Permissions and folder structure are worth getting right before you hand the tool to users. A clean setup makes the library easy to navigate and the security model easy to reason about. A messy setup — built by accumulation rather than design — creates confusion that compounds as more reports are added. This chapter covers the structure to aim for and how to phase the rollout so it doesn't land on everyone at once.
How Groups and Permissions Work
DashboardFox's permission model centers on groups. You define groups in Settings → Security → Groups, assign users to groups, and then assign groups to library folders with specific permission levels. There are three core permission roles to understand: admin (full access), builder (can create and save reports), and agent (view and run only). Most organizations have a small number of people who need builder access and a larger population of agents — people who run reports but don't need to create new ones.
The simplest starting structure uses an All Users group as the baseline. Reports and folders assigned to All Users are visible to everyone with an account. From there, you create additional groups for access-restricted content: a Finance group that can see financial dashboards, a specific client group that sees only that client's data, a management group that sees executive-level summaries. When a user has no permission on a folder or App, they don't see it in the library at all — it's invisible to them, not just locked.
A practical recommendation: start with fewer groups than you think you need. You can always add groups and tighten permissions later. Starting with a complex group structure and then discovering that most of your content is All Users anyway wastes setup time and creates confusion.
Structuring the Library Folders
Admins create top-level library folders. Those folders inherit the permission groups you assign to them, and reports saved in a folder automatically inherit the folder's permissions. For most organizations, a clean starting structure is three to five top-level folders: one for shared reports that everyone sees, one or two for restricted function areas (finance, operations, client-specific), and one for the analytics team's working folder.
Reports don't need their own permission assignments — letting them inherit from the folder keeps management simple. Only override at the report level when something specific requires it, like a single report within a shared folder that should be builder-only.
Row-Level Security — Data Tags
If your migration includes implementing row-level security (or moving an existing RLS implementation from your old tool), DashboardFox handles this through Data Tags. A Data Tag is a value assigned to a user or group that gets substituted into queries at runtime. In your SQL query or App Builder field, you reference the tag placeholder, and DashboardFox substitutes the user's assigned tag value when they run the report — so two users running the same report see different data based on their respective tag values.
For a detailed walkthrough of the Data Tags mechanism and how to design a row-level security model, the row-level security guide covers this specifically. If you're migrating an existing RLS implementation, the conceptual model — which users see which data based on what attribute — translates directly. The configuration mechanism is different from how Power BI's row-level security or Tableau's data-level security work, but the end result is the same: the right data reaches the right user without manual filtering.
If you're using DashboardFox's white-label features — your logo, custom domain, branded login page — set these up in Settings → Branding before you send login invitations to users. The first experience users have with the tool should be your branded version, not a default DashboardFox interface. Custom domain configuration is in Settings → Server Settings; branding policies (colors, logos, feature visibility) are in Settings → Branding.
A Phased Rollout Approach
Switching all users at once on a specific date creates a support spike and risks disrupting workflows if anything isn't quite right. A phased approach is less dramatic and lets you catch issues with a smaller group before they affect everyone.
A workable pattern: start with the people who will become power users or advocates — the team leads, the analyst who runs the weekly ops report, the operations manager who lives in data. They get access first, help validate that the priority reports are correct, and become your internal point people for questions from their teams. Their feedback during this phase is often where you catch report logic errors before they reach a wider audience.
Phase two expands to the broader team, department by department or function by function. Brief each group on what's changing, what reports they'll find, and who to contact with questions. For occasional users — managers and executives who check in periodically — a short email with a link to their key dashboards and a one-paragraph explanation of the new location is usually sufficient.
Keep the old tool accessible in read-only mode during the parallel period if the contract allows it. Having both available removes the pressure of a hard cutover and gives users a reference point if they need to confirm that a number looks the same in both systems.
Scheduled Reports and Embedding — Confirm Before Cutover
Before you cancel the old tool's subscription, verify two things from your inventory: scheduled reports are running in DashboardFox and delivering to the right recipients, and any embedded dashboards are updated to point to DashboardFox embed URLs rather than the old tool's. These are the two items most likely to cause an external-facing issue after cutover. Scheduled reports that send to clients, partners, or executives carry a higher visibility than internal ones — confirm those specifically.
The final chapter is the go-live checklist: a complete list of items to verify before you cancel the old subscription and mark the migration complete.
