Most BI platforms implement row-level security as a per-report configuration problem: you open each report, define the filter rules, and attach them to user roles. The more reports you have, the more places you manage security. DashboardFox takes a different approach: you define a security policy once, reference it dynamically using Data Tags assigned to users or groups, and that policy applies automatically across every report that references the secured data — without touching the reports themselves.
This chapter explains how Data Tags work, walks through the configuration logic, and covers the use cases where this approach has a meaningful operational advantage over traditional per-report RLS configuration.
A Data Tag is a named, administrator-defined attribute that can be assigned to individual users or entire departments, with a specific value that represents their data access scope. When a user runs a report, DashboardFox looks up their Data Tag values and injects those values into the query as filter conditions — automatically, at query time. The user sees only the rows that match their tag values. Admins, who have no tags applied, see everything.
The Problem with Per-Report Security Configuration
Before getting into how Data Tags work, it's worth understanding what they replace. In many BI tools, configuring RLS means opening each report individually and attaching security rules to it. If you have 50 reports and want data isolation across all of them, you configure security 50 times. When you add a new report, you configure security again. When you bring on a new client or department, you may need to revisit every report to ensure the new user's access scope is correctly represented.
This is manageable at small scale. It becomes an administrative burden as the report library grows. And it's fragile — a new report built by an analyst who forgets to attach security rules is a data exposure waiting to happen.
Data Tags invert the model. Security is defined centrally, at the policy level, linked to named tags. As long as reports are built on secured data sources, the policies apply automatically. A new report doesn't require a separate security configuration step — the policy is already in place.
How Data Tags Work: The Configuration Flow
Setting up Data Tags-based RLS in DashboardFox involves three steps: creating the tag, assigning values to users or groups, and creating the security policy that references the tag.
Step 1: Create the Data Tag
A Data Tag has a name — something that describes the security dimension you're working with. Common examples: tenant_id, client_name, region, driver, department. The tag name is how the security policy will reference it. You choose a name that maps to a field in your database — because the tag value will be matched against that field when filtering queries.
Tags can hold character-based values (strings), which covers the majority of real-world use cases. A tenant ID, a client name, a region identifier, an employee ID — all string values that can be matched against database fields.
Step 2: Assign Tag Values to Users or Departments
Once the tag exists, you assign values to users or departments. For a client_name tag, you'd assign "Acme Corp" to all users who belong to the Acme Corp client account, "Globex" to Globex's users, and so on. For a region tag, "Southeast" goes to the Southeast team, "Northwest" to the Northwest team.
The assignment can happen at the individual user level or at the department level — which is the more scalable approach. If you assign the tag at the department level, every user in that department inherits the value. Adding a new user to the Southeast department automatically gives them the Southeast data scope without any additional configuration.
A single tag can hold multiple values for a user or group. If a manager oversees both the Southeast and Central regions, they can have both values assigned — and they'll see data from both. The policy supports is equal to for exact single-value matches, and is in the list for multi-value scenarios. This flexibility covers the "manager who oversees multiple territories" case without needing special handling.
Step 3: Create the Security Policy
The security policy is where the Data Tag is connected to the actual database field it should filter. You configure:
Which App (semantic layer) the policy applies to. DashboardFox's Apps are the semantic layer that defines how your data tables are structured. You select the App that contains the data you're securing.
Which field in that App is the security field. This is the column in your database that holds the value the tag should be matched against — the client_name column, the region column, the driver_id column, whatever maps to your tag.
The constraint type. Is equal to, is in the list, or other comparison operators depending on your use case.
The value — referenced as a dynamic tag parameter. Instead of a hardcoded value like "Acme Corp", you reference the tag using the syntax /#tagname#/. For a tag named client_name, the policy value would be /#client_name#/. At query time, DashboardFox substitutes this with the actual tag value assigned to the current user.
Who the policy applies to. You can apply it to all users, specific departments, or specific individual users. Critically, users with no tag value assigned — such as administrators — are not affected by the policy, so they continue to see unfiltered data. This is the expected behavior: admins see everything; users see their permitted scope.
Data Tags are available in every DashboardFox plan starting at $99/month. Set up your security model in the free trial and validate it against your actual data before committing.
A Concrete Example: Multi-Client Reporting for an Agency
An agency manages reporting for 15 clients. All client data lives in the same database — a client_transactions table with a client_id column identifying which rows belong to which client.
Without RLS, the agency either builds 15 separate filtered reports per client (unscalable) or gives clients a login where they'd see all 15 clients' data (unacceptable). With Data Tags:
The administrator creates a tag named client_id. They assign the appropriate client ID value to each client's user account or department — "ACME001" to Acme's users, "GLOBEX002" to Globex's users, and so on. They create a single security policy: field client_id is equal to /#client_id#/, applied to all non-admin users.
Now every report built on that data source automatically enforces client isolation. A client logs in, runs the Sales by Month report, and sees only their sales data. The agency admin runs the same report and sees all clients. When the agency onboards client 16, they create their user account, assign the new client ID to their tag, and they're immediately restricted to their own data across every report — without touching a single report file.
A Concrete Example: Regional Sales Management
A national company has a central sales database. Regional managers should see only their region's pipeline. The VP of Sales should see everything. Individual reps should see only their own accounts.
This requires two security policies — one filtering by region (for managers), one filtering by rep ID (for reps). Two Data Tags: region and rep_id.
Regional managers get a region tag with their region value. Individual reps get a rep_id tag with their ID. The VP has no tags — they see everything. Two policies, two tags, and the security model covers three distinct user types across the entire report library. Adding a new rep or a new manager requires assigning the appropriate tag value to their account — no report edits.
Profile Tags vs. Data Tags — When to Use Each
DashboardFox also supports a simpler mechanism called profile tags — attributes stored directly on the user's profile that can be referenced as security parameters. Profile tags work well for purely one-to-one relationships: one user, one value, one segment. If every user maps to exactly one region and never changes, profile tags are slightly simpler to set up.
Data Tags are the recommended approach when: the relationship between users and data segments is one-to-many (a manager covering multiple regions), you want department-level assignment rather than individual user editing, or you want a centralized place to manage security values that isn't buried in individual user profile settings. For any multi-client or multi-tenant scenario, Data Tags are the cleaner architecture.
Why "Assign Once, Filters Everywhere" Matters at Scale
The operational payoff of the Data Tags model becomes clearest as your report library grows. At 10 reports it's a minor convenience. At 100 reports it's the difference between a manageable system and one that requires dedicated administrative overhead to maintain.
The security model is defined in one place. Reports don't need to know about it — they just query data, and the security layer intercepts and filters at query time. An analyst building a new report doesn't need to configure security for that report; the existing policy already covers it. A new client or department gets access by having their tag value assigned to their account — security follows them automatically.
This is the practical advantage of policy-based, centralized RLS over per-report configuration. It's not just simpler to set up; it's more reliably maintained as the system grows.
