Groups and library folder permissions
Groups bundle users; library folders gate which reports those groups can open. Together they're Layer 2 of the three-layer model — and the layer most single-tenant teams stop at.
By the end of this lesson
- A folder structure that maps to your teams
- Groups configured with appropriate intra-group roles
- Each persona seeing only the folders they should
You'll need
- Admin role in DashboardFox
- Users created (lesson 2)
- A rough plan for how your library should be organized
Background
Layer 2 of the three-layer model — restricting which reports a user can open. Layer 1 (create users) gates app access; this lesson gates folder and report visibility within the apps a user can already touch.
Every user is automatically in the hidden All Users group. Folders permissioned to All Users are visible to everyone. If your team should see everything, you can skip this lesson entirely — All Users + a single shared folder structure works. This lesson is for when different audiences need different visibility.
Two concepts, one outcome
Groups are bundles of users. Folder permissions attach to library folders and reference one or more groups. The combination says "this folder is visible to members of these groups." Add row-level security (next lesson) and you also restrict the rows of data inside those reports.
The admin-only root folder rule
Only administrators can create parent (root) folders. That's a deliberate security restriction — it prevents the library's top-level shape from being changed by anyone but you. Composers and other users with appropriate intra-group permissions can create subfolders inside parents they have access to, but not new parents.
Intra-group roles
When you grant a group access to a folder, the user's intra-group role determines what they can do with it. Five checkboxes per group on the user record: None / Admin / View / Modify / Delete:
- None — cosmetic. Equivalent to no checkboxes. Some teams prefer explicit no-role rows for clarity; it changes nothing functionally.
- Admin — in the Administrators group, full instance admin. In any other group, currently behaves the same as Delete.
- View — can open the folder's reports. Can't change anything.
- Modify — can rename the folder and create subfolders inside it.
- Delete — can delete folders and reports the group owns.
An Agent's group memberships almost always sit at View. A Composer who'll build content for a team usually gets Modify (so they can organize subfolders). Delete is reserved for the small set of people you trust to remove production content.
Single-group membership scopes more than just folder access
A quiet but important property: when a user belongs to only one custom group (plus the hidden All Users), the schedule, share, and save-as dialogs filter to that group's members and folders only. A client builder who's only in the "Acme Corp" group sees only Acme members when scheduling a report, only the Acme folder when saving a new one, only Acme as the target in sharing dialogs. They have no way of knowing other clients even exist on the instance.
Mingle two clients in one group and that isolation breaks — members of one client see members of the other in those dialogs. The next callout is why that's the rule, not a suggestion.
The All Users group is the only legitimate shared-access group in DashboardFox. Every custom group should represent one clearly-bounded set of users — one client, one team, one tenant. Never combine.
This isn't just about folder permissions. Mingling defeats tenant-mode's isolation guarantees, leaks member names between clients in scheduling and sharing dialogs, and makes audits much harder. The pattern of "let's put Client A and Client B together because they happen to need the same access today" is the most common cause of cross-client visibility incidents.
Stuck on how to organize your folders, which intra-group roles to grant, or whether to use per-team parents or shared-parent subfolders? Email team@dashboardfox.com with a quick sketch of your team structure. Real human, same business day.
Before you start
- A sketch of your folder hierarchy. Pen and paper is fine — what parent folders you need, what subfolders sit under them, who should see each.
- A list of groups you'll create. One group per distinct audience. Never mingle audiences in a single group (the canonical anti-pattern: a "customer builders" mega-group whose members can see each other).
- A plan for which intra-group role each user needs. Most Agents land at View; most Composers at Modify; Delete sparingly.
- Test users. At minimum, one Agent and one Composer outside the Administrators group, so you can verify each persona sees what you intended.
Do it
-
Open the Documents library
Click Documents in the left sidebar. On a fresh instance you'll see three top-level sections — Favorites, Team, and Private — with no folders inside Team yet.
Team is the shared library — what every Module 4 permission flows through. Private is each user's personal space (no permissions to manage). Favorites is the per-user starred set. We're working in Team.
-
Create your first parent folder
Only administrators can create parent folders. You'll see a New Folder button at the Team root; non-admin users don't.
Click New Folder. Give it a name — for an internal team starting out,
Team ContentorShared Reportsis fine. The permission picker shows the groups that exist: All Users and Administrators by default.Pick All Users if everyone in your organization should see this folder. That's the right default for shared content — Composer-built reports, dashboards, common references.
The accordion at the bottom labeled Additional Options contains Allow Anonymous and Hidden. Leave these unchecked for now — they're covered in later modules. Allow Anonymous powers the guest library. Hidden has a specific use case that comes up in drill-down reports — there you'll want target reports hidden so users can run them via click-through but not browse to them directly. Click Save.
-
Create an admin-only parent folder
Repeat the flow, this time naming it
Admin Only Reportsor similar, and choosing Administrators in the permission picker (not All Users). This is where you'll put audit reports, usage dashboards, anything only admins should see.Save. You should now see two top-level parents in Team.
-
Verify by signing in as different personas
Sign out, then log in as an Agent (the view-only user you created in lesson 2). Open Documents → Team. You should see:
- Team Content — visible (they're in All Users).
- Admin Only Reports — not visible (they're not in Administrators).
- No New Folder button at the Team root (not an admin).
- No Edit, Add Subfolder, or Delete options on Team Content (View-only doesn't include folder management).
Sign out, log in as a Composer. They see Team Content with edit and add-subfolder options (Composer behavior on All-Users folders is more permissive by default — see the tenant-mode lesson for when that changes). They don't see Admin Only Reports.
Sign out, log in as your Backup Admin. They see both folders and have full management on each. They can also create new parent folders (admin privilege).
This three-persona verification loop is the only reliable way to confirm permissions are right. Do it every time you change a folder structure or group membership.
-
Create a group
Back to Settings → Security → Groups as an admin. Click Create New Group.
Name the group after the audience it represents —
Finance Team,Customer Support,Acme Customer. Description is optional but worth filling in if you'll have multiple admins managing groups.In the Members section, search and select the users who belong. For each member, check the intra-group role that fits — View for consumers, Modify for content owners, Delete for the small set you trust with destructive actions. Save.
-
Create folders restricted to that group
Back to Documents. Two ways to give the group its own report space:
Strategy A — Parent folder per groupCreate a new parent folder, permission it only to the group (e.g.,
Finance Team).When to use:
- Hard isolation — nobody else should see anything in this branch
- The audience has its own distinct content universe
- Multi-tenant — each customer/partner gets their own parent
Strategy B — Subfolder under a shared parentInside an existing All Users parent, create a subfolder permissioned to the group.
When to use:
- Most people see the parent; the subfolder is the "extra" content
- The group's content is conceptually part of the shared library
- Department reports inside a single internal hierarchy
Both strategies work. The difference is whether outsiders see the existence of the folder (Strategy B: yes, they see the parent but not the locked subfolder; Strategy A: no, the whole branch is invisible). For tenants and customers, use Strategy A. For internal departments, Strategy B is usually friendlier.
To create the folder: from Documents, click the parent's action menu (three dots) → Add Subfolder, or use New Folder at the root for Strategy A. Pick the group from the permission picker. Save.
-
Verify the new group sees only their folder
Log in as a member of the new group. They should see All Users folders plus their group's folder, and nothing else. Folder management capabilities depend on their intra-group role — Modify or Delete means they can manage their group's content; View only means they can open it.
If they see something they shouldn't or don't see something they should, the issue is almost always one of: (1) wrong group membership on the user, (2) wrong group on the folder permission, (3) the user hasn't logged out and back in since the change.
-
Bulk-edit paths — when one-at-a-time is too slow
For "move five users into a new group," go to Settings → Security → Groups, edit the group, set memberships and roles in one place. For "give the Composer group access to ten folders," go folder-by-folder — there's no bulk folder permission tool, but folder permissions cascade (a parent's groups flow down unless a subfolder explicitly overrides).
The cascade is the single biggest time-saver. Get the parent right; subfolders inherit until you need an exception.
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 scale, and the anti-patterns that don't.
Plan structure before you click
Folder structures are far easier to design on paper than to refactor live. Sketch your hierarchy first: what parents, what subfolders, who sees each. Two questions force the right shape:
- If I added a new audience tomorrow, where would their content go? (Answers "parent vs subfolder" for the strategy choice.)
- What's the highest-cost mistake — wrong people seeing data, or right people not seeing it? (Answers "default to All Users" vs "default to locked-down.")
For most internal teams, "default to All Users with one or two locked-down branches" is the right starting shape. Add complexity only when an audience actually needs separation.
Never mingle audiences in a single group
The canonical mistake: creating an "all customer builders" group, or a "field staff" group containing reps from multiple regions who shouldn't see each other. With tenant mode on (covered in lesson 5), group membership controls who appears in scheduler dropdowns, which means mingled groups leak identities across audiences.
The pattern: one group per distinct audience, no exceptions. If a person needs access to two audiences' content (a Composer building reports for two departments), put them in both groups individually — don't merge the groups.
Give Modify generously, Delete sparingly
Modify lets people rename folders and create subfolders — the routine work of organizing a library. Delete lets them remove folders and reports. The asymmetry: an over-organized library is a minor annoyance; a deleted production report is a real problem.
Default new Composers to Modify. Reserve Delete for a small named set (lead analysts, admins). If you find a Composer wishing they had Delete, that's the conversation — not the default.
Lean on the cascade
Folder permissions cascade. Granting a group access to a parent grants every subfolder underneath, unless a subfolder explicitly overrides the permission set. Use this:
- Set the parent's permissions to the broadest reasonable audience. Most parents land on All Users.
- Override on subfolders only where genuine restriction is needed.
- Avoid setting the same permissions individually on twenty subfolders when the parent could carry it.
Cascade also means: if you tighten a parent (e.g., change a parent from All Users to a specific group), every subfolder under it tightens accordingly unless they had explicit overrides. Test after structural changes.
Use Strategy B (subfolder under shared parent) for soft sharing
When an audience's content is "part of the shared library, but their team's working space" — internal departments are the classic case — Strategy B keeps the library cohesive. Everyone sees the shared parent; the team sees their subfolder; non-team members see the parent without the subfolder existing. The library feels like one place, not N silos.
Reserve Strategy A (separate parent) for cases where the audience shouldn't even know the others exist — customers, partners, external auditors.
So far you've gated which reports users can open. The next layer down — which rows of data appear inside those reports — is row-level security.
Common patterns playbook
Single team, share everything
Do nothing — All Users + Administrators is enough. One parent permissioned to All Users for shared content; an Administrators-only parent for audit reports.
Department-by-department
One group per department. One subfolder per department under a shared Team Content parent. Department members see their subfolder; everyone sees the parent.
Admin-only audit reports
A parent folder permissioned only to Administrators. Audit reports, usage dashboards, sensitive ops reports live here. Visible only to people with Admin/View/Modify/Delete on the Administrators group.
Customer-facing (preview)
One group per customer, parent folder per customer (Strategy A). Each customer sees only their parent. Full version with branding and tenant mode in the multi-group walkthrough.
If you're stuck
The stumbles that come up most often after the first few folder/group setups.
Composers can edit my production folders — I didn't want that
That's default behavior. Composers can manage All Users folders (rename, add subfolders) and delete/move reports within them. If that's too permissive for your team, tenant mode changes this — Composer destructive actions on All Users folders are restricted when tenant mode is on. Tenant mode is also useful for small single-tenant teams that just want production-report protection.
A user sees a folder but no reports inside
They have the folder permission but not an app role on the app the reports run against. Lesson 2 — edit the user, App Assignments, grant Composer or Agent on the right app. Refresh; the reports appear inside the folder.
I want "everything except this one folder"
Invert it. Set the things-everyone-can-see to All Users (or a broad group). Set the restricted folder to a narrower group — its own group, or Administrators only. There's no native "deny" rule; you compose access positively from groups instead.
I gave someone Modify but they still can't delete
Working as designed. Modify lets them rename folders and create subfolders; Delete is a separate role for removing folders and reports. If they need to delete, check Delete on the appropriate group. Both can coexist — Modify + Delete gives full control.
I changed a parent's permission and subfolders unexpectedly changed too
Cascade. Folder permissions flow from parents to children unless explicitly overridden. If a subfolder had no explicit permission set, it followed the parent — and now follows the new parent permission. To insulate a subfolder: edit it, set its permissions explicitly, and they'll stay regardless of parent changes.
I see Allow Anonymous and Hidden options — what are those?
Two advanced toggles in the folder creation form. Allow Anonymous exposes the folder to the guest library (a public report space for users without logins — covered in Module 5).
Hidden is a visibility setting, not a permission setting. Users with folder permission can still run reports inside a Hidden folder — they just can't see the folder when browsing the library tree. The canonical use case is drill-down target folders: users have folder permission (so the drill-down click resolves), and the folder is Hidden (so they can't run the target report directly via library navigation). Both toggles cooperate; they're independent levers. Also used for staging folders during report development.
Leave both unchecked unless you specifically need them.
None of these match my situation
Email team@dashboardfox.com with a sketch of your folder structure, the groups involved, and what's behaving unexpectedly. Same business day reply.
