If your app runs in multi-tenant mode, each tenant gets its own settings panel — genuinely separate from your org's own settings, not a scoped-down copy of it. A tenant's credentials, AI keys, and SSO config never leak into another tenant, and they're independent of whatever your org itself has configured.
What's configurable per tenant
| Setting | What it controls |
|---|---|
| Connector credentials | Each tenant supplies its own API keys/secrets for any connector your org has adopted — see Connectors for the full setup flow. |
| AI provider keys | Each tenant supplies its own AI provider key(s), used by that tenant's own logic blocks/agents. This is separate from the org-level AI provider *catalog* in Org Settings, which holds no keys of its own. |
| SSO | Per-tenant Okta/OIDC or Google sign-in (paid plans) for that tenant's own end users — distinct from your org team's own SSO. |
| A custom from-address for that tenant (paid-plan gated), falling back to your org's verified domain, then the platform default, if unset. | |
| Branding | Per-tenant logo/colors, independent of your org's own branding. |
| General settings and Secrets | Two key/value lists for your own use. They are handed to the things that run for the tenant: {{params.settings.KEY}} in a Logic Block step or an agent prompt, ctx.params inside a Glyph, and {{secret:NAME}} in a Logic Block webhook step. Keep sensitive values in Secrets — they never reach an AI model and are scrubbed from Glyph output. |
One value for every tenant, or one each?
One app serves many tenants, so for each value you use in a Logic Block, a Glyph or an agent, decide whether every tenant should share it or each should have its own. A value you write into the asset — a Glyph's envConfig, a literal in a Logic Block step, text in an agent's prompt — is the same for every tenant of your org. That is right for logic, and for anything your whole business shares: a base URL of your own service, a fixed rate, a tone of voice.
It is wrong for anything that differs per tenant: each tenant's own API keys, account or workspace ids, webhook URLs, sender names, limits. Put those in the tenant's own settings instead — General for plain values, Secrets for keys and tokens — and let the asset read them when it runs. You write the asset once; each tenant's admin fills in their own values, and nothing changes in the asset when you add a tenant.
| Where the asset reads it | How |
|---|---|
| Logic Block step or agent prompt | {{params.settings.KEY}} — a General setting |
| Logic Block webhook step | {{secret:NAME}} — a Secret, in a header, the body or a query parameter |
| Glyph | ctx.params.settings and ctx.params.secrets |
| A connector | Each tenant's own credentials (Tenant Management → Connectors) — prefer this to a raw key wherever a connector exists |
Not sure which it is? Ask the business: should every tenant use the same value, or its own? Anything sensitive goes in Secrets, never General (General values can reach an AI model through an agent prompt). When you build with an AI assistant over MCP, it can write assets that read these values but cannot set them — they are the tenant's own data, entered by that tenant's admin here — so ask it which keys each tenant needs to fill in.
Team management is a different system
Inviting a tenant's users and assigning them permissions is NOT a tenant setting — it's a separate concept entirely (see Roles, ACL & groups). Don't go looking for team invites here.