Creating Users and Assigning Access

Adding people to Yurbi means filling out one form that does five things at once: it creates the identity, sets the user's group memberships, grants per-app roles, sets profile-tag values that row-level security can reference later, and (optionally) points the user at an alternate data source. This article walks the form section by section, including the most common mistakes.

When This Applies

You'll create or edit users when:

Onboarding new team members or customers
Promoting someone to administrator
Changing which apps a user can access
Setting profile-tag values that row-level security depends on
Routing a user to a specific data source via Alternate User Data Sources

Prerequisites

Creating and editing users requires Admin access to Yurbi.

If you'll be using row-level security, read Row-Level Security: Profile Tags, Data Tags, and Policies first so you know what profile-tag values to seed during user creation. Backfilling later is much more tedious than setting values now.

Before You Start: Decide These Five Things

Run through this checklist for each user before you start clicking:

Identity First name, last name, login (no spaces). Decide upfront whether you're using a plain handle (jsmith) or an email address as the login. Either works, but mixing them within one instance is confusing. If SSO is anywhere in your roadmap, email-as-login pays off later.

Group memberships Which groups does this user belong to, and what role in each? The Administrators group has special meaning — Admin in that group grants full instance access. Other groups grant access to folders, reports, and RLS policies that target that group.

Per-app roles For each app the user should touch: Agent (view-only), Builder (build reports), or Architect (edit the semantic layer). Default is no role on any app — that's deliberate. You grant per app, per user.

Profile-tag values for RLS If you'll be using row-level security, seed the user's Company field (and tag1–tag4 as needed) during creation.

Alternate data source (if applicable) If this user belongs to a customer whose data lives in its own database, decide which alternate data source to point them at on the App Assignment. See Alternate User Data Sources.

Once Your Foundation Is Set: The Three-Step Flow

If you've already done the heavier setup work — created groups, configured folder permissions, set up RLS policies, enabled Tenant Mode if applicable — adding each new user becomes a fast three-step click flow:

Create the user (name, login, password, and the Company profile tag if RLS uses it)
Assign them to their tenant or team group with the appropriate intra-group role (View / Modify / Delete)
Assign per-app roles (Agent / Builder / Architect) on the apps they should access

That's it. Profile-tag wiring, RLS policies, branding, and folder permissions are all foundation work — done once, applied automatically to every new user through the group assignment. The full walkthrough below covers the form section by section for first-time setup or when you need to understand what each field controls.

Creating a User

Navigate to Settings → Security → Users

[SCREENSHOT: Settings → Security → Users page showing existing users and the Create New User button]

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.

General Information

[SCREENSHOT: Edit User panel — General Information section showing First Name, Last Name, Login, Email, Authentication, Password, Company, Description fields]

First Name / Last Name Required.

Login Required, unique across the instance, no spaces. Stick with your chosen convention (handle or email).

Email Optional. Required for scheduled report delivery to that user. If you don't have it, the user can add it themselves from their profile after they sign in.

Authentication Defaults to Password. SSO options appear here when configured.

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 references as /#company#/. If you'll ever scope data by company, tenant, or region using a per-user value, fill this in now.

Description Optional, free text. Also a profile tag (referenced as /#description#/). Useful for auditing notes about why a user has the access they have.

Created and Modified timestamps below these fields are read-only and useful in the audit trail.

Group Assignments

Scroll to Group Assignments. Every existing group appears as a row with five role checkboxes: 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.

[SCREENSHOT: Group Assignments section showing groups with None/Admin/View/Modify/Delete checkbox columns]

What each role does inside a group:

None — cosmetic. Equivalent to no checkboxes at all.
Admin — special meaning. In the Administrators group, this grants full instance administrator powers. 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.

Important: The Administrators-group trap. If 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 dashboards), without administrator powers. This is the single most common mistake when promoting users.

App Assignments

Scroll to App Assignments. Every app you've created in Architect appears as a row, each with three role checkboxes: Agent, Builder, and Architect.

[SCREENSHOT: App Assignments section showing apps with Agent/Builder/Architect columns and the Default dropdown on the right]

What each grants on that specific app:

Agent — view-only. Can run reports built by Builders, schedule them, drill into them. Cannot build new ones.
Builder — can build reports and dashboards on the app's data. The most common "power user" role.
Architect — can edit the app's semantic layer (categories, tables, joins, report tree).

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., Builder + Agent for someone who both builds and consumes). Pick the highest needed.
The Default dropdown on the right of each row is where you assign the user to an Alternate User Data Source. Leave it on Default to use the app's primary data source.
The Apps subtab on the Security page is the bulk-edit alternative — useful when onboarding many users to the same set of apps.

Additional Options → Profile Tags

Scroll to the bottom of the panel. Expand Additional Options, then Profile Tags. Four free-form text fields: Profile Tag1 through Profile Tag4.

[SCREENSHOT: Additional Options → Profile Tags section showing Profile Tag1 through Profile Tag4 input fields]

You won't use these until you configure row-level security, but setting them during user creation is dramatically easier than backfilling later. Yurbi has ten built-in profile tags total — most are fields you already filled in:

firstname, lastname, Login, email — from General Information
company, description — also from General Information
tag1, tag2, tag3, tag4 — the four general-purpose slots here in Additional Options

Row-level security references them with /#name#/ syntax — for example, /#company#/, /#tag1#/, /#Login#/. Full syntax reference is in Row-Level Security: Profile Tags, Data Tags, and Policies.

Common patterns:

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 Yurbi auth to another system's data
tag4 = a tenant or partner ID

You can leave them blank now and fill them later — 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 the Library. If something's missing that should be there (or visible that shouldn't be), revisit Group Assignments or App Assignments on the user.

The Backup Admin Pattern

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 your primary admin's 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.

Creating an Agent (View-Only) User

The most common pattern after admins is the view-only end user. Same form, different choices:

No Administrators-group membership
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

Once you have one Agent set up correctly, future Agents are a 60-second copy of the same choices.

Bulk-Edit Alternatives

Editing one user at a time is the right tool when you're adding a single person. For batch operations, use the other subtabs under Settings → Security:

Apps subtab — 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.

Groups subtab — 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.

When Changes Take Effect

Most user changes take effect on the user's next request — usually within a refresh. Some specifics:

Group memberships and app roles: next request
Profile-tag values: next time the user runs a report that references them
Password changes: immediately; the old password stops working at once
Authentication method changes (Password → SSO): the user's next sign-in attempt

There's no "users must log out and back in" requirement for most security changes, unlike branding policies.

Common Configuration Scenarios

Scenario 1: Internal Team — Single Admin Plus Builders

Goal: Small internal team where one or two people build reports for everyone else

Create yourself as Admin on the Administrators group
Create a backup admin
Create your Builders — Builder role on each relevant app, no Administrators-group membership
Create your Agents — Agent role on each relevant app, no Administrators-group membership

No custom groups needed. The hidden All Users group handles sharing automatically.

Scenario 2: Multi-Team Internal — Department Isolation

Goal: Sales sees CRM data, Finance sees billing data, no crossover

Create per-team groups (Sales, Finance, etc.) in Settings → Security → Groups
When creating users, add them to their team's group with View
Grant per-app roles only for the apps that team should access
Set up Library folder permissions so each team's folders target their group

See Groups and Library Folder Permissions.

Scenario 3: Multi-Tenant — One Customer Per Group

Goal: Each customer organization is isolated; they see only their own data and reports

Create one group per customer (e.g., "Acme Corp", "Widget Inc")
Create users in each customer's group; set Company profile tag to the customer identifier
Configure row-level security or alternate data sources to scope data per customer
Set up per-tenant Library folder structure and (optionally) branding policies
Enable tenant mode if you want sharing to be explicit per-group

For the full walkthrough, see Multi-Tenant Setup Walkthrough.

Best Practices

Always create a backup admin before you need one. The first user after yourself should be a second admin with credentials stored somewhere durable.

Pick a login convention before user #3. Switching from handles to email addresses (or vice versa) once you have 30 users means recreating all of them.

Fill in Company on every user during creation. It's referenced as /#company#/ by row-level security. Setting it now costs four seconds; backfilling later is a tedious afternoon.

Don't grant admin when View on Administrators is what you wanted. If someone needs to read admin reports but shouldn't change settings, give them View on the Administrators group — not Admin.

Use the Apps subtab for batch onboarding. Five new analysts who all need Builder on the same three apps is a one-minute job through the Apps subtab versus fifteen minutes one-user-at-a-time.

Audit your admins periodically. Settings → Security → Groups → Administrators → Edit shows everyone with admin powers. The list should be small, named, and known.

Common Issues

"Login failed" on first sign-in. Three usual causes: (1) the user is typing their name, not their login — those are different fields. (2) The password you set isn't what you remember — reset it. (3) The login has a space in it — DashboardFox rejects spaces; recreate.

User signed in but sees nothing. You created them but didn't grant any per-app role. Edit the user, scroll to App Assignments, check Agent or Builder on at least one app. Save. They'll see apps appear on their next request.

"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. Edit the user, find the Administrators group row, check Admin.

Can't find profile tags. Scroll to the very bottom of the Edit User panel. Expand Additional Options, then Profile Tags. Profile Tag1–4 are there. Company and Description (also profile tags) are higher up in General Information.

Two-factor authentication is grayed out. 2FA is a Scale-tier feature. Contact support if it's a requirement.

Remember: Most user changes take effect on the user's next request — no logout required, unlike branding policies.