Row-level security with profile tags and data tags

Do it

1. Identify the report and the field to filter on

   Pick an existing report (or build a quick one — covered in the Builder module) that returns rows you want to scope per user. The classic shape: a report with a customer or assignee column whose values should be filtered to the current user's scope.

   The constraint will apply at the category/report-type level, not per-report — meaning every report in that category, including future ones, will inherit the filter. That's a feature, not a limit. It's why "Composers can build new reports and RLS still applies" works.

2. Path A — Profile tag (per-user values)

   Use this when each user has a unique value, or when users are auto-provisioned via the DashboardFox API (profile tag values can be set during user provisioning).

   Step A1 — Set the profile tag value on each user. Edit each user (Settings → Security → Users → Edit). The fields that double as profile tags:

   • Company — most common for customer/tenant scoping. Referenced as /#company#/.
   • tag1 through tag4 — general-purpose slots in the Additional Options accordion. Referenced as /#tag1#/, etc.
   • firstname, lastname, Login, email, description — also referenced as profile tags. Auto-populated from General Information.

   Set the value (e.g., Company = Acme Corp). Save. Repeat for each user who should be scoped.

   Step A2 — Create the data security policy. Settings → Security → Data Security → Create New Policy. Name it descriptively (e.g., Customer Restriction). Description optional.

   Step A3 — Add a constraint. Click Add Constraint:

   • Select Category — pick your app's semantic-layer category (report type).
   • Select Fields — pick the field to constrain (e.g., Customer).
   • Operator — defaults to = (equal). Use this for single-value scoping.
   • Custom Value — scroll to the bottom of the value dropdown or type custom. Enter /#company#/ (the profile tag reference).
   • Click + Add Constraint.

   Step A4 — Assign the policy to users or groups. Scroll to Assigned Groups.

   • Recommended default: All Users. Every user gets filtered by their own Company value automatically — clients see only their client's rows, and admins (who typically don't have a Company value matching client data) see zero rows on this report. That's fine: admins use admin-only reports against admin-only folders where this RLS policy doesn't apply.
   • Alternative: scope to specific groups (every client group, but not Administrators). Use this only when admins regularly need to see unfiltered client data from the same reports clients run. The tradeoff: every new client group you add must be remembered and added to this policy's assignments. All Users covers them automatically.

   Save.

   Step A5 — Verify. Sign out, log in as each test user. They should see only rows matching their Company value. Any user without a Company set sees nothing — that's working as intended.

