Skip to Content
🏢 For Consultants & MSPsHow Multi-Tenancy Works

How Multi-Tenancy Works

Every client you work with has a workspace of their own. Their workflows, connected accounts, secrets, files and run history live inside it and belong to them.

You do not work from a shared account with access to everything. Access to a client workspace is governed by a delegation grant, and only what that grant permits is visible to you. 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.

The same model on the canvas: client workspaces, the access a grant carries, and pushing one automation to all of them.

One workspace per client

The workspace is the unit everything is scoped to. Two clients never share one.

Belongs to the client’s workspaceWhat that means for you
Workflows and their run historyYou see a client’s runs only while your grant is active
Connected accountsTheir Slack, their CRM, authorised under their own account — never yours
Secrets and team variablesYou can use them in a workflow, and their values are never shown to you in plain text
FilesUploaded to their workspace, read by their workflows
Plan, credits and limitsTheir plan governs what runs there, independently of yours

Their plan applies inside their workspace. A workflow that loops 500 items runs on a client with a Pro plan and stops on one with Free. Check the plan before you deploy something demanding. See System Limits.

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. You request one; they can accept it or downgrade it, never raise it.
  • The scope. The whole workspace, or a list of workflows they pick.
  • How long. 30 days, 90 days, 1 year or 2 years, with the exact expiry date shown before they accept.
  • Whether you may work as them. Impersonation is a separate checkbox, unchecked by default, and offered only at full operational.

New workspaces created through either partner onboarding route begin at full operational without this request screen. The client can review, narrow, or end the grant afterwards. Full detail is in Governance & Impersonation.

A workspace is governed by one practice at a time. Accepting a grant declines any competing request and ends any previous one, so a client always knows exactly who holds access.

What crosses between workspaces

Three things cross a boundary, each deliberately:

Your view of their workspace, limited to what the grant permits. A client who revokes consent disappears from your console immediately.

A workflow you push to them. Build an automation once in your own workspace and deploy it into a client’s. A step is rebound when the client workspace has one matching connected account. If none or several match, the copied step arrives without an account selected for the client to complete.

Nothing else. A client’s data is not pooled, aggregated across your roster, or visible to another client. Your own workspace’s secrets do not travel with a pushed workflow: variables land as empty references for the client to fill, never your values. Team files the workflow reads are the one thing copied in, and the one-client Push preflight lists each one before anything is written.

The one-client admin Push shows a preflight before the copy starts. Review its connections, workspace values, files, and sample-data handling with the client, then start the push. For a multi-client rollout, Workspace Deployment uses the saved workflow version you select instead. See Pushing Workflows.

What the client keeps

Worth being able to state plainly, because clients ask:

  • Ownership. Workflows built in their workspace are theirs. Ending the relationship does not take them away.
  • Visibility. Every impersonation session is recorded, with who, when and how long. The audit history survives the grant ending and is exportable.
  • Control. Consent can be narrowed to specific workflows, downgraded to read-only, or withdrawn outright, without going through you.
  • Their own accounts. Connections are authorised under the client’s accounts. Nothing you hold gives access to their tools once the grant ends.

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.