Create users and assign access
The user record carries identity, group memberships, per-app roles, and the profile-tag values row-level security will use later. Five things in one form — let's walk it carefully.
By the end of this lesson
- A signed-in user with the right scope to do their job
- A backup admin so you're never locked out
- Profile-tag values seeded for the row-level security lesson
You'll need
- Admin role in DashboardFox
- Familiarity with the role model from Roles & permissions (Module 1)
Background
This lesson sets up the foundation everything else in Module 4 stands on. By the end, you'll have working users with the right scope, a backup admin so you're never locked out, and the profile-tag values that row-level security uses two lessons from now.
Out of the box, DashboardFox is designed for a single internal team where data is broadly shared. Every user you create lands in a hidden default group called All Users. If everyone on your team should see everything, that's already most of your setup — this lesson just covers creating the people. The other Module 4 lessons add restrictions on top.
Where this fits
Module 4 walks three security layers in order. This lesson covers Layer 1 — does the user exist, and what apps can they touch at all? The next two lessons add Layer 2 (which reports they can open) and Layer 3 (what rows show inside those reports). The Module 4 overview has the full picture.
The Security tab anatomy
Everything in Module 4 lives under Settings → Security. Five subtabs:
- Users — the people. Where this lesson lives.
- Groups — bundles of users you grant access to as a group. Lesson 3.
- Apps — bulk-grant access to data sources across users. Touched here, expanded later.
- Data Tags — group-based scoped values for row-level security. Lesson 4.
- Data Security — the row-level security policies themselves. Lesson 4.
The two default groups
Before you create anyone, two groups already exist:
- Administrators — visible in 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, all the time. You can't add or remove members; that's the point.
For a small internal team, those two groups plus per-user roles on the Administrators group may be all you ever configure on the group side. Groups & folders covers when (and why) to add more.
The full walkthrough below covers the user form section by section for first-time setup. Once you've done the foundation work (groups created, folder permissions configured, RLS policies in place, tenant mode flipped on if you're running multi-tenant), adding each new user is just three steps:
- Create the user — name, login, password, and the Company profile tag if RLS uses it
- Assign to their tenant or team group with the appropriate intra-group role (View / Modify / Delete)
- Assign per-app roles — Composer / Agent / App Builder on the apps they should access
Stuck on whether someone should be an admin, what app role they need, or whether to grant access individually vs. through a group? Email team@dashboardfox.com with a quick description of the user you're trying to set up. Real human, same business day.
Do it
-
Open the Users page
From the left sidebar, click Settings (the gear icon), then the Security tab at the top, then the Users subtab. You'll see a list of existing users — at minimum, yourself.
Click Create New User. A side panel slides in from the right with the user form. The panel scrolls; the save buttons stay pinned at the bottom.
-
Fill in General Information
Top of the form:
- First Name / Last Name — required.
- Login — required, unique across the instance, no spaces. Stick with your chosen convention (handle or email).
- Email — optional. Skip if you don't have it; the user can add it themselves from their profile later.
- Authentication — defaults to Password. SSO options appear here when configured (covered in a later module).
- Password / Confirm Password — the user's initial credentials. They can change it after signing in. No built-in strength rules unless your server settings impose them.
- Company — this looks optional, but it's a profile tag that row-level security will reference as
/#company#/. If you'll ever scope data by company / tenant / region using a per-user value, fill this in now. (More on profile tags in step 5.) - Description — optional, free text. Also a profile tag (referenced as
/#description#/). Useful for auditing notes.
Created and Modified timestamps below these fields are read-only and useful in the audit trail.
-
Set group memberships — and watch for the Admin trap
Scroll to Group Assignments. Every existing group is listed with five role checkboxes per row: None / Admin / View / Modify / Delete. A new user gets nothing checked by default — they're in the hidden All Users group automatically and that's it.
What each role does inside a group:
- None — cosmetic. Equivalent to no checkboxes at all. Some teams prefer explicit "no role" rows; it changes nothing functionally.
- Admin — special meaning. In the Administrators group, this grants full instance administrator powers — everything in Settings, every app, every override. In any other group, Admin 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.
The Administrators-group trapIf you want to make someone a full administrator, you must check the Admin column on the Administrators group row. Nothing else does that.
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, usage dashboards) — useful for letting someone see admin-only reports without giving them the keys to the kingdom.
A second admin is worth creating early as a backup admin. If your primary admin loses access (forgot password, left the company, etc.), the backup gets you in without a support ticket.
-
Assign per-app roles
Scroll to App Assignments. Every app you've created appears as a row, each with three role checkboxes: Composer, Agent, and App Builder.
What each grants on that specific app:
- Composer — can build reports and dashboards on the app's data. The most common "power user" role.
- Agent — view-only. Can run reports built by Composers, schedule them, drill into them. Cannot build new ones.
- App Builder — can edit the semantic layer (categories, tables, joins, report tree). See Module 3 for what App Builder unlocks.
A few things worth knowing:
- Default is no role on any app. This is deliberate — connecting a data source and granting access to it are separate decisions on purpose. New users see nothing in any app until you grant them a role.
- You can stack roles on one app (e.g., Composer + Agent for someone who both builds and consumes). In practice, pick the highest needed.
- The Apps subtab on the Security page is the bulk-edit alternative — useful when onboarding 10+ users to the same set of apps. Covered in step 8.
- You may see a Default dropdown next to each app row. That's an Enterprise-tier feature for setting per-user dynamic database connection strings. Ignore it unless you're on Enterprise.
-
Set profile-tag values (RLS scaffolding)
Scroll to Additional Options → Profile Tags. Four free-form text fields: Profile Tag1 through Profile Tag4.
You won't use these until lesson 4, but setting them during user creation is dramatically easier than backfilling later. DashboardFox has ten built-in profile tags total — most are fields you already filled in:
- firstname, lastname, Login, email — from General Information, top of form.
- company, description — also from General Information.
- tag1, tag2, tag3, tag4 — the four general-purpose slots here under Additional Options.
RLS references them with
/#name#/syntax — e.g.,/#company#/,/#tag1#/. Full syntax reference is in lesson 4.Some examples of what teams put in tag1–tag4:
- tag1 = region code (e.g.,
US-WEST) — used in an RLS rule like "region field equals/#tag1#/" - tag2 = team or department identifier
- tag3 = an external system's user ID, for joining DashboardFox auth to another system's data
- tag4 = a tenant or partner ID
Leave them blank now and fill them later if you're not yet sure what values you'll need — the user just won't be filtered by anything that depends on them until you do.
-
Save and verify
Scroll to the bottom and click Save & Apply. The panel closes and the user appears in the Users list. They can sign in immediately with the password you set.
Quick verification — sign out, sign back in as that user. Check what they see: which app icons are in the sidebar, which folders show in Documents. If something's missing that should be there (or visible that shouldn't be), you almost certainly need to revisit Group Assignments or App Assignments on the user.
-
Create a second user — the Agent pattern
Repeat the flow for a view-only consumer. Same form, different choices:
- No Administrators-group membership at all.
- Agent role on every app they need to see data from. Skip apps they shouldn't touch — they'll never see those apps appear anywhere in the UI.
- Company filled in (so RLS can scope their data later).
- Profile tags as needed.
That's your most common pattern after admins — view-only end users who run pre-built reports. Once you have one Agent set up correctly, future Agents are a 60-second copy of the same choices.
-
Bulk-edit alternatives — Groups and Apps tabs
Editing one user at a time is the right tool when you're adding a single person. For "everyone on the sales team needs Composer on the CRM app," go through the Apps subtab; for "add five people to the Finance group," go through Groups.
- Settings → Security → Apps → click an app → edit roles for every user at once on that app. The fastest path for onboarding a batch of users to the same data source.
- Settings → Security → Groups → click a group → edit members and their intra-group roles in one place. The fastest path for moving people in and out of teams.
Both tabs reach the same underlying data the Users tab edits — there's no "primary" path. Pick whichever matches the shape of the change.
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
Five patterns that pay off well before your team grows past a handful of users.
Always create a backup admin before you need one
The first user you should create after yourself is a second administrator. Stash the credentials somewhere durable (password manager, your DR runbook). The day you need them is rarely a calm Tuesday afternoon — it's usually the day before a board meeting when your laptop is wiped or your SSO is misconfigured.
To make a backup admin: in Group Assignments, check the Admin column on the Administrators group row. Nothing else needed unless they'll also build reports.
Pick a login convention before user #3
Two reasonable conventions: plain handles (jsmith) or email addresses (jsmith@acme.com). Pick one and apply it consistently. If SSO is anywhere on your roadmap, lean toward email-as-login — it makes the eventual mapping trivial. If your team is internal-only and small, plain handles are fine.
What's painful: switching conventions after you have 30 users. Existing logins don't auto-rename; you'd recreate every user.
Fill in Company on every user during creation
The Company field on a user is referenced by row-level security as /#company#/. Filling it in costs you four seconds during user creation. Backfilling 50 users later because RLS needs to scope by company is a tedious afternoon.
If you don't yet know what value to put — guess. Use the company name, the tenant ID, the customer code, whatever lookups make sense in your data. You can edit it later if your scheme evolves. The cost is asymmetric: blank now means rework later; filled-in-wrong now means a one-field edit.
Don't grant admin to people who just need to read admin reports
If your auditor or compliance manager needs to see the audit dashboards but shouldn't have full administrator powers: in Group Assignments, give them View on the Administrators group, not Admin. They'll see folders and reports that target the Administrators group without being able to change settings or modify other users.
The reverse mistake — granting Admin when you meant View — gives someone the ability to change everything. Easy to do, harder to notice afterwards.
Use the Apps tab when onboarding a batch
For one new user across one or two apps, the Users → Create New User flow is right. For five new analysts who all need Composer on the same three apps: open Settings → Security → Apps, click the first app, set Composer on all five at once, repeat for the next two apps. Done in a minute instead of fifteen.
Same data, faster path. Use whichever matches the shape of the change.
Once you have a few users in place, the next layer is restricting which reports each of them can open. That's Groups & folders.
If you're stuck
The classic stumbles, in roughly the order they show up after you start creating users.
My new user can't sign in — "login failed"
Three usual causes. (1) The user is typing their name, not their login — those are different fields on the user record. (2) The password you typed during creation isn't what you remember; reset it from the Edit User panel. (3) The login has a space in it — DashboardFox rejects spaces; recreate the user with a space-free login.
My user signed in but sees no apps, no reports, nothing
You created them but didn't grant any per-app role. Edit the user, scroll to App Assignments, check Composer or Agent (or App Builder) on at least one app. Save. Have them refresh; the apps appear in the sidebar.
This is the single most common "I made a user but it doesn't work" issue. Per-app roles default to none on purpose — apps are gated until you grant explicitly.
I made them an admin but they don't have admin powers
You checked View, Modify, or Delete on the Administrators group instead of Admin. Those three grant access to admin-only folders and reports — useful, but not the same as being an admin. Edit the user, find the Administrators group row, check Admin, uncheck the others if they're not also needed.
I can't find where to set profile tags
Scroll to the very bottom of the Edit User panel. Expand Additional Options, then the Profile Tags accordion inside it. Profile Tag1 through Profile Tag4 are there. Company (also a profile tag) is much higher up in the General Information section.
Two-factor authentication is grayed out
2FA is a Scale-tier feature. If you're on a lower tier, the toggle appears but isn't usable. Talk to team@dashboardfox.com about tiers if 2FA is a requirement.
I lost track of who's an admin
Settings → Security → Groups → Administrators → Edit. The members list shows everyone in the group with their checked roles. The ones with Admin checked are your administrators. Audit it periodically — admins should be a small, named, known set.
None of these match my situation
Email team@dashboardfox.com with what you were trying to do, what you saw instead, and the user's role and group memberships. Same business day reply.