3. Path B — Data tag (group/tenant values with default)

   Use this when multiple users share a value (everyone in the Acme group sees Acme's data), or when you want a safe-fallback default for users without an explicit value.

   Step B1 — Create the data tag. Settings → Security → Data Tags → Create New Data Tag:

   • Label — the name you'll reference. Stick with snake_case lowercase (e.g., assignee, region_code) and avoid spaces. The reference syntax will be /#assignee#/.
   • Group — an optional free-text label for organizing your data tags in the list view. Cosmetic only; doesn't change behavior.
   • Data Type — Character, Numeric, or Datetime. Match the type of the field you'll constrain.
   • Default Value — what users without an explicit value see. Powerful: set this to a demo/safe value (e.g., DEMO_CUSTOMER) so admin users and unmapped users see something meaningful rather than nothing.

   Step B2 — Assign values per group and/or user. Below the basic fields:

   • Group Assignments — every group is listed. Check the box and enter the value for each group that should be scoped. Members of that group inherit the value.
   • User Assignments — for users who need an override or a value outside of groups. Search and assign.

   Save. Notice you can toggle the data tag inactive from the list view — useful for testing.

   Step B3 — Create or extend the data security policy. Either create a new policy or add to an existing one (we'll cover the AND-vs-OR composition implications shortly). Add a constraint:

   • Select Category, Select Fields — same as Path A.
   • Operator — usually = for single-value scoping, or in list for multi-value scoping (e.g., a manager seeing multiple regions).
   • Custom Value — enter /#assignee#/ (or whatever label you used).
   • Add the constraint.

   Step B4 — Assign and verify. Save the policy. Sign out, sign in as test users. Members of an assigned group see their group's value; users without an assignment see the default value (or nothing, if no default is set).

4. AND vs OR — keep constraints in one policy

   The single most consequential decision when an app needs more than one constraint:

   ✓ Same policy → AND

   Multiple constraints inside one policy combine as AND — the most restrictive interpretation. Company matches AND assignee matches.

   Almost always what you want. Keep all an app's constraints in one policy and add them inside that policy.

   ✗ Separate policies → OR

   Constraints in separate policies on the same app combine as OR — the most permissive interpretation. Company matches OR assignee matches.

   Almost never what you want. Users see more data than either policy alone would allow — the union of all matches.

   Rule of thumb: one policy per app. Add every constraint that app needs as a constraint inside that policy. Test by toggling individual constraints inactive (the per-constraint toggle is right there in the policy editor) rather than splitting policies for testing.

5. In-list values — the syntax that catches everyone

   For an operator of in list (multiple acceptable values), the custom-value syntax has a specific format that's easy to mistype:

   In-list custom-value format

   Use this exact pattern:

   value1','value2','value3','value4

   • No leading single quote on the first value
   • No trailing single quote on the last value
   • No spaces anywhere — not after the commas, not around the separators
   • The separator between values is exactly ',' (close-quote, comma, open-quote)

   DashboardFox wraps your input in single quotes automatically — that's why the leading and trailing ones are missing. Type extras and the generated SQL ends up with ''value1'', which never matches.

   For mixing static values and dynamic tags in an in-list (e.g., "this customer plus DEMO_DATA fallback"), you can include the tag reference: /#company#/','DEMO_DATA.

6. The complete tag syntax reference

   Reference for every place a tag value can be inserted in a data security policy constraint.

   Open the full reference

   Profile tags (built-in, attached to every user):

   • /#firstname#/ — user's first name
   • /#lastname#/ — user's last name
   • /#Login#/ — user's login (case-sensitive in the reference)
   • /#email#/ — user's email address
   • /#company#/ — Company field from General Information
   • /#description#/ — Description field from General Information
   • /#tag1#/, /#tag2#/, /#tag3#/, /#tag4#/ — the four general-purpose slots in Additional Options → Profile Tags

   Data tags (custom, defined in Settings → Security → Data Tags):

   • /#yourlabel#/ — where yourlabel matches the Label you set when creating the data tag. Recommended: snake_case lowercase, no spaces.
   • Reserved names you cannot use as data tag labels: firstname, lastname, Login, email, company, description, tag1, tag2, tag3, tag4 (these are already profile tags).

   Where to paste the syntax:

   • In the Custom Value field of a constraint, with = operator: paste /#tagname#/ directly.
   • In the Custom Value field with in list operator: use the in-list format from the previous step. Can mix tags and literal values: /#company#/','DEMO_DATA.

7. RLS follows the user everywhere

   One of the most useful properties of how RLS is built: the constraint applies at the semantic-layer category level, not on individual reports. Consequences worth knowing:

   • New reports inherit the filter. A Composer building a new report on the same category will see filtered data themselves and produce reports that filter correctly for every other user. They can't accidentally build an unfiltered report.
   • Dashboards inherit the filter. Reports inside dashboards filter per the dashboard viewer's tag values. The same dashboard shown to two users shows two different slices.
   • Scheduled exports inherit the filter. The recipient's tag values determine what their copy of the report contains.
   • Drill-downs inherit the filter. Click-through detail views still respect the RLS constraint.
   • Admins are not bypassed. An admin without a matching tag value sees nothing — same as any other user. This is by design and is auditable (admin changes to RLS policies appear in the audit log).

   The mechanism is the dynamic SQL DashboardFox writes; the filter is baked into the WHERE clause every time. There's no separate "RLS-aware report" toggle to remember.

8. Always log out and back in to test

   Policy and tag changes don't take effect mid-session. After every change you want to verify, log out and back in as the test user. Until they re-authenticate, they're still operating with the cached values from their last session.

   The most common "I changed the policy and nothing happened" report traces back to this. Build the log-out-log-in step into your verification loop and you'll save yourself a lot of confusion.