Tenant Mode and Canned Content
Tenant Mode is an instance-wide setting that changes how Yurbi handles content sharing. With it off (the default), Yurbi behaves like a single-team tool — content is broadly shared, Builders can save reports to common folders, everyone in the All Users group sees everything. With it on, sharing becomes explicit per-group, Builders can only modify content owned by their own group, and the All Users folder becomes read-only canned content that admins control.
The canned-content pattern is what makes multi-tenant Yurbi deployments maintainable. This article covers the tenant mode toggle, what it actually changes, and how to use canned content to serve many customers from one set of reports without duplicating work.
When Tenant Mode Applies
Turn on Tenant Mode when:
You're running a multi-tenant deployment where customers share one Yurbi instance
You want to ensure customer Builders can't accidentally save reports into folders other customers can see
You want to build a library of "canned" reports that all tenants run, with row-level security scoping the data per customer
You need a clear separation between admin-controlled content (in All Users) and tenant-controlled content (in per-tenant folders)
Leave Tenant Mode off when:
You're running a single-team internal deployment
All your users should be able to share content freely with each other
You have no per-customer or per-tenant isolation requirements
Prerequisites
Changing Tenant Mode requires Admin access to Yurbi.
Before turning it on, you should have:
Per-tenant groups created (see Groups and Library Folder Permissions)
Library folder structure that supports per-tenant content
Row-level security policies in place if customers share a database (see Row-Level Security)
Or Alternate User Data Sources configured if each customer has their own database (see Alternate User Data Sources)
Tenant Mode is the enforcement layer on top of the access layers below it. Configure those first, then flip Tenant Mode on.
What Tenant Mode Actually Changes
When you enable Tenant Mode, four things change:
1. The All Users Folder Becomes Read-Only for Non-Admins
The hidden All Users group still includes every user automatically, but folders that target All Users behave differently:
With Tenant Mode off: Builders can save reports into All Users folders. Content there is shared with everyone, including each other.
With Tenant Mode on: Only admins can save into All Users folders. Builders and Architects from non-admin groups can read All Users content but cannot modify it. This is the canned-content distribution channel.
2. Builders Can Only Save to Folders Their Group Owns
Without Tenant Mode, a Builder can save a report to any folder they have Modify access on, which might span multiple groups' folders. With Tenant Mode on, Yurbi enforces that Builders save to folders owned by their own group only.
This prevents the common mistake of a customer's Builder accidentally saving a report into a folder visible to other customers.
3. Architects Are Scoped to Their Group's Content
Same restriction as Builders, but for the Architect role. An Architect can only edit semantic-layer elements (categories, joins) within the scope of their group. Cross-group editing is admin-only.
4. The Default Sharing Behavior Flips
Without Tenant Mode, new reports default to widely shared (visible to All Users unless restricted). With Tenant Mode on, new reports default to private-to-group (visible only to the Builder's group unless explicitly shared).
This is the most important behavioral change. The "secure by default" posture means customer Builders can't leak reports by forgetting to set permissions.
Enabling Tenant Mode
Navigate to Settings → Server Settings → Tenant Mode
[SCREENSHOT: Server Settings page showing the Tenant Mode toggle]
Toggle Tenant Mode on. The change is instance-wide and takes effect immediately.
Important: Users already in an active session may need to sign out and back in for the new restrictions to take effect in their UI. Existing reports and folders are unaffected — only new save and edit operations follow the new rules.
Before you flip it on, verify:
Every tenant group has its own folder structure with the right permissions
Customer users are assigned to exactly the right group (no accidental cross-membership)
Your canned-content reports (the ones meant for all tenants) live in folders targeting All Users — these become read-only after the flip
You're not relying on Builders to save into cross-tenant folders anywhere
Turning Tenant Mode on after the fact, on an instance that wasn't set up for it, can surface configuration issues. Walk through the Multi-Tenant Setup Walkthrough before flipping the toggle on production.
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 entire 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 tenants
Every piece of content must be explicitly assigned to a specific group
You're not using the canned-content pattern (so the All Users distribution channel isn't needed)
Don't use this when:
You rely on the canned-content pattern (you need All Users folders for shared reports)
You're running internal multi-team or single-tenant deployments where universally-shared content is useful
Your branding policies use All Users as the default audience
For most multi-tenant deployments, leave All Users enabled and use Tenant Mode to control sharing. The All Users disable toggle is an additional belt-and-suspenders setting for strict deployments.
The Canned Content Pattern
This is the pattern that makes Tenant Mode worth using. Once you understand it, multi-tenant Yurbi gets much simpler.
The Problem It Solves
Without canned content, supporting 20 customers means one of two paths:
Path A: Copy reports per customer. You build a "Monthly Revenue" report for Customer 1. Customer 2 wants the same report — you duplicate it into their folder. Customer 3 wants it — duplicate again. By customer 20, you have 20 copies of the same report. Every time you fix a bug or add a column, you fix it 20 times. Every time you add a customer, you copy 20 reports. Maintenance scales linearly with customer count, and that's before any divergence between copies.
Path B: Use canned content. You build the report once, in a folder targeting All Users. Every customer sees the same report. Row-level security (or alternate data sources) scopes the data per customer, so each customer's view shows only their data. When you fix a bug, you fix it once. When you add a customer, no report changes are needed — the new customer's user record (with the right group and profile tags) automatically gets filtered correctly.
How It Works
The pieces:
Tenant Mode is on. All Users folders become admin-controlled canned content.
You (an admin) build the canned reports in folders targeting All Users with View permission. Customers can run these reports but not modify them.
Row-level security or alternate data sources scope the data per customer. A report query returns different rows for different users based on their group / profile tags.
Customers run the same reports but see only their own data. They can't modify, share, or break the underlying report.
Per-customer folders also exist for customer Builders to save their own work. Customer A's Builder saves to Customer A's folder; Customer B's Builder saves to Customer B's folder. Neither can touch the canned content.
What You Maintain
In a canned-content setup, you maintain:
The canned report library (in All Users folders) — built once, used by everyone
Per-customer groups and their users
Profile-tag values on each user (Company, etc.) so RLS scopes correctly
Optionally, per-customer alternate data sources if each customer has their own database
You do not maintain duplicate copies of the same report.
When Canned Content Isn't the Right Fit
The pattern doesn't work for everyone. Two cases where you'd skip it:
Customers genuinely need different reports. If Customer A wants a Revenue dashboard and Customer B wants a Pipeline dashboard, you're not running canned content — you're running per-customer content. That's fine; Tenant Mode still helps by isolating them.
You need report copies that diverge over time. Some teams maintain a baseline report plus customer-specific overrides on top. The baseline lives in canned content; the overrides are per-customer copies. This is a hybrid model — most reports are canned, a few are duplicated.
Yurbi Scale Tier — Sync Server. If your model requires copies per customer but you want them kept in sync automatically, Yurbi's Scale tier includes Sync Server, which can propagate changes from a template to its copies. This gives you the per-customer-copy model without the manual sync burden. Contact Yurbi support if Sync Server is relevant for your deployment.
Common Configuration Scenarios
Scenario 1: Pure Canned Content (Recommended for Most Multi-Tenant)
Goal: All reports built once, served to all customers, data scoped per customer
Enable Tenant Mode
As an admin, build reports in folders targeting All Users with View
Set up row-level security so each user sees only their own rows
Customer Builders can still save private reports to their own group's folders if needed
Maintenance: one place for shared reports, customer folders for customer-specific work
Scenario 2: Hybrid — Canned Plus Per-Customer Customizations
Goal: Most reports shared, some customers get bespoke reports
Enable Tenant Mode
Build the shared library in All Users folders
For customers who need custom reports, create them in that customer's group's folder
The customer's Builder can edit their custom reports but not the canned ones
Scenario 3: Pure Per-Tenant (No Canned Content)
Goal: Each customer has entirely separate reports
Enable Tenant Mode for the isolation guarantees
Don't put reports in All Users folders
Each customer's Builder creates and maintains their own folder of reports
You'll likely use this if customers' needs diverge significantly, or if you offer a "managed service" tier where you build per-customer
Scenario 4: Single-Team Internal (Tenant Mode Off)
Goal: Internal team where everyone collaborates on the same reports
Leave Tenant Mode off (this is the default)
Builders share content freely through All Users folders
Folder permissions still work — you can restrict specific folders to specific teams without enabling Tenant Mode
Best Practices
Decide on Tenant Mode before onboarding your first customer. Flipping it on after you have 10 customers requires more cleanup than doing it right from day one.
Don't mingle tenants in custom groups. The All Users group is the only legitimate shared group in Yurbi. Custom groups should always represent one tenant. Mingling tenants in a group breaks Tenant Mode's isolation guarantees and leaks information across tenants in scheduling and sharing dialogs.
Use canned content aggressively. If two customers could use the same report (with RLS scoping the data), make it canned. Per-customer copies should be the exception, not the rule.
Keep the canned library small and high-quality. Every canned report serves every customer. Polishing one report is more valuable than building three mediocre ones.
Document which reports are canned. When customer support asks "where did this report come from?", you need to know quickly whether to fix it in one place or per-customer.
Test as a customer Builder before going live. Sign in as a Builder in a customer group. Verify they can save to their own folder but not into All Users folders. Verify they can read canned content but not modify it. Verify they don't see other customers' folders.
Plan for "the new customer in 30 minutes" workflow. With canned content, onboarding a new customer should be: create the group, create the user, set profile tags, done. They immediately see the canned library with their own scoped data. If onboarding takes longer than that, your setup may have drifted from the pure canned-content model.
Don't forget the Administrators group is separate. Admins are not in the per-customer groups (usually). They see everything because they have Admin on the Administrators group, which bypasses tenant restrictions.
When Changes Take Effect
Tenant Mode toggle: instance-wide, immediate. New save and edit operations follow the new rules.
Existing reports and folders: unaffected. Already-saved content stays where it is with the permissions it has.
Active user sessions: may need a refresh or re-login to see UI changes (e.g., the "Save to..." dropdown's available folders).
Common Issues
Builder says "I can't save my report anymore." Tenant Mode is now on and they're trying to save into a folder their group doesn't own. Have them save to their group's folder, or move the target folder's permissions to include their group with Modify access.
Customer reports their dashboard is gone. Most likely cause: an admin moved a canned report or changed its folder permissions. Check the report's current location and permissions. Canned content should live in folders targeting All Users with View.
Two customers see each other's data. Tenant Mode prevents cross-tenant content mixing but doesn't filter data — that's RLS's job. Check the row-level-security policies on the relevant app.
Builder can read All Users content but can't copy it to their own folder. This is by design — All Users canned content is read-only. If a customer needs a variant, they should build their own from scratch in their own folder, or you can copy it for them as an admin.
"I turned on Tenant Mode and everything broke." The instance wasn't set up for it. Most common causes: (1) reports that should be canned are in folders targeting specific groups instead of All Users, (2) users are in multiple groups including All Users + a customer group, causing ambiguous ownership, (3) Builder workflows assumed they could save to other customers' folders. Turn it off, fix the issues, turn it back on. The Multi-Tenant Setup Walkthrough is the pre-flight checklist.
Remember: Build once, share with all. Canned content plus RLS is what makes multi-tenant Yurbi maintainable.