Guide

Multi-Tenant SaaS Orchestration

How shared orchestration infrastructure can give each customer a properly isolated workspace.

What "Multi-Tenant" Actually Has to Mean

Calling a system multi-tenant is cheap. Making it multi-tenant in a way that holds up to scrutiny means the following are all true:

Data isolation. One tenant cannot read, write, or even see another tenant's configuration, secrets, or run history.
Identity isolation. A user authenticated for tenant A cannot, by changing a URL or a header, act as tenant B.
Performance isolation. A noisy tenant should not degrade the portal or the dispatcher for everyone else.
Operational isolation. Removing a tenant should remove their data cleanly. Restoring a tenant should restore their data and nothing else.

These properties are usually achieved with one of three patterns: row-level filtering, schema-per-tenant, or database-per-tenant. Each has trade-offs in isolation strength, operational overhead, and per-tenant cost. Polysync uses schema-per-tenant, which sits in the middle: stronger isolation than row filtering, lower overhead than running a database per customer.

Schema-Isolated Tenancy in Polysync

Each Polysync tenant owns a dedicated SQL schema. Their platforms, jobs, tasks, schedules, dependencies, concurrency profiles, and run history all live inside that schema. A small system schema holds tenant metadata, user-to-tenant mapping, and platform-wide configuration.

The consequences of that choice:

Isolation is enforced at the schema level, not at the query level. A bug in application code cannot accidentally JOIN across tenants because the tables it would have to JOIN do not exist in its connection's search path.
Per-tenant queries cost what they cost. A heavy operations dashboard for tenant A scans only A's run history, not the entire platform's.
Deprovisioning is a schema drop. There is no orphan-row hunt and no "did we remember to filter on tenant_id everywhere" audit.
Per-tenant restores are a schema restore. You do not have to extract one tenant's rows out of a shared table.

Identity: Claims, Not URL Parameters

Authentication is Microsoft Entra ID single sign-on. Once a user signs in, Polysync runs a claims transformation that resolves the user's tenant from their directory membership and injects three claims into every request:

tenant_id: the Polysync tenant ID.
tenant_schema: the SQL schema name that backs that tenant.
tenant_user_id: the user's identity inside the tenant.

Application code does not parse Azure AD object identifiers on every request, and tenant identity is not carried in URLs, headers, or query parameters where it could be forged. The orchestration code reads the resolved claims and routes all data access through the tenant's schema. A user with no claim for a tenant cannot reach that tenant's data, regardless of what URL they type.

Provisioning Happens on First Sign-In

When a new organisation subscribes through the Azure Marketplace and the first user signs in, Polysync provisions the tenant automatically: the schema is created, migrations are applied, and the user is assigned the Administrator role. There is no manual setup step, no support ticket, and no deployment pipeline to run per customer. By the time the sign-in redirect completes, the workspace is ready.

Roles: Administrator and Operator

Polysync uses a deliberately small role model.

Administrator configures platforms, secret vault links, jobs, tasks, dependencies, schedules, concurrency profiles, and users.
Operator runs and monitors: triggers ad-hoc executions, reschedules, watches the live dashboard, and inspects run history.

Both roles are scoped to a single tenant. Authorisation is enforced server-side on every request, not just on the UI. A user cannot acquire elevated capabilities by manipulating client state.

Per-Tenant Platform Connections and Vaults

Each tenant configures its own platform connections. Tenant A might orchestrate ADF, Databricks, and Logic Apps; Tenant B might orchestrate Cloud Composer and Vertex AI. The orchestration engine is the same in both cases; the connection details are the tenant's.

Credentials live in a vault. Polysync supports Azure Key Vault, AWS Secrets Manager, Google Cloud Secret Manager, and HashiCorp Vault as the credential source. If a tenant does not want to link their own vault, Polysync can hold the credential in its managed Azure Key Vault. Secrets are read on demand at dispatch time and are not retained in application memory or logs.

The Shared Dispatcher Is Tenant-Aware

The dispatcher is shared infrastructure, but it does not pool work across tenants. Concurrency budgets are evaluated per platform connection, and platform connections belong to tenants, so tenant A's busy Databricks workspace cannot exhaust the dispatch budget for tenant B's unrelated work. The scheduler enqueues per-tenant runs into the same queue table, and the dispatcher picks them up with the tenant context attached, so all downstream API calls, parameter lookups, and run-history writes happen inside the tenant's schema.

Operational Properties That Fall Out Of This

Auditability. Every action is bound to a tenant and a user. Run history per tenant is a single-schema query.
Compliance simplicity. "Show me everything we hold for customer X" is a schema dump. "Delete everything we hold for customer X" is a schema drop.
Restoration without bleed. A point-in-time restore of one tenant's schema does not require quiescing the others.
Capacity planning per tenant. Schema-level metrics make it straightforward to see which tenants are growing, in what dimensions.

When This Model Fits

You are building a SaaS that orchestrates per-customer data work and need isolation guarantees you can defend to a security reviewer.
You operate a data team that serves multiple clients and wants each client's orchestration to live in its own logical workspace without standing up separate infrastructure per client.
You want one operational view across tenants for your own ops team, while every tenant sees only their own world.