Users and permissions overview
Three security layers, walked in order. Plus one instance-level switch (tenant mode) for setups that need it. This page is your map.
By the end of this lesson
- You'll know the three-layer security model and which lesson configures each layer
- You'll know the five-step Module 4 sequence and which step solves which permission concern
- You'll know whether the last two lessons (tenant mode, multi-group) apply to you
You'll need
- Familiarity with DashboardFox roles from Roles & permissions (Module 1)
Background
Module 4 is where you go from "I have working apps with data in them" to "the right people see the right things in those apps." Every permission concern in DashboardFox lives at one of three layers — and Module 4 walks them in order.
The three-layer security model
Each layer narrows what a user can see. They stack — Layer 2 only matters for users who passed Layer 1; Layer 3 only matters for reports the user can already open. Plus a fourth cross-cutting layer (tenant mode) that hardens behavior at all three.
Does the user have any role on this app at all? If no, they see nothing from it — no folders, no reports, no app icon in the sidebar.
Within apps they can touch, which reports can they open? Library folders have group permissions; if their groups don't match, the folder doesn't appear.
Within reports they can open, which rows of data appear? Same report, different users, different rows — driven by per-user or per-group tag values.
An instance-level switch (off by default) that hardens the boundaries at all three layers — restricts cross-group user visibility, makes shared folders read-only canned content, locks down Composer destructive actions on shared content. Most teams don't need it; multi-tenant setups depend on it.
A related Server Settings toggle can disable the All Users group entirely — one step stricter than tenant mode, for deployments where shared-with-everyone content shouldn't even be possible. Covered in lesson 5.
The five-lesson sequence
Five lessons build on each other. The first three are for every team; the last two are only for multi-tenant setups.
Every team does these
Create users
Add people to your DashboardFox instance and assign their initial roles. Where the App Builder permission gotcha lives.
Groups & folders
Bundle users into groups and use library folder permissions to control which reports each group can open.
Row-level security
Use data tags to control which rows of data each user sees inside a report they already have access to.
Decision: single-tenant or multi-tenant?
Single-tenant — one team, one set of users who all work on the same data. Maybe with different roles and different folder access, but one organization at the table. You're done at step 3. Skip to Module 5 — Branding.
Multi-tenant — you're running one DashboardFox instance for several distinct customer organizations (a hosted product, an MSP serving multiple clients, a portfolio of business units). Continue to steps 4 and 5 below.
Multi-tenant only
Tenant mode
Turn on the instance-level behavior that isolates user groups from each other — scheduling, visibility, the whole pattern.
Multi-group walkthrough
Two tenants end-to-end — folders, data tags, branding, tenant mode, all in one running example.
The three core lessons build on each other: create users → group them → filter their data. Each one narrows what a given user sees. Library folders gate which reports they can open; row-level security gates which rows of data show up inside those reports. If you don't need both, you can do less — the section below walks each step in turn.
Stuck on which lesson covers your situation, or which permission layer is blocking a user? Email team@dashboardfox.com with what you're trying to grant or deny and who you're trying to grant or deny it to. Real human, same business day.
Do it
-
Step 1 — Create users (start every team here)
Add the people who'll be working in DashboardFox. Settings → Security → Users → Add User. For each person you set a name, email, and any system-level flags (Admin, Billing Admin) — but you do not grant per-app access in this step.
That's deliberate. Per-app roles (App Builder, Composer, Agent) are assigned in step 2, where they scale better via groups. Creating the user just means they can sign in — what they can see is gated by everything that comes after.
Open: Create users →
-
Step 2 — Groups and library folder permissions
Instead of granting roles user-by-user, bundle users into groups, then grant each group access to apps and to library folders. Folder permissions are how you say "the sales team can open these reports; the finance team can open those." Folders cascade — give a group access to a parent, they get every subfolder unless you explicitly restrict.
For most single-tenant teams, this layer plus step 1 covers 80% of "who sees what." Step 3 is the next layer down.
Open: Groups & folders →
-
Step 3 — Row-level security (the last layer for most teams)
Same report, different users, different rows showing. The classic example: a sales report where each rep sees only their own region. The mechanism is data tags — small markers you put on users and on rows of data, and DashboardFox filters rows to the ones whose tag matches the user's tag.
Once you've finished this step, every single-tenant DashboardFox setup is feature-complete on the permissions side. If you're single-tenant, you can stop here and head to Module 5 (Branding). If you're multi-tenant, keep going.
Open: Row-level security →
-
Decision — single-tenant or multi-tenant?
The next two lessons are only for one specific situation: you're running one DashboardFox instance for several distinct customer organizations. A hosted product where each customer is logically isolated. An MSP serving multiple end clients. A portfolio of business units that need to feel separate.
If your situation is more like "one team, different roles, different folder access" — that's single-tenant. You've already finished Module 4. Steps 4 and 5 would add complexity you don't need.
If you're not sure: do you have customer organizations that should never see each other's data, branding, or schedule notifications? If yes, multi-tenant. If no, single-tenant. Still unsure? Email team@dashboardfox.com — we'll walk through your specific setup.
-
Steps 4 and 5 (multi-tenant only) — tenant mode and the walkthrough
Two paired lessons:
- Tenant mode — the instance-level setting that isolates groups from each other. Once on, schedules, visibility, and a handful of other behaviors change to respect tenant boundaries. Configure it once for the instance.
- Multi-group walkthrough — a worked example with two tenants, end to end. Folders, data tags, branding, tenant mode, the whole stack in one running example. The fastest way to see it click for your situation.
Open: Tenant mode → then Multi-group walkthrough →.
If you're stuck
Conceptual confusions people hit before they even start Module 4. If you're not sure what each lesson is for, one of these usually clears it up.
Is row-level security the same as groups and folders?
No — they sit at different layers and solve different problems.
Library folder permissions (lesson 3) gate which reports a user can open in the library. If the report isn't in a folder they have access to, they can't see it at all.
Row-level security (lesson 4) gates which rows of data appear inside a report the user can open. Same report, different users, different rows showing.
Most teams use both: folders to say "which reports", row-level security to say "what slice of the data, within those reports."
Do I need tenant mode if my users see different reports?
Probably not. Different users seeing different reports is what library folder permissions are for (lesson 3). Different users seeing different rows in the same report is what row-level security is for (lesson 4). Both of those are single-tenant features.
Tenant mode is for when distinct customer organizations share one instance and need to feel separate from each other — separate branding, separate schedules, separate visibility into who else is using the system. If your situation is one team with role variation, you don't need it.
What's the difference between tenant mode and the multi-group walkthrough?
Tenant mode is the configuration — a small set of instance-level switches and behaviors. The multi-group walkthrough is a worked example showing tenant mode in use alongside groups, folders, data tags, and branding, end to end. Read tenant mode first to understand the switches; read multi-group to see how a real two-tenant setup hangs together.
I'm not sure whether I'm single-tenant or multi-tenant
One test that usually works: could two of your end users meet at a conference, mention they use DashboardFox, and be surprised that the other one exists? If yes — separate customer organizations, no overlap — you're multi-tenant. If no — they all work at the same company, even if they're in different departments — you're single-tenant.
Edge case: an internal company with multiple business units that don't share data. Technically single-tenant (one organization) but multi-tenant in effect (the BUs should be isolated). Treat it as multi-tenant for Module 4 purposes — the tooling is built for exactly that case.
None of these match my situation
Email team@dashboardfox.com with what you're trying to set up and what's confusing about the path. We'll point you at the right lesson, or walk it with you directly. Same business day reply.
