Overview

In Datarails, all data is stored and organized in data tables — structured datasets that serve as the foundation for every report, dashboard, Excel output, and metrics in the platform. The table element is the primary unit of data access in the system: when a user is given access to a table, they gain visibility into the data it contains across all outputs built from it.

Table Access is Data Access

Sharing a table with a user is the mechanism through which data access is granted in Datarails. Unlike sharing a dashboard or a report space — which controls whether a user can open that element — sharing a table directly controls what data that user can see in every output derived from it. A user's access to a table will grant access to that table's data reflected in any dashboard, report, or Excel output which they are shared on, or when working with AI Agents.

Table Access Levels

Tables support two access levels:

• Owner — Full control over the table: modify and delete the table, manage its permissions, grant access to other users, and configure permission filters to control what data each Viewer can see.

• Viewer — The user can see and work with the table's data in any output they have access to (reports, dashboards, Excel functions, KPIs). They cannot modify the table structure or grant access to others. To limit viewers, you can apply a permission filter that narrows down the data a user can access.

Tables have no Editor level — only Viewer and Owner. A user's system role determines which levels they can receive. Only Manager, Admin, and Super Admin can be granted Owner or Viewer.

Permission Filters

A permission filter restricts the data a specific user can see within a table, based on one or more dimension values. The filter applies to all outputs generated from that table for that user.

Setting Up a Permission Filter

1. Go to Members & Groups in the left navigation bar.

2. Click on the user's name to open their profile.

3. Navigate to the Element-level permissions section and select the relevant table.

4. Click Edit Permission Filter on that table.

5. In the filter window, select the dimension you want to filter on (e.g., Department, Region, Entity).

6. Choose the allowed values for that dimension (e.g., "Customer Success", "Finance").

7. Click Save. The filter takes effect immediately across all outputs for that user.

8. When applying multiple dimension restrictions to a single user, an AND operation is applied to the different filters — the user sees only data that matches all conditions simultaneously (e.g., Department = "Finance" AND Region = "EMEA").

If a user receives access to the same table from more than one group, an AND operation is applied to all permission filters.

Blocking Drill-Downs

By default, when a user has a permission filter, their drill-down access is automatically scoped to their permitted data — they cannot drill into rows outside their filter. You can additionally block drill-down access entirely, preventing a user from accessing any row-level detail regardless of their filter settings.

This is useful when:

• You want users to see summary-level metrics only (e.g., totals by department) but not the underlying transaction rows.

• Regulatory or compliance requirements restrict row-level data visibility.

How to Block Drill-Downs

In the user's permission filter settings for a table, enable the Block Drill-Down option. Once enabled, the user will see aggregated data in outputs but will not be able to expand or drill into individual rows.
 

Note: Managers and Admins with block drill will still be able to creating output with this data, bypassing the limitation is possiable by breaking the data to unique value per row fileds.

Access to Metrics & Working with Dimensions

Permission filters in Datarails operate at the semantic layer — the unified data model (UDM) that underpins all outputs in the platform. This means a filter applied to a table dimension automatically scopes every metric, KPI, report, and dashboard derived from that table to the user's permitted rows.

How the Semantic Layer Applies Filters

• When a user generates a report or opens a dashboard, Datarails queries the semantic layer and applies their permission filter before returning any data.

• Metrics (e.g., Total Revenue, Headcount) are calculated only on the rows the user is permitted to see — they do not see an aggregation of all data with restricted rows hidden.

• Dimension values not included in the user's filter will not appear in dropdowns, filters, or drill-down options within the UI.

Choosing the Right Dimension

Any dimension in your data table can be used as a permission filter. Common examples include:

• Department — limit access to a specific department's data

• Region / Entity — scope access by geography or legal entity

• Cost Center — restrict visibility to specific cost centers

Choose a dimension that maps cleanly to your organization's data ownership structure. The filter is only as precise as the dimension values in your data model.

Backward Compatibility

Behind the scenes, we have replaced the logic from filebox-based permissions to the new table permission framework. This ensures no existing user loses access to data they were previously able to see nor gains access to data they had no access to.

Permission filters were automatically created to preserve each user's existing data access. If a user had access to all Fileboxes mapped to a table, that user received viewing permissions to the table without a permission filter applied. For a user with access to a subset of Fileboxes mapped to the table, that user received viewing permissions with a permission filter based on the Filebox IDs, covering all the values of the Fileboxes in the subset.

If you have questions about migrated filters or need help reviewing your organization's data access after migration, contact your Datarails Customer Success Manager.

Updated June 16, 2026 07:58