Security Guide Overview
Yurbi's security model controls who can sign in, what apps they can touch, which reports they can open, and what rows of data they see inside those reports. Whether you're running an internal team, a multi-tenant SaaS, or a hybrid of customer and internal users, Yurbi's security features let you scope access at the layer that fits.
What is Security in Yurbi?
Security in Yurbi is built in layers, each adding a tighter restriction on top of the one before it:
User access — does the user exist, and what apps can they use at all?
Library access — which folders and reports can they open?
Row-level access — what rows of data show up inside the reports they can open?
Per-user data routing — for the same report, can different users be pointed to different databases or schemas?
Tenant mode — an instance-wide switch that changes how content is shared between groups
Most internal teams use only the first two layers. Multi-tenant deployments typically use all of them.
Start Here: Choose Your Deployment Model
Yurbi's features serve very different deployment patterns. Before you configure anything, decide which model fits your situation:
Embedded analytics + multi-tenant SaaS — most common; uses every security feature in this guide
On-premise single-tenant internal — simplest; skips most of the advanced features
Internal multi-team — moderate; uses groups and folder permissions, sometimes RLS
Hybrid — mix of the above
The Deployment Models and Best Practices article walks each model in detail and shows which security features apply to each. Start there if you're not sure which model fits, or if you want a checklist for your specific setup.
Integrations, Apps, Folders, and Users — How the Pieces Fit
Yurbi has a few core concepts that interact in ways that aren't always obvious. Knowing the relationships ahead of time will save you confusion later.
Integration A connection to a data source — a registered server with host, port, credentials. You configure integrations in Architect.
App The semantic layer Yurbi builds on top of an integration's data. Categories, tables, joins, fields. An app may also expose direct SQL or stored-procedure access. Each app has exactly one integration, but you can register multiple integrations against the same datasource if you want separate semantic layers — for example, one app for the standard semantic layer and a separate app for direct SQL access to the same database.
Folder A container in the Library that holds reports. Folders have no relationship to apps. A folder can hold reports built from any app; permissions on the folder control which groups can see and modify the reports inside it.
Report Built against one app, saved into one folder. Inherits visibility from the folder's permissions plus the app's per-user access.
User Has an identity, group memberships, per-app roles, profile-tag values, and (per app) an optional alternate data source assignment.
Group A bundle of users. Groups are what Library folder permissions and RLS policies target. A user inherits access through the groups they belong to.
This conceptual model matters because the same app's reports can live in many folders with different audiences; one folder can hold reports from many apps; and a user's access to a report depends on both their per-app role and their group's folder permissions.
Prerequisites
Configuring security requires Admin access to Yurbi.
The Three-Layer Security Model
Yurbi enforces access in three sequential layers. A user must pass every layer to see a given row of data.
Layer 1: App Access
The user record decides whether someone can sign in and which apps they have any role on. No role on an app means the app doesn't appear in their sidebar at all.
Three roles per app: Agent (view-only), Builder (build reports and dashboards), and Architect (edit the app's semantic layer — categories, tables, joins).
Learn more: Creating Users and Assigning Access
Layer 2: Library Folder Access
Library folders are owned by groups. A user inherits access through the groups they belong to. Four actions per group: View (open), Modify (rename, create subfolders), Delete (remove), or Admin (currently the same as Delete on non-Administrator groups).
Learn more: Groups and Library Folder Permissions
Layer 3: Row-Level Security
Once a user can open a report, row-level security policies filter the rows they actually see. Policies reference profile tags (per-user values like company or region) and data tags (per-group values with defaults). Even users running the same report see different rows.
Learn more: Row-Level Security: Profile Tags, Data Tags, and Policies
Plus Two Additional Capabilities
Alternate User Data Sources
Yurbi-specific feature that lets you point different users to different databases or schemas for the same app and the same report. Register your app with a primary data source, then add alternate data sources for each customer or tenant database. On the user record, pick which alternate that user should use. They run the same report and Yurbi swaps the connection at runtime.
This is the right tool for single-tenant database models (one DB per customer) where each customer's data lives in its own physically separate database.
Learn more: Alternate User Data Sources
Tenant Mode
An instance-wide toggle that changes how Yurbi handles shared content. With tenant mode off (the default), Yurbi behaves like a single-team tool — content is broadly shared, Builders can save to common folders. With tenant mode on, sharing is explicit per-group, Builders can only modify content owned by their own group, and the "All Users" folder becomes read-only canned content.
Tenant mode is the foundation of the "build once, share with all customers" pattern that makes multi-tenant Yurbi deployments maintainable.
Learn more: Tenant Mode and Canned Content
The Two Default Groups
Before you create anyone, two groups already exist:
Administrators — visible under Settings → Security → Groups. The default home for anyone you want to grant full instance access. Empty until you put someone in it.
All Users — hidden, automatic. Every user you create lands in it without you doing anything. It's how "share everything by default" works — folder permissions and branding policies that target All Users hit everyone. You can't add or remove members; that's the point. In tenant mode, this group becomes the canned-content distribution channel.
Note: Under Settings → Server Settings there is a toggle to disable the All Users group entirely. Enable it if you don't want shared-user capability to exist at all — useful for strict deployments where admins shouldn't even have the option to accidentally create reports or folders visible to everyone. With All Users disabled, every piece of content must target a specific group; nothing is universally visible.
Intra-Group Roles
When you assign a user to a group, you set their role inside that group. Five checkboxes appear: None / Admin / View / Modify / Delete.
None — cosmetic. Equivalent to no checkboxes at all.
Admin — special meaning depending on the group:
In the Administrators group: grants full instance administrator powers.
In any other group: currently behaves the same as Delete (manages folders and reports owned by that group).
View / Modify / Delete — actions on the folders and reports that target this group. View = open them. Modify = rename them and create subfolders. Delete = remove them.
Important: If you want to make someone a full administrator, you must check the Admin column on the Administrators group row. Checking View, Modify, or Delete on the Administrators group does not grant admin — it grants access to folders and reports that target the Administrators group (typically audit reports), without giving them administrator powers.
Getting Started
We recommend configuring security in this order:
Read Deployment Models and Best Practices to pick the model that fits your situation
Create a backup admin before you do anything else — a second user with Admin on the Administrators group, credentials stored somewhere durable
Create your users and assign their group memberships and per-app roles
Set up custom groups if you have multiple teams or tenants that need different access
Configure Library folder permissions so each group sees the right reports
Set up Alternate User Data Sources if you need per-user database routing
Add Row-Level Security policies if users on the same database need to see different rows
Enable Tenant Mode if you're running a multi-tenant deployment
Most deployments skip several of these steps. The Deployment Models article shows you which apply to your specific model.
Key Capabilities
Per-Tenant or Per-Group Access
Group-based permissions let you isolate tenants completely or share content selectively between them. Combined with Library folder targeting and Row-Level Security, you can run a multi-tenant deployment where every customer sees only their own data without duplicating reports.
Per-User Database Routing
Alternate User Data Sources extend that isolation to the physical database level — useful when each customer has their own database rather than sharing a schema.
Build Once, Share with All
Tenant mode plus Row-Level Security enables the canned content pattern: one report, served to all tenants, filtered per-user. The alternative — one copy per tenant — multiplies maintenance work by your customer count. Yurbi's Scale tier also offers Sync Server for keeping multiple report copies in sync if your model requires it.
Important: When Security Changes Take Effect
For most security changes: group memberships, app roles, profile tags, RLS policies, and folder permissions take effect on the user's next request — usually within a refresh.
For tenant mode changes: the toggle is instance-wide and takes effect immediately, but Builders and Architects already in a session may need to sign out and back in to see the restricted behavior.
For new branding policies: see the Branding Guide Overview — branding loads at login time and requires logout/login to see changes.
Additional Resources
Branding: Security controls what users can do; branding controls what they see in the interface. See the Branding Guide Overview for visual customization, feature toggles, and per-tenant branding policies.
Deployment Models: For deployment-specific guidance and which features apply to which use case, see Deployment Models and Best Practices.
Multi-Tenant Walkthrough: For an end-to-end worked example combining users, groups, folder permissions, RLS, and tenant mode, see Multi-Tenant Setup Walkthrough.
Need help with security configuration? Contact our support team or check out the specific articles below for detailed instructions.