Tenant Access

Linking Users to Tenants

A user is linked to a tenant, and that link is what decides which organisation’s data they see.

Where to find it

Architect Panel → Configuration:

• Multitenancy — the tenants themselves
• Custom Tenant Information Fields — your own fields on a tenant
• Instance Configuration Fields — settings held per tenant

Architect Panel → User Administration:

• All Users — the accounts themselves
• User Groups — what they can do within a tenant

The link identifies the account, not the row

A link records the login method, the unique identifier and the domain — so it works for inbuilt accounts and for federated ones alike. That matters because a user signing in through an identity provider does not have an account row in the ordinary sense.

A user can belong to several

Which is a real requirement more often than it looks: a consultant working with two of your customers, a group finance manager covering subsidiaries, your own support staff.

Each link is separate, and each can be removed independently.

Access within a tenant is still groups

The tenant link says which organisation; security groups say what they may do inside it. Both are needed, and a user linked to a tenant with no groups sees a tenant they cannot use.

Your own staff need care

Support and administration staff often end up linked to many tenants, accumulated one incident at a time and never removed. That is a small number of accounts with access to a large number of customers.

Review those links specifically, on a schedule, and prefer time-bounded access where the platform allows it.

Leavers are the recurring failure

Somebody leaving a customer organisation needs their link removed. That is the customer’s responsibility and your problem, because a former employee still reaching their old employer’s data is a story about your platform.

Make it easy for a customer administrator to see and remove their own users’ links.

Removing the link is not deleting the account

Which is usually right — the person may belong to another tenant, and their history should stay attributable. Be clear about the difference when writing a leaver process.

Audit the links periodically

Who is linked to each tenant, and does each still need to be. It is a short list per tenant and a revealing one.

Worked example

A platform lets each customer administrator see their own tenant’s user links and remove them. Support staff links are reviewed monthly and removed when the incident closes — a review that once found eleven support accounts still linked to a customer who had left two years earlier.

Recommendations

• Review your own staff’s links monthly.
• Give customer administrators visibility of their own links.
• Removing a link is not deleting an account — say so in the process.
• Audit links per tenant periodically.

Switching Tenants

A user linked to more than one tenant can switch between them, and the platform lists the ones they may reach.

Where to find it

Architect Panel → Configuration:

• Multitenancy — the tenants themselves
• Custom Tenant Information Fields — your own fields on a tenant
• Instance Configuration Fields — settings held per tenant

Architect Panel → Configuration:

• Site Settings — where a user lands after signing in

Only linked tenants appear

The list a user is offered comes from their own links and their groups. So switching is not a way to reach a tenant somebody does not already have access to — it is a convenience over access they already hold.

Where they land

Sign-in can take a user to a tenant page or straight to the administration panel, which is an installation-level choice. For a user with several tenants, landing somewhere that makes the current tenant obvious is worth more than saving a click.

The current tenant must be unmistakable

The whole risk of switching. Somebody who believes they are in one customer’s tenant and is actually in another will create records in the wrong place, send a message to the wrong customer, or delete something that was not theirs.

The tenant name should be visible at all times, not on a page nobody looks at.

Encourage a habit

Check where you are before doing anything consequential. That sounds trivial and it is the control that actually works, because no interface prevents somebody acting on an assumption.

Switching does not change permissions

A user has whatever groups they hold in the tenant they switch to, which may be quite different. Somebody who is an administrator in one and a read-only user in another will find things missing, and that is correct.

Activity is recorded per tenant

Which means an action taken in the wrong tenant is recorded there. That is how such a mistake is found afterwards — and a reason the tenant should be obvious at the time, not reconstructed later.

Support access deserves a marker

If your own staff switch into customer tenants, consider making that visibly different from a customer’s own session. It reduces mistakes and it is the honest thing to show the customer in their activity log.

Worked example

A platform shows the current tenant name in the header at all times and lands multi-tenant users on a page that names it explicitly. Support sessions are visually marked. A consultant working across three customers reported the header as the thing that stopped repeated mistakes.

Recommendations

• Show the tenant name always, not on one page.
• Land multi-tenant users somewhere that names it.
• Mark support sessions visibly.
• Build the habit of checking before acting.

Tenancy and Custom Code

Two older custom-PHP paths are refused automatically whenever tenancy is enabled. This is deliberate and it is worth understanding rather than working around.

Where to find it

Architect Panel → Configuration:

• Multitenancy — the tenants themselves
• Custom Tenant Information Fields — your own fields on a tenant
• Instance Configuration Fields — settings held per tenant

Architect Panel → Automation:

• Extensions — the supported way to run custom logic
• Workflow Builder — rules, which cover most cases

What is refused

• The rule action that runs a PHP script.
• The custom-PHP field type.

Both execute code written by an architect, with no sandbox, in the platform’s own process.

Why tenancy changes the answer

On a single-organisation installation, an architect writing unsandboxed PHP is running code on their own system — a reasonable thing to allow.

With tenancy on, that same code runs in a process shared with every other tenant on the installation. An architect in one customer’s tenant would be executing unreviewed code alongside everybody else’s data. That is not a permission anybody can safely grant.

It is refused automatically

Not left as a setting somebody might forget. The check happens because tenancy is on, which is the right shape for a control of this kind — a security boundary that depends on somebody remembering is not a boundary.

What to use instead

• Rules cover most of what these paths were used for — conditions, actions, notifications, field updates.
• Extensions cover the rest. They run out of process, under a timeout, a memory limit and an outbound allowlist, with a circuit breaker.

Extensions exist precisely because custom logic is legitimate and unsandboxed execution is not.

There is an override, and it is narrow

A configuration setting allows the legacy paths, and it exists for one situation: a self-hosted installation that runs tenancy for its own internal reasons and already depends on those paths.

If you serve external customers, this is not for you. Setting it means an architect in one tenant can run arbitrary code affecting all of them.

Migrating existing usage

If you are turning tenancy on and have existing custom PHP, find it first. A rule that stops working when tenancy is enabled is a bad way to discover a dependency.

Rewrite each as a rule or an extension before the switch, not after.

Worked example

An installation enabling tenancy found four rules using the PHP script action. Three were reimplemented as ordinary rule actions; the fourth, which called an external service, became an extension with the service’s host on its allowlist. Tenancy was enabled afterwards, with nothing broken.

Recommendations

• Find existing custom PHP before enabling tenancy.
• Rules first, extensions for the rest.
• Do not set the override if you serve external customers.
• Treat the refusal as correct, not as an obstacle.