# Governance & Impersonation

> How delegated access works between a partner practice and a client workspace: consent, tiers, scope, impersonation sessions, and revocation.

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.

  - [If a Partner Manages Your Workspace](/msp/governance/for-clients): Deciding whether to accept a request, and how to narrow or end access afterwards. Written for the client.

## The grant lifecycle

A grant is only ever in one of two live states. Everything else is a way it finished.

A grant has two live states, Pending and Active. Every other state is final.

From **Pending** (requested, nothing granted yet):

- Accepted → **Active**. The client's admin accepted, at the tier and scope they chose. Accepting also declines any competing request and ends any previous grant.
- Declined → **Declined**. The client's admin said no. The partner may ask again.
- Withdrawn → **Withdrawn**. The partner cancelled its own request before it was answered.
- 14 days passed → **Expired**. The request timed out unanswered.

From **Active** (the partner has the access the client consented to):

- Revoked → **Revoked**. The client ended the relationship, effective immediately.
- Ended or replaced → **Ended**. The partner ended it, or a newer grant replaced it.
- Reached its end date → **Expired**. The grant hit the expiry date set when it was accepted.

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](/build/ai-features/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](/msp/governance/for-clients)**. It covers the consent screen, the
**Allow impersonation** toggle, and the three different ways to stop access.

## What's Next?

👉 **[Your First Client Workflow →](/msp/first-client-workflow)** — apply the grant, workspace and handover model to one complete rollout.

Sideways from here: read [If a Partner Manages Your Workspace](/msp/governance/for-clients) before asking a client to approve access.