Governance & Impersonation
A consultancy or MSP reaches a client workspace through a delegation grant. New workspaces created through the partner onboarding flow start with an active full-operational grant. For an existing workspace, a client Admin approves the tier, scope, and duration before access begins. The client can review, narrow, or end delegated access from Governance settings.
This page is written for the partner side: what a grant gives you, and how to work inside a client’s workspace.
The grant lifecycle
A grant is only ever in one of two live states. Everything else is a way it finished.
Two states are live; the rest are final. Choose a transition to see who moves the grant and what it means. Accepting is the only step that grants anything.
A workspace can be governed by one partner at a time. Accepting a grant declines any competing request and ends any previous one.
A new request emails the client’s Admins with what was asked for and a link to answer it, and it also waits for them under Settings → Governance. Both the email and that page are Admin-only, so a workspace whose day-to-day runs on Manager accounts should make sure an Admin is watching for it. Accepting or declining emails the operator who asked.
Ended grants are kept permanently. The client’s audit history of the relationship is never deleted, and stays exportable by the client.
Access tiers
The partner requests a tier; the client can accept it or downgrade it, never raise it. To move an active grant to a higher tier later, the partner sends a new request. Accepting it ends the old grant and activates the newly consented one.
| Capability | Read-only | Full operational |
|---|---|---|
| View workflows, executions, failures, members, credit usage | Yes | Yes |
| Receive alerts about this team | Yes | Yes |
| Copy workflows into or out of this team | No | Yes |
| Acknowledge or resolve alerts, operational actions | No | Yes |
| Impersonation as a team admin | No | Only if separately allowed |
| Change billing, delete data, read credentials | Never | Never |
What “never read credentials” does and does not mean. At no tier can an
operator open your credential vault, or create, rotate, or remove a
connection, impersonation included. When a result or error contains the exact
value of a workspace secret referenced through Glow Secrets, standard run
processing replaces it with [REDACTED] before storing the history. Do not
paste tokens directly into step fields or outputs: those values do not carry
the same protection. What a full-operational grant can read is the rest of the
step result: the business data your workflows move. If a workflow handles data
you would not show your partner, scope the grant to exclude it, or grant
read-only.
Access scope
A grant covers either the whole workspace or a specific list of workflows.
Full workspace: every workflow in the team.
Selected workflows: only the workflows the client’s admin picks when accepting, up to 100. The request cannot name workflows, because a partner without a grant cannot see what a workspace contains. Widening the list later requires a new request and a new consent.
The cap shapes what scoping is good for. It works when you want a partner confined to a handful of automations. Exposing more than 100 means granting the whole workspace instead, so scoping is not the way to exclude a few workflows from a large one.
Workflow scoping confines which workflows an operator can see, run, and edit. But working on those workflows still reaches the team resources they depend on: files, variables, and connected accounts. Scoping is narrower than full-workspace access, not a sealed box.
Under a workflow-scoped session, operators cannot create new workflows at all. A new workflow would fall outside the consented set.
Grant duration
The partner picks a duration when requesting: 30 days, 90 days, 1 year, or 2 years. The default is 2 years, and the minimum is 30 days. Check the expiry date shown on the consent screen before accepting.
Clients see a warning in Governance settings when fewer than 30 days remain, and receive an email with an extend option once a grant lapses.
Choosing a duration for the way you work
Consultant and MSP practices carry exactly the same access. Where they differ is what happens after the work is done, and that is worth thinking about when you pick a duration.
Delivering a project and handing it over. Set the grant to the length of the engagement rather than the default. When the project ends, leave management yourself rather than waiting for the grant to lapse: the client keeps every workflow you built, and the record of the engagement stays in their audit history. A grant that quietly runs for another eighteen months after the last invoice is the thing a client’s security review will ask about.
Running the automations you built, indefinitely. A long grant is the point, and the default suits it. What matters instead is that the client understands the relationship is ongoing: say so when they accept, and expect to be asked about it at review time. If a client narrows the scope later, the console tells you what you can no longer reach rather than failing quietly.
Either way, the client sets the ceiling. You request; they accept, downgrade, or decline.
Impersonation
Impersonation lets an operator act as one of the client’s admins, with that admin’s permissions. It is a second, separate consent. Accepting a grant does not enable it.
Three conditions must all hold for a session to start: the grant is active and unexpired, its tier is full operational, and the client has switched on Allow impersonation.
Starting a session
The operator chooses the target admin, a duration, and must type a reason of at least ten characters. The reason is recorded, emailed to the client’s admins, and shown in the client’s session log.
Available durations: 5, 15, and 30 minutes; 1, 3, 6, 12, and 24 hours; 3, 7, 14, and 30 days. The default is one hour, and 30 days is a hard ceiling.
An operator can run one session at a time across your whole client list, not one per client: starting a second session while one is open is refused until the first ends. Two operators can be in two different clients at once, so parallel work is a matter of how many people you have, not a per-client limit. Sessions can be narrowed below the grant’s scope at start, never widened.
What is recorded
The client’s admins are emailed the moment a session starts, before the operator does anything. They are emailed again when it ends, with the duration and an action count. Every action is attributed to both identities in the client’s activity trail.
Even under impersonation, credential operations stay blocked. An operator can run workflows against existing connections, but cannot mint, remove, or re-authorise them.
Agent memory is shared with the client
An AI Agent step with Memory Enabled keys its memory to the workflow rather than to the person running it. Run a client’s workflow under impersonation and that applies to your run too: the agent recalls what the client’s own runs taught it. Whatever it learns on your run is there for the client’s next one.
This is worth a thought before you trigger a client workflow whose agent has memory switched on. If a run of yours would teach the agent something the client’s runs should not inherit, use a test workflow in your own workspace instead. A copy of a workflow does not inherit the original’s memory.
For clients
If a partner has asked to manage your workspace, or already does, everything you decide and control lives on its own page: If a Partner Manages Your Workspace. It covers the consent screen, the Allow impersonation toggle, and the three different ways to stop access.
What’s Next?
👉 Your First Client Workflow → — apply the grant, workspace and handover model to one complete rollout.
Sideways from here: read If a Partner Manages Your Workspace before asking a client to approve access.