Deployment Models and Best Practices
Yurbi serves a wide range of use cases. Most customers run embedded analytics for multi-tenant SaaS products; others run on-premise single-tenant deployments for internal use; some run multi-team internal setups where different departments need different access; and many run hybrids of these. This article helps you pick which security features apply to your deployment, in what order to configure them, and what the long-term best practices look like for your model.
Read this article first. It will save you time by letting you skip the features that don't apply to your deployment.
When This Applies
Read this article before you start configuring users, groups, or policies. If you've already configured your instance, use this article as an audit checklist — verify your setup matches the recommended pattern for your deployment model.
Prerequisites
This article is informational and doesn't require any configuration to read. To act on its recommendations you'll need Admin access to Yurbi.
The Four Common Deployment Models
Model 1: Embedded Analytics + Multi-Tenant SaaS
What it looks like: You're a SaaS company. Your customers (tenants) use your application, which embeds Yurbi reports and dashboards. Each customer's data is isolated from other customers' data — either by row (shared database with a customer-identifier column) or by database (separate database per customer). Maintenance happens centrally — you build reports once and serve them to every customer.
Who uses it: Most Yurbi customers. SaaS products of all sizes from startup to enterprise.
Features you need:
Custom groups (one per tenant)
Library folder permissions (per-tenant)
Row-Level Security or Alternate User Data Sources (data isolation)
Tenant Mode (lock down sharing)
Canned content pattern (build once, share with all)
Per-tenant branding (optional but common)
The Multi-Tenant Setup Walkthrough is the canonical setup for this model.
Model 2: On-Premise Single-Tenant Internal
What it looks like: Yurbi is installed on your infrastructure and used by your own team only. There are no external customers. Every user is internal staff who should see most or all of the data. Permission boundaries are about roles (admins vs. analysts vs. viewers) rather than tenants.
Who uses it: Internal BI deployments, IT operations teams, finance departments using Yurbi for internal reporting.
Features you need:
Users with appropriate per-app roles (Agent / Builder / Architect)
A backup admin
(Optional) Library folder permissions if some reports are sensitive to certain roles
Features you typically don't need:
Custom groups beyond the default Administrators
Row-Level Security
Tenant Mode
Alternate Data Sources
Canned content pattern
The simplest possible setup: create users, assign per-app roles, done. The hidden All Users group handles sharing automatically.
Model 3: Internal Multi-Team
What it looks like: Yurbi is used internally, but different teams (Sales, Finance, Marketing, Operations) should see different content. Some reports are universal (shared across teams), others are team-specific. Users typically belong to one team but admins see everything.
Who uses it: Mid-sized to large internal BI deployments serving multiple departments from one instance.
Features you need:
Custom groups (one per team)
Library folder permissions (per-team folder structure)
(Optional) Row-Level Security if teams share databases but should see different rows
Features you typically don't need:
Tenant Mode (you generally want some cross-team sharing)
Alternate Data Sources
Per-team branding (one corporate brand usually applies)
Setup pattern: create per-team groups, create per-team folders, assign users to their team's group with View, and let the All Users group handle universally shared reports.
Model 4: Hybrid Deployments
What it looks like: Combinations of the above. Common hybrids:
Embedded multi-tenant + internal staff using the full Yurbi UI. Most common hybrid. Customers see embedded views; your internal team uses the full Yurbi instance with admin powers.
Multi-tenant for some apps + single-tenant for others. When some data is shared (a public reference dataset) and other data is per-customer.
Single-tenant per customer (each customer has their own Yurbi instance) + per-instance internal multi-team. Less common; more setup but full isolation.
Features you need: Whichever of the above fit each portion of your deployment. The Multi-Tenant Walkthrough covers the embedded-multi-tenant + internal-staff combination, which is the most common hybrid.
Feature Applicability Matrix
Quick reference for which Yurbi security features each deployment model uses:
Feature | Embedded Multi-Tenant | On-Prem Single-Tenant | Internal Multi-Team |
|---|---|---|---|
Backup admin | Required | Required | Required |
Per-app role assignment | Required | Required | Required |
Custom groups | Required (per tenant) | Not needed | Required (per team) |
Library folder permissions | Required (per tenant) | Optional | Required (per team) |
Profile tags | Required (Company at minimum) | Not needed | Sometimes |
Data tags | Sometimes | Not needed | Sometimes |
Row-Level Security | Required (shared DB) | Not needed | Sometimes |
Alternate Data Sources | Required (separate DBs) | Not needed | Rarely |
Tenant Mode | Required | Not needed | Not recommended |
Disabling All Users group | Optional (extra strictness) | Not recommended | Not recommended |
Per-tenant branding | Common | Not needed | Sometimes |
Canned content pattern | Recommended | Not applicable | Optional |
Recommended Setup Order Per Model
Setup for Embedded Multi-Tenant
This is the Multi-Tenant Setup Walkthrough in checklist form:
[ ] Create a backup admin
[ ] Confirm data isolation strategy (shared DB + RLS, or separate DBs + alternate data sources, or hybrid)
[ ] Enable Tenant Mode
[ ] Set Library folders to default-target All Users group only (canned content distribution)
[ ] Create a group per tenant — one group per tenant, never combined with another tenant
[ ] Create a root-level or sub-folder per tenant, targeting only that tenant's group
[ ] If using shared DB: create a data tag (or rely on the Company profile tag) and create an RLS policy
[ ] If using separate DBs: configure Alternate Data Sources per tenant
[ ] Create users — assign to their tenant group with appropriate role + per-app roles + (if applicable) alternate data source assignment
[ ] (Optional) Create per-tenant branding policies
[ ] Test as a tenant user, then as another tenant user, then as admin
Setup for On-Premise Single-Tenant Internal
[ ] Create a backup admin
[ ] Register your app(s) in Architect
[ ] Create users with appropriate per-app roles (Agent / Builder / Architect)
[ ] (Optional) Configure default Library folder structure
[ ] (Optional) Set up role-based branding if you want a different look for Builders vs. Agents
Done. The default All Users group handles sharing automatically.
Setup for Internal Multi-Team
[ ] Create a backup admin
[ ] Create a group per team (Sales, Finance, etc.)
[ ] Create a top-level Library folder per team, targeting that team's group with View + Modify
[ ] Optionally create a "Shared Reports" folder targeting All Users for universal reports
[ ] Create users — assign to their team's group plus appropriate per-app roles
[ ] (Optional) If teams share a database and should see different rows, set up Row-Level Security
Best Practices Across All Models
Always create a backup admin first. The day you lock yourself out is rarely the day you planned for it.
Don't mingle tenants or unrelated teams in the same group. A group should represent one clearly-bounded set of users. The All Users group is the only legitimate shared group; never recreate that pattern with custom groups. Mingling defeats the isolation guarantees Tenant Mode provides and makes scheduling and sharing dialogs leak information across tenants.
Decide your deployment model before you start configuring. Mid-setup pivots from "internal multi-team" to "multi-tenant" require reworking groups, folder permissions, and possibly database structure. Pick the right model up front.
Document the model you chose. Future admins (and future-you) will thank you. A one-page note saying "we run embedded multi-tenant with separate databases per customer; alternate data sources are at the app level; Company profile tag identifies the tenant" saves weeks of archaeology.
Test as each persona before going live. Sign in as a representative user from each role and verify what they see. This catches more configuration mistakes than any other practice.
Audit periodically. Twice a year: review group memberships, folder permissions, RLS policies, and per-app role assignments. Drift is real.
Match folder structure to your model. Parent-per-team folders for clean isolation, shared-parent-plus-subfolders for hybrid sharing. Pick one pattern and apply it consistently.
Common Gotchas Across All Models
"My admin user is being filtered by RLS." Either (1) the admin is in a group that's been assigned to the RLS policy, or (2) the policy is assigned to All Users (which includes the admin). Decide whether you want admins filtered or not, and structure assignments accordingly. See Row-Level Security.
"Reports built before we turned on Tenant Mode broke." Tenant Mode applies new restrictions to save/edit operations; existing reports stay where they were. But if existing reports were in folders that no longer fit the canned-content model (e.g., a customer Builder owned a report in an All Users folder), Tenant Mode may make that report effectively orphaned. Audit before flipping the toggle. See Tenant Mode and Canned Content.
"Schemas drifted across alternate data sources and reports broke." Alternate Data Sources assume identical schemas. Add a column to one customer's database without adding it to the others, and reports break for users on the lagging databases. Use a migration tool or process to keep schemas in sync. See Alternate User Data Sources.
"A user is in three groups and we can't figure out why they see what they see." Yurbi permissions are cumulative across group membership. If a user is in groups A, B, and C, they get the union of permissions from all three. The fastest debugging path: sign in as the user, see what's visible, then check each group's folder permissions one at a time.
"We tried to mingle tenants in a group to share content between two customers." Don't do this. The only legitimate cross-tenant sharing is via the All Users group. Mingling in custom groups breaks tenant isolation and causes scheduling and sharing dialogs to leak member names and folder names across tenants.
"Our setup works but onboarding a new customer takes 2 hours." You've drifted from the canned-content pattern. The fix is usually: (a) move per-customer report copies into a shared All Users folder, (b) ensure RLS handles the data scoping rather than report duplication, (c) reduce per-customer custom branding to a templated process. See Multi-Tenant Setup Walkthrough.
Remember: Your deployment model determines which Yurbi features matter. Read this article first, configure only what you need, and revisit it when your model changes.