How Multi-Tenancy Works
Isolate each client’s automations, connected accounts, secrets, files, and run history in their own dedicated workspace. Every client you work with has a workspace of their own.
- Use it to
- Isolate each client's automations, connected accounts, secrets, files, and execution history in a dedicated workspace
- Find it
- Clients → Settings → Client access (partner) or Team settings → Governance (client)
- Limits
- 1 governing partner practice per client workspace · Up to 100 selected automations · 30 days to 2 years grant duration
- Output
- Draft automation copies, variable/secret key names, and fleet run summaries cross the boundary
You do not work from a shared account with access to everything. Delegated access to a client workspace is governed by a delegation grant. Direct workspace membership is a separate access path and must be reviewed separately. New workspaces created through partner onboarding start with an active full-operational grant. A client Admin reviews requests for an existing workspace before access begins.
This page is the model in one place: what separation means here, what crosses a boundary, and what the client keeps hold of throughout. The pages after it cover each part in practice.
One workspace per client
Use a separate workspace for each client so their automations, accounts, and access can be managed independently.
| Belongs to the client’s workspace | What that means for you |
|---|---|
| Automations and their run history | Delegated visibility follows the active grant; direct membership has its own permissions |
| Connected accounts | Connect the client’s Slack or CRM account, not your practice’s account |
| Secrets | Secret values are masked when variables are read; see the credential and output safeguards |
| Ordinary team variables | Values can be read in plaintext by authorized users; do not store credentials in them |
| Files | Uploaded to their workspace, read by their automations |
| Plan, credits and limits | Check the plan, available resources, and limits shown for the client workspace |
Check the client’s plan before deployment. A 500-item batch exceeds Free’s 50-item limit for Run for each item, but fits Paid’s 1,000-item limit. Sufficient resource balances and other execution limits still apply.
Self-funded prepaid client workspaces use their own purchased balances. Workspace access does not itself establish sponsorship or paid capacity, and sponsorship does not grant access to client automations. See Sponsorship & Changing Payer for funding arrangements and Invoices & Payment Methods for invoice ownership.
Access is granted, not assumed
For a request to an existing workspace, the grant names four things for the client to review:
- The tier. Read-only or full operational. The client can accept or downgrade your request, never raise it.
- The scope. Whole-workspace or selected-automation access (up to 100 automations chosen by the client Admin).
- How long. Time-boxed from 30 days up to 2 years, starting when the client accepts.
- Whether you may work as them. Allow time-boxed impersonation is off by default and available only at full operational.
New workspaces created through Client Onboarding start with an active full-operational grant so setup can begin immediately. A client Admin can lower the active tier, disable impersonation, or end management at any time in Team settings → Governance. See Governance & Impersonation.
A workspace is governed by one practice at a time. Accepting a grant declines any competing request and ends any previous grant. Review direct memberships separately; ending a grant does not remove them.
What crosses between workspaces
| Crosses the boundary | Stays in source or reconfigured in client workspace |
|---|---|
| Delegated visibility permitted by the active grant | Direct workspace memberships, which are managed separately from the grant |
| Copied automation structure delivered in Draft | App connections (auto-bound only when the client has one healthy matching account in total) |
| Variable and secret key names referenced by the automation | Variable and secret values (missing keys arrive empty; existing client values stay untouched) |
| Referenced team files (review file contents before pushing) | Captured Step sample data, which is stripped during deployment |
| Fleet-level run summaries in your Clients console | Subflow targets and AI Agent tools/knowledge, which must be re-linked in the client copy |
See Complete the client copy for the post-deployment checklist.
Admin Push checks sources in the background. It does not show a detailed per-file or per-key preflight. Review deployment receipts and the client copies before activation. Workspace Deployment uses a selected saved version instead. See Pushing Automations.
What the client keeps
- Delivered automations. Ending a delegation grant does not delete automations built or deployed in the client’s workspace. Authorized client members can continue to maintain them. This describes workspace control, not the intellectual-property terms of your engagement.
- Visibility. Impersonation sessions record who, when, and how long. Ending the grant does not erase the trail. Client Admins can export the available Governance audit trail as CSV.
- Control. A client Admin can lower the active tier, end a session, disable impersonation, or end management without going through you. A higher tier or wider automation scope requires a new request and consent.
- Their own accounts. Connections are authorized under the client’s accounts. When the relationship ends, review direct workspace memberships separately from the grant.
- Run
- Open Clients → Settings → Client access in your practice workspace
- You should see
- Each managed client workspace lists its active grant tier, scope, and expiration date separately from direct workspace memberships.
What’s Next?
👉 Client Onboarding →: choose how to create a client workspace or request access to an existing one.
Sideways from here: share If a Partner Manages Your Workspace with a client who wants to review the controls they keep.