In the Semantic Layer, you don’t share metrics manually. Access to a metric is derived automatically from the data permissions users already have on the underlying source tables, plus the dimensions defined on the metric. The result: anyone who can already see the underlying data can use the metric, and anyone who can’t is automatically blocked.

This article explains how that automatic access model works and how to debug why a specific user can’t see a metric you expect them to see.

How metric access works 

For a user to use a metric, two requirements must both be true:

Access to every source table the metric depends on

The user must have at least view access to every source table the metric reads from. For a calculated metric, this includes every table referenced by the metrics in the formula, including metrics that are themselves built from other metrics.

If the user lacks access to even one of those tables, the metric is hidden from them entirely.

Permission filters covered by the metric’s dimensions

Some users have permission filters on certain source tables that limit what data they can see - for example, a regional sales lead who is filtered to East-region accounts only. For the user to use a metric built from that table, every field the user is filtered on must be mapped as a dimension on the metric.

An example of how this rule plays out:

• John is a regional sales lead. His Datarails account has a permission filter on the Sales table that restricts him to Region = East.
• A Sales Revenue metric is built from the Sales table and includes Region as a dimension. John has access: the system can apply his East filter to the metric’s results.
• A Total Revenue metric is built from Sales but does not include Region as a dimension. John has no access: without Region in the metric, the system can’t restrict the result to his allowed scope, so it blocks him from the metric entirely.

Practical implication for metric builders: If you want a metric to be usable by users who have permission filters on the source table, make sure those filtered fields are mapped as dimensions on the metric. Otherwise those users will be silently blocked.

See who can and can’t use a metric 

You can open the Who can view this metric dialog from your metric’s row in the Metrics & dimensions page. The dialog is useful when a teammate reports that they can’t find a metric they expect to see, or when you want to verify which audience your metric reaches before publishing it.

The list - and the counts shown alongside it - includes only users who have at least view permission on the metric’s source table. Users without any access to the source table are outside the perimeter and aren’t counted.

The dialog looks slightly different depending on whether you’re inspecting a base metric or a calculated metric.

For a base metric

The dialog opens with an information banner:

“Access is determined by the source table permissions. A filter set on a field that is not defined as a dimension will prevent members from viewing the metric.”

Below the banner, two lists are shown:

• Table viewers without access to this metric (N) - users who have view access to the source table but can’t use this metric because their permission filters aren’t covered by the metric’s dimensions. Each row shows the user, their role, and the filter fields that aren’t covered (for example, “Filter by fields: Filebox ID, Region”).
• Table viewers with access to [metric name] (N) - users who can use the metric. The list header includes a Manage table permissions link so you can navigate directly to the source table’s permission settings.

To restore access for a restricted user, either add the missing field as a dimension on the metric, or adjust the user’s permission filters via the table-permissions screen.

For a calculated metric

Because a calculated metric inherits its access from the metrics referenced in its formula, the dialog has a different shape. The information banner reads:

“Access is based on permissions for the metrics included in the formula. To view this metric, users must have permission to all metrics used in the formula.”

A single list - Members with access to [metric name] - shows everyone who has access to every metric referenced in the formula (the intersection of access lists).

Below the user list, each input metric referenced in the formula appears as an expandable row (for example, “Revenue metric permission”). Expand a row to see that input metric’s own permissions - useful for investigating why specific users are or aren’t included in the calculated metric’s audience.

When access changes 

Metric access is recalculated immediately whenever any of the following happens:

• A user’s access level on a source table changes.
• A metric’s source tables or formula dependencies change.
• A dimension is added to or removed from a metric.
• A permission filter is added to or removed from a user.

No session restart or manual refresh is required. The next time the user loads a metric-consuming surface, their access reflects the latest state.

Related articles 

• Key concepts and terminology
• Creating a base metric
• Creating a calculated metric
• Managing dimensions

Updated August 04, 2026 18:48