Your organization defines the flags; each tenant can adjust how they are served to itself. This matters in a multi-tenant app, where you — the org admin — cannot manage every tenant's settings one by one in the console.
What a tenant can change
| Part | Tenant may set it? |
|---|---|
| Switch on/off and the off value | Yes |
| Everyone else (default or split) | Yes |
| Individual users | Yes |
| Rules | Yes |
| Schedule and window | Yes — it replaces the organization's schedule for that tenant |
| Key, kind, values, name, description | No — the organization owns what a flag is |
| Adding or deleting a flag | No |
A tenant can only use the values the organization defined, so every tenant's answers stay inside what your Logic Blocks, Glyphs and app expect.
In the console
Open Tenants → the tenant → Feature flags. Each flag shows what that tenant gets and whether it differs from your organization. Use the switch to turn a flag on or off for this tenant (an Undo appears), or open it:
- Each section has Set for this tenant. Off means it follows your organization (shown read-only); on lets you change it.
- Use my organization's settings removes every change for that flag in one step.
- The Test tab shows what a user of this tenant would get.
Locking a flag
In the organization's flag, turn off Tenants may change this flag. The flag shows as "Set by your organization" in every tenant, tenants cannot change it, and any earlier change a tenant made to it stops applying immediately.
What follows what
| If… | Then the tenant gets… |
|---|---|
| The tenant changed nothing | Whatever your organization sets — including later changes you make |
| The tenant changed only the switch | Its own switch, your default, rules and schedule |
| You change your default and the tenant had set its own default | The tenant's default; the rest follows you |
Your own admin screen
Build a screen in your app where each tenant's admin manages their flags, with the same token your app already uses. Only a tenant admin (a user with full access in that tenant) can use these; the tenant is always the one in the token.
| Call | Does |
|---|---|
GET /app/{orgCode}/tenant/featureflags | Every flag as this tenant gets it: flag (what it gets), org_default (what you defined), overridden (which parts the tenant set), override_version. |
GET .../featureflags?key=new-checkout&as=u_1&attr.plan=pro | One flag, plus test — what that user would get and why. |
PUT .../featureflags { "key": "new-checkout", "enabled": false } | Changes the given parts for this tenant. A part sent as null goes back to your organization's value. |
DELETE .../featureflags?key=new-checkout | Removes every change this tenant made to the flag. |
// turn a flag off for this tenant, then put its default back to the organization's
await api.put(`/app/${org}/tenant/featureflags`, { key: 'new-checkout', enabled: false });
await api.put(`/app/${org}/tenant/featureflags`, { key: 'new-checkout', fallthrough: null });Send version (the override_version you read) with a change to refuse it if someone else changed the flag in the meantime (409). A locked flag answers 403; an unknown value answers 400 with a plain message.
From MCP
Ask your AI assistant to manage a tenant's flags with list_tenant_feature_flags, set_tenant_feature_flag and clear_tenant_feature_flag_override. These need a tenant: if your org has more than one, the assistant asks which tenant you mean.
More than flags
The same tenant-admin route (/app/{orgCode}/tenant/{section}) also manages the tenant's settings and email templates, and its members, invitations and workspace name — see Manage tenant settings from your own app.