Tenant mode — instance-level isolation
A single server-side switch that hardens every layer you've built. Off by default — designed for two specific situations.
By the end of this lesson
- A clear decision about whether your instance needs tenant mode
- If yes, tenant mode enabled with behavior changes verified across personas
- A grasp of the canned-content pattern — build once, share with many
You'll need
- Admin role in DashboardFox
- Module 4 lessons 2–4 complete (or skipped intentionally)
- Server settings access
Background
Tenant mode is one toggle in Server Settings. Off, you have the friendly-internal-team default behavior — Composers can manage shared library folders, every user is visible to every other user in the scheduler, All Users is a writable shared space. On, the boundaries between groups harden across every layer.
Tenant mode is off by default. That's the right setting for the most common case — a single internal team where Composers manage the library, everyone shares data, and folder permissions plus RLS are all the security you need. Most teams never turn it on. Read this lesson to decide whether you should.
Two scenarios where tenant mode earns its keep
Distinct customer organizations sharing one DashboardFox instance. A hosted product. An MSP serving end clients. A portfolio of business units that should feel separate.
Tenant mode prevents one customer's users from seeing another customer's users in scheduler dropdowns, prevents cross-customer folder management, and turns shared content into read-only canned content.
A small internal team that nonetheless wants to prevent Composers from accidentally deleting or renaming production reports. Default Composer behavior on All-Users folders is permissive — sometimes too permissive for production environments.
Tenant mode is the simplest way to make shared folders effectively read-only for everyone except admins, without building elaborate group structures.
If neither scenario fits, leave tenant mode off. Module 4 is feature-complete for single-tenant teams at the end of row-level security.
What tenant mode is NOT
Tenant mode doesn't replace folder permissions or RLS — it hardens them. The three layers (app access, folder access, row access) still do their work. Tenant mode adds a fourth, cross-cutting layer that changes how Composer permissions interact with shared content and how user visibility works in scheduling.
Related setting: disable the All Users group entirely
Server Settings has a separate toggle to disable the All Users group. With it on, the All Users group is removed as a permission target across the whole instance — admins can no longer create folders, branding policies, or RLS assignments that hit "everyone."
This is one step stricter than tenant mode. Tenant mode locks down who can save into All Users folders; the All Users disable toggle removes the All Users group as a concept so no shared-with-everyone content can exist at all.
- Use this when you want zero risk of admins accidentally creating content visible to all clients, or you're not using the canned-content pattern at all (so the All Users distribution channel isn't needed).
- Don't use this when you rely on canned content — disabling All Users removes the distribution channel that canned content depends on.
For most agency multi-client deployments, leave All Users enabled and use tenant mode to control sharing. The disable toggle is a belt-and-suspenders setting for strict deployments where canned content isn't part of the model.
Stuck on whether your setup needs tenant mode, or seeing unexpected behavior after turning it on? Email team@dashboardfox.com with what changed and what you expected. Real human, same business day.
Before you start
- A decision on which scenario applies to your instance (or that neither does, in which case skip this lesson).
- For multi-tenant: confirmation that your groups follow "one group per tenant, never mingled." If you have a mixed-tenant group anywhere, fix that first (lesson 3) — tenant mode amplifies the consequences of mingling.
- For single-tenant lockdown: agreement from your Composers that reduced folder/report management capabilities on shared content is acceptable. They'll still have full control over folders permissioned to groups they're in.
- Test users ready. One per scope you want to verify — a Composer in Group A, a Composer in Group B, an Agent in a third group, an admin outside any tenant group.
- A backup plan. Tenant mode is a server-level switch — turning it back off restores the prior behavior. There's no migration step in either direction.
Do it
-
Open Server Settings
Go to Settings → Server Settings (sibling of the Security tab). This page contains instance-wide configuration — most of which is covered in Module 6.
Find the Enable Tenant Mode toggle. Default is off.
-
Turn on tenant mode
Toggle Enable Tenant Mode on. Click Save.
You'll also see a Disable All Users Group toggle. Don't turn this on. It removes the hidden All Users group entirely — a setting reserved for instances where even the existence of the implicit "everyone" group is a security concern. Most teams that turn it on regret it within a week. Leave it off unless you've had a specific conversation with our team about why you need it.
-
Verify the changes — what tenant mode now enforces
The cleanest way to see what changed is to log in as the same Composer user you had before, and notice what's different. Here's the definitive list of behaviors that change:
-
Verify as an Agent (multi-group)
If you have an Agent who's a member of two groups, log in as them and try to schedule a report. The recipient picker should now show only members of those two groups — not every user in the instance.
This is the multi-tenant payoff in action: customer A's users don't even see the existence of customer B's users.
-
Verify as a Composer (single-group)
Log in as a Composer who's in, say, the Finance Team group. Open Documents:
- The All Users parent folder — they can see it and run reports inside it, but no edit or add-subfolder options appear. No delete on its reports.
- The Finance Team folder (their group) — full management: edit, add subfolders, modify and delete reports.
- Other groups' folders (Customer Support, etc.) — not visible at all.
That's the pattern: Composers manage their own group's content; All Users content is canned.
-
Decision — keep tenant mode on, or turn it back off?
Tenant mode is reversible. If the verification surprises you in the wrong direction — too restrictive for your culture, breaking workflows you didn't anticipate — toggle it back off. If it does what you wanted, you're done.
Most teams that try tenant mode and don't fit either scenario find it too restrictive within a few days. If you're hesitant, run it for a week and see how your Composers react. The cost of toggling back is zero.
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
Patterns that make tenant mode actually pay off.
The canned-content pattern — build once, share with many
Tenant mode unlocks one of DashboardFox's most powerful patterns: build a report or dashboard once, then share it with every tenant — each one sees their own slice of the data. Three layers work together to make this safe:
- Folder permission to All Users — every tenant can see the report exists.
- RLS filtering by tenant tag — each tenant sees only their data inside it.
- Tenant mode making All Users read-only — no tenant can edit or delete the shared report.
The alternative is making a separate copy of every report and dashboard for every tenant. With three tenants and twenty reports, that's sixty objects to maintain. Every time you fix a bug or add a feature to the report, you have to apply the change in three places. With six tenants, six places. With a hundred tenants, hopeless.
Canned content collapses this to one object, edited once. Every tenant gets the update instantly. RLS guarantees their view of the data is still their own.
The only alternative for per-tenant report copies is the Sync Server feature on Scale tier, which keeps multiple report copies in sync programmatically. Canned content is simpler when it fits — and it fits most of the time.
The multi-group walkthrough shows this pattern in action across two tenants. Read it once and the shape will click.
Never mingle customers in one group
With tenant mode on, group membership controls user visibility in scheduling. A group containing users from two different customers leaks identities — customer A's users see customer B's users in the recipient picker when scheduling reports.
The pattern: one group per tenant, no exceptions. If you need a "all customer builders" capability for internal admin convenience, build it on the admin side (an admin role, an internal-only group) — never by mingling external users.
Combine with per-group branding for full isolation
Tenant mode handles user visibility and folder management. Branding (Module 5) handles look and feel — logo, colors, sidebar features, even custom login domains per tenant. Together they produce true isolation: a tenant sees their branding, their users, their folders, their rows, and nothing else.
The multi-group walkthrough covers wiring all of this together in one running example.
Pair with a Modify/Delete role on tenant groups
When tenant mode strips Composer abilities on All Users folders, you may still want some users to manage their own group's content. The pattern: give those users Modify or Delete on their specific group (in Group Assignments on the user record). They'll have full management on their group's folders without affecting their canned-content-only access to All Users folders.
This is what makes tenant mode practical day-to-day — power users still have organizational control, but it's scoped to their tenant.
Test as each persona after every structural change
The full test loop with tenant mode on: an Agent in one group, a Composer in their own group, a Composer in two groups, an admin. Each one should see the right folders, the right scheduler recipients, the right Composer-management capabilities. Five minutes per change.
With tenant mode on and the patterns above in place, you're ready for the integration walkthrough: a complete two-tenant configuration from users through branding.
If you're stuck
What surprises people most often after enabling tenant mode.
My Composers can't do anything now
That's the point of tenant mode for the single-tenant lockdown scenario. If it's too restrictive, give Composers Modify on their own group(s) so they have full management on their team's folders without restoring write access to All Users. If you want them to manage All Users folders too, tenant mode probably isn't the right tool — turn it off and use Module 5 branding for separation instead.
A user in two groups sees more recipients than I expected in scheduling
Working as designed. Tenant mode scopes scheduler visibility to "users who share at least one group with the scheduler." Someone in groups A and B can schedule to anyone in A and anyone in B. If you want stricter isolation, the user shouldn't be in both groups — split into separate roles or use admin-only schedule management.
My All Users folder is now read-only for Composers
Working as designed — the canned-content pattern. For editable shared content, create a folder owned by a non-All-Users group that includes the editors. They'll have full management on that folder, and viewers can still see it (folder permissions can stack — see lesson 3).
An admin still bypasses everything
Working as designed. Tenant mode hardens non-admin behavior; admins retain full instance access. If you need to restrict admins themselves (e.g., a customer admin who shouldn't see other tenants), the conversation is about your role assignments rather than tenant mode. Email our team to talk through it.
I turned on "Disable All Users Group" by mistake and now things are broken
Turn it back off and re-save. Existing All Users folder permissions persist; the implicit group reappears. If you had folders that relied on All Users that you've now repermissioned manually, you may need to clean those up.
Tenant mode is on but cross-tenant data is still showing up
Tenant mode doesn't filter data rows — that's RLS's job. If a customer is seeing another customer's data inside a shared report, the report doesn't have RLS, or the RLS policy isn't scoped correctly. Revisit lesson 4 and make sure each shared report's category has an RLS constraint with the tenant tag.
None of these match my situation
Email team@dashboardfox.com with what you turned on, what you expected, and what you're seeing. Tenant mode interactions can be subtle — we'll trace it with you. Same business day reply.
