Multi Tenancy Staff Access

Multi-tenancy: staff cross-company access

Part of the Multi-tenancy section. Built — on main. The company switcher and the per-analyst access control are live; cross-company audit logging is still to come.

Your analysts work across companies. This page covers how they move between clients, search across all of them, and how you control who can see what.

The company switcher

Analysts spend most of their time working in one company's context — picked from a company switcher in the header. While in that context, everything they see and do is scoped to that client.

They can also step up to an "All companies" view to search across every client at once — for those "I know I wrote that knowledge article, but which client was it for?" moments. Cross-company search results always carry a company badge so it's obvious which client each result belongs to.

The active company is shown loudly at all times. The dangerous mistake isn't failing to find something — it's replying to a ticket while in the wrong company's context. The interface makes the current company unmistakable to prevent exactly that. See Pitfalls.

Who can see which clients — your call, no "mode" required

Different MSPs run their teams differently, and FreeITSM accommodates all of them without an install-wide switch — because access is a property of your analysts and teams, not a global mode:

• Generalist desk ("everyone supports everyone") → give all analysts access to all companies.
• Account-aligned analyst ("Jo looks after Acme and Globex; Sam looks after Initech") → grant each analyst only their clients.
• Account-aligned team ("the Acme team handles Acme + Globex") → grant a team its clients and drop analysts into it; they inherit that access — one grant instead of ticking companies on every member.

You can mix all of these freely. Access is additive: an analyst can reach a company if their own grant or any of their teams allows it.

Setting it — System → Analysts

Each analyst's add/edit dialog has an "Access all companies" toggle. Leave it on for an all-access analyst; switch it off and a checklist appears to tick exactly which companies they may work in. New analysts default to all-access. The analyst list flags anyone restricted with a small "N companies" chip. (The control only appears once you have more than one company — a single-company install never sees it.)

This is the key that the isolation locks turn. Restricting an analyst takes effect everywhere at once: their company switcher only lists their companies, their ticket lists / search / dashboards scope to those, and any attempt to reach another client's ticket by id is denied. There is no install-wide mode — access is simply a property of your analysts and their teams.

Setting it for a team — System → Teams

On a multi-company install each team gets a Manage companies action: an "Access all companies" toggle, or a checklist of specific companies. Every analyst in the team inherits that access on top of whatever they're granted directly. Team grants default to nothing — a team (new or pre-existing) grants no company access until you set it — so enabling this never silently widens anyone's access on upgrade.

Because it's additive and funnels through the same choke-point (getAccessibleTenantIds() in includes/tenancy.php unions an analyst's own grants with their teams'), the System → Analysts screen shows each analyst's effective access — direct + inherited — and team-granted companies appear there read-only, with a pointer back to Teams. The team itself stays global: it isn't owned by a company, it just carries company grants.

Auditing

Because stepping across companies is a sensitive action, cross-company views and changes are good candidates for an audit trail — planned as part of the rollout.