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.