# If a Partner Manages Your Workspace

> Deciding whether to accept a consultancy or MSP's request for access, what you keep control of afterwards, and the three different ways to stop it.

A consultancy or MSP works in your workspace through a **delegation grant** that you can review, narrow, or end. If they requested access to an existing workspace, you choose whether to approve it and can reduce the requested tier. A new workspace created through partner onboarding starts with a full-operational grant so setup can begin immediately.

## Deciding on a request

You have had an email, or there is something waiting under **Settings → Governance**. Four things decide it, and you can change three of them before you accept.

| What you are asked                                 | What you can do about it                                                                                                             |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **The tier** — read-only or full operational       | Accept it, or downgrade to read-only. You can never raise it above what was asked. See [Access Tiers](/msp/governance#access-tiers). |
| **The scope** — whole workspace or named workflows | If the request is workflow-scoped, you pick the workflows, up to 100.                                                                |
| **Impersonation** — acting as one of your admins   | A separate checkbox, unchecked by default, and offered only at full operational. Accepting the grant does not enable it.             |
| **The expiry date**                                | Set by the partner's requested duration. Read it before accepting; it is shown on the consent screen.                                |

Take the narrower option unless the work genuinely needs the wider one. A partner who needs more later has to ask again, and you consent again.

### Reviewing a request

The email links to a consent screen. Nothing is decided by opening it. Unlike ordinary invite links, no decision is committed until you choose. Only team admins can act on it.

The screen shows who is asking, the tier and scope requested, the exact expiry date, the [capability table](/msp/governance#access-tiers), and any note the partner added. If full operational was requested, you can downgrade to read-only before accepting. If the request is workflow-scoped, you pick the workflows.

**Allow impersonation** is a separate checkbox, unchecked by default, and available only at full operational.

> **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.

## Ongoing control

Everything lives under **Settings → Governance**, which only team Admins can open:

- A banner while a session is live: who, when, why, when it ends automatically, and a button to end it now.
- Current status: tier, expiry, who granted it, and how the grant originated.
- The **Allow impersonation** toggle.
- A log of every impersonation session ever run against the workspace.
- The activity trail and the history of past grants.

You are emailed the moment an impersonation session starts, before the operator does anything, and again when it ends with the duration and an action count.

## Three different ways to stop access

These are easy to confuse, and they do different things.

| Control                       | Stops                              | Leaves in place                                                                               |
| ----------------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------- |
| **End session**               | The one session running now        | The grant. A new session can start later.                                                     |
| **Allow impersonation** (off) | All impersonation, now and future  | The grant — console visibility continues.                                                     |
| **Leave MSP management**\*    | Delegated access through the grant | Audit history, your workflows, and any direct team membership the partner's people also hold. |

\* The wording follows your partner's own brand, so it reads **Leave consultancy management** where the practice is set up as a consultancy.

**Your workflows stay yours.** Leaving management ends the partner's delegation grant, active sessions, console visibility and planned workflow transfers. It does not remove anything from your workspace. Workflows they built or pushed to you remain, keep running, and are yours to edit.

If the partner's people also appear under **Team Management**, remove those direct memberships separately. This matters for workspaces created through partner onboarding, where the person who created or accepted the workspace can also hold an Admin membership. Ending the grant does not remove that second access path.

> **Check both access paths when the relationship ends.** Removing a person from
> Team Management leaves the delegation grant active. Leaving MSP management
> ends the grant but leaves any direct team membership in place. Use Governance
> for the grant, then Team Management for partner members who should no longer
> belong to the workspace.

### Revocation takes effect immediately

There is no cached access anywhere. When you revoke a grant or switch off impersonation, live sessions end in the same transaction. The operator's next request is refused, and any open canvas disconnects within 30 seconds. You do not wait for a session to expire.

Ending a grant also clears the partner's console visibility and cancels any planned workflow transfers between the two workspaces.

## Grants that never showed you a consent screen

Not every grant comes from a request you approved. Check the origin on your status card:

- **Invited by request**: you consented on the screen described above. This is the only origin where you picked the tier.
- **Workspace created by** your consultancy, agency or MSP — the card names whichever applies: the workspace has been governed since it was created, so no consent screen ever appeared. These start at **full operational**. It covers two cases. They may have created the workspace for you. Or **you created it yourself from an invite link they sent**, in which case signing up personally did not mean choosing their access level.
- **Pre-existing management**: migrated from before this system existed.
- **Assigned by Glow**: a break-glass assignment by Glow support.

Whatever the origin, the controls above are yours: you can downgrade impersonation consent or leave management at any time.

## What's Next?

- **[Governance & Impersonation](/msp/governance)**: the full detail of what each tier permits, how scope works, and what an impersonation session records.
- **[Security & Compliance](/manage/workspace-settings/security-compliance)**: how the rest of your workspace's access controls fit together.
- **[Team Management](/manage/workspace-settings/team-management)**: roles and members inside your own team, which is a separate thing from a grant.