Multiple Tenants
More than one Azure AD connection can exist, each pointing at a different Microsoft directory.
Where to find it
Architect Panel → Integration & Connections:
- Azure AD Tenants — the connections
Architect Panel → Configuration:
- Multitenancy — the platform tenants they may be tied to
When you need several
- A multi-tenant installation where each customer signs in with their own Microsoft directory.
- A group whose subsidiaries have separate directories.
- Partner access, where an external organisation's staff sign in with their own accounts.
Tie each to its tenant
The local tenant setting binds a connection to one tenant of your installation. On a multi-tenant platform that matters a great deal: without it, a connection intended for one customer is available to another.
Set it deliberately on every connection. This is the field that keeps customers separate, and the failure is not obvious from the sign-in page.
Name them for the organisation
Not "Azure 2". When a secret is about to expire or a connection fails, you need to know whose it is immediately — and the person handling it may not be the person who set it up.
Each has its own expiry
Several connections means several secrets on different dates. That is several diary entries, and the one that is missed will be the connection nobody thinks about.
Keep a single list of every connection and its expiry rather than relying on remembering. Reviewing it quarterly takes minutes.
Know who administers each directory
Renewing a secret needs somebody with rights in that Microsoft tenant, who may work for another organisation entirely. Record who that is alongside the connection — discovering you do not know, on the day it expires, is a bad afternoon.
The same person in two directories
Somebody with accounts in two connected directories arrives as two identities, because identity includes the method and domain. Usually correct — they are acting in two capacities — and occasionally confusing.
Be ready to explain it, particularly to consultants who work with several of your customers.
Test each separately
A working connection tells you nothing about the others. When adding one, test that one, and confirm it lands users in the right tenant with the right groups rather than assuming it inherits the behaviour of an existing connection.
Retiring one
When a customer leaves, disable their connection. Their accounts remain until you deal with them, so decide what happens to those too — an account that can no longer authenticate is not the same as one that has been closed.
Worked example
A multi-tenant platform runs four Azure connections, each named for its customer and tied to its own local tenant. A single reviewed list holds each secret's expiry and the administrator contact at that customer. When one customer's directory was restructured, only their connection needed attention.
Recommendations
- Always set the local tenant on a multi-tenant installation.
- Name connections after the organisation.
- Keep one list of connections, expiries and contacts.
- Test each connection separately.