Groups and Library Folder Permissions
Groups bundle users together so you can grant access to many people at once. Library folder permissions then point at those groups to decide who can open which reports. Together they're how you control the second layer of Yurbi's security model: which reports each user can actually see.
When This Applies
You'll work with groups and folder permissions when:
Onboarding a new team that needs its own private reports
Adding a new customer to a multi-tenant deployment
Restructuring the Library so different teams see different content
Moving a user from one team to another
Sharing specific folders across multiple groups
Prerequisites
Configuring groups and folder permissions requires Admin access to Yurbi.
Have your users already created. See Creating Users and Assigning Access if you haven't.
The Two Default Groups
Before you create anything, two groups already exist:
Administrators — visible under Settings → Security → Groups. The default home for full instance admins. Folders that target the Administrators group are visible to anyone with View, Modify, Delete, or Admin on it.
All Users — hidden, automatic. Every user lands here without you doing anything. Folders that target All Users are visible to everyone. You can't add or remove members; the membership is every user. This is how the "share everything by default" model works on a single-team Yurbi instance.
For a small internal team where everyone sees everything, these two groups are often all you need. Custom groups become necessary when different teams or tenants should see different content.
Group Strategy: When to Add Custom Groups
Add a custom group when at least one of these is true:
A set of users needs access to folders that other users shouldn't see
A set of users needs different row-level-security filtering than others
A set of users needs different branding or feature toggles
You want to bulk-assign app roles or permissions to a stable set of people
If none of these apply, the default groups handle it.
Creating a Group
Navigate to Settings → Security → Groups
[SCREENSHOT: Settings → Security → Groups page showing the existing groups list and Create New Group button]
Click Create New Group. A side panel opens with the group form.
General Information
Name Required. Use a name that describes who's in the group, not what they can do — "Acme Corp", "Finance Team", "External Auditors". Permissions can change; the people don't.
Description Optional, but recommended for any non-obvious group. Helps other admins (and future-you) understand why the group exists.
Adding Members
Scroll to the Members section. Every user appears as a row with the same five intra-group role checkboxes you saw on the user form: None / Admin / View / Modify / Delete.
[SCREENSHOT: Group Edit panel — Members section with user rows and role checkboxes]
The roles work exactly as they do on the user form:
None — cosmetic; equivalent to no checkboxes
Admin — on the Administrators group, full instance admin. On any other group, currently the same as Delete
View / Modify / Delete — actions on the folders and reports that target this group
For most members, check View. The other roles are for users who need to manage the group's content.
Click Save & Apply.
Library Folder Permissions
Folder permissions are what make a group meaningful. Without them, a group is just a label.
How Folder Permissions Work
Every folder in the Library has a list of groups it targets. Each group has an action on that folder: View, Modify, or Delete (Admin gives the same as Delete on non-Administrator groups).
A user can perform an action on a folder if any of their groups has that action on the folder. Permissions are cumulative — if a user is in two groups and one of them has View on a folder, the user sees it.
Folders are independent of apps. A folder is just a container for reports. Any report can be saved into any folder regardless of which app the report was built against. Folders don't inherit permissions from apps, and apps don't restrict which folders their reports can live in. The folder controls who can see the report; the app controls what the report can query.
Single-Group Membership Helps with Tenant Isolation
A quiet but important property of Yurbi: when a user is in only one custom group (plus the hidden All Users group), the schedule, share, and save dialogs filter the available choices to that user's group only. A tenant Builder who's only in the "Acme Corp" group sees only Acme members in the schedule recipient list, only the Acme folder when saving a new report, only Acme as the target group in sharing dialogs.
If you mingle tenants in the same group, that isolation breaks — members of one tenant would see members of another tenant in those dialogs. This is why the "don't mingle tenants" rule below matters; it's not just about access permissions, it's also about what users see in everyday workflows.
Setting Permissions on a Folder
Navigate to Library → Right-click any folder → Permissions
[SCREENSHOT: Library folder context menu with Permissions option highlighted]
The Permissions dialog lists every group. For each, check the actions you want to grant:
[SCREENSHOT: Folder Permissions dialog with groups and View/Modify/Delete checkboxes]
View — group members can open the folder and the reports inside it
Modify — group members can rename the folder and create subfolders
Delete — group members can remove the folder and its contents
A folder with no permissions checked is invisible to everyone except admins.
Inheritance: by default, new folders inherit the permissions of their parent. You can override per-folder once it's created.
Two Common Folder Strategies
Two patterns cover most Yurbi deployments. Pick one and apply it consistently.
Strategy A: Parent-Per-Team
Each team gets its own top-level folder. Sales folder, Finance folder, Marketing folder. Each parent targets only its team's group. No crossover by default.
Use this when:
Teams are mostly independent and don't share content
Easy to explain — "your team's stuff lives in your team's folder"
New teams = new top-level folder, no restructuring
Tradeoff: sharing content between teams means creating it in two places or moving it to a shared parent.
Strategy B: Shared Parent Plus Subfolders
One parent folder visible to multiple teams, with team-specific subfolders inside. "Reports" parent targets all teams with View. Inside it, "Sales Reports" subfolder targets only Sales with View, "Finance Reports" subfolder targets only Finance with View.
Use this when:
Teams have a mix of shared and private content
You want a single navigational entry point for everyone
Most reports cross team boundaries; only some are restricted
Tradeoff: the parent's permissions can leak — if you give everyone View on the parent, they'll see the subfolder names even if they can't open them. Most teams find this acceptable; some don't.
You can mix strategies. A typical multi-tenant deployment has parent-per-tenant for customer content, plus a shared "Templates" parent visible to internal builders.
Common Configuration Scenarios
Scenario 1: Single Internal Team
Goal: Everyone sees everything
Don't create custom groups
Don't override folder permissions
Default behavior: everyone is in All Users; folders are visible to everyone
Done in zero clicks.
Scenario 2: Multiple Internal Teams
Goal: Sales sees Sales folders, Finance sees Finance folders, admins see both
Create one group per team (Sales, Finance)
Add users to their team's group with View
Create a top-level folder per team (parent-per-team strategy)
Set each folder's permissions to View on its team's group only
Administrators see everything because they have Admin on the Administrators group
Scenario 3: Shared Reports Plus Private Reports
Goal: Common templates visible to everyone, team-specific reports private
Create per-team groups
Create a "Templates" parent folder targeting All Users with View — everyone sees the templates
Create per-team parent folders targeting only that team's group with View — only that team sees its folders
Builders building shared templates save to Templates; private work goes to the team folder
Scenario 4: Multi-Tenant — One Customer Per Group
Goal: Each customer sees only their own folder
Create one group per customer
Add the customer's users to their group with View
Create a top-level folder per customer (parent-per-team strategy applied to tenants)
Set permissions: each customer folder targets only that customer's group with View
Optionally enable tenant mode so builders can only save to their own folder
See Multi-Tenant Setup Walkthrough.
Best Practices
Don't mingle tenants or unrelated teams in the same group. The All Users group is the only legitimate shared-access group in Yurbi. Custom groups should each represent one clearly-bounded set of users — one tenant, or one team. Mingling defeats Tenant Mode's isolation guarantees and leaks member names and folder names across tenants in scheduling, sharing, and save-as dialogs.
Name groups for people, not permissions. "Acme Corp" outlasts "Acme Corp - View Only". Permissions evolve; group identities don't.
One purpose per group. Resist combining unrelated teams into one group because they happen to need the same access today. They won't need the same access forever.
Use Strategy A by default. Parent-per-team is easier to explain and audit. Move to Strategy B only when you have content that genuinely needs to be shared.
Audit folder permissions when teams change. When a team is renamed, split, or merged, the folder permissions need to follow. It's easy to forget.
Don't grant Delete unless someone really needs it. View is the right default. Modify for team leads who organize folders. Delete for the rare case where ongoing cleanup is part of someone's role.
Test as a member of the group. After setting up permissions, sign in as a user in the group and verify they see what you intended. The fastest way to find a misconfigured folder.
When Changes Take Effect
Group membership changes: take effect on the user's next request.
Folder permission changes: take effect immediately for users who open the folder after the change. Already-open folder views may need a refresh.
New folder inheritance: applies at folder-creation time. Existing folders aren't retroactively re-parented.
Common Issues
User says "I can't see the folder." They're not in a group that targets the folder, or the group they're in doesn't have View. Check Settings → Security → Groups → [their group] for membership, then check the folder's permissions for that group.
User sees the folder but it's empty. They have View on the folder but not on the reports inside it. Reports inherit permissions from their parent folder by default; if someone moved reports, the inheritance may have broken. Check the report's own permissions.
Folder shows but they can't open it. They have permission on the folder's parent but not the folder itself. Check the folder's permissions directly.
Builder can't save a new report. They have View but not Modify on the destination folder. Grant Modify on the folder for their group, or have them save to a folder they own.
Multi-tenant: customer sees folders from another customer. Either (1) the customer's user is accidentally in multiple groups, or (2) the folder is granting View to All Users instead of just the customer's group. Check both.
Remember: A folder with no permissions checked is invisible to everyone except admins. When in doubt, that's the safe default.