Metric Permissions

Beta Feature

Metric Permissions is a beta feature. Its behavior and available settings may change in future releases. Do not use it in a production environment.

Metric permissions control who can view, use, share, edit, or delete an individual saved metric. Use them to share a metric with its intended audience or let someone maintain its definition without making them a workspace administrator.

To try this beta feature, enable it in Settings > Early Access for the workspaces where you want to use it. See Enable Early Access Feature.

Creating a metric and accessing an existing metric are separate permissions. To create new metrics, a user needs the workspace-level Workspace.CREATE_METRIC permission, which is included in Workspace.MANAGE. The visibility and grants described in this article control access after the metric exists.

Before You Start

A metric grant does not replace access to its workspace. Workspace permissions also control access to authoring tools. Opening the Metric editor, Catalog, or Analytical Designer requires Workspace.ANALYZE or Workspace.MANAGE. A grant on a metric, or Workspace.CREATE_METRIC added to Workspace.VIEW, does not open these tools.

A user’s access to the metric also does not override permissions on the objects it references. To compute the metric, the user must be able to access its dependencies. See Dependent Metrics and Columns.

Metric Creation

Workspace.CREATE_METRIC is an add-on. It is included in Workspace.MANAGE. It is not included in Workspace.VIEW or Workspace.ANALYZE. You can assign it on top of VIEW or ANALYZE.

Workspace.CREATE_METRIC gates saving a metric. It does not by itself open the Metric editor, Catalog, or Analytical Designer.

ANALYZE + CREATE_METRIC — users can create metrics in the user interface.
VIEW + CREATE_METRIC — users can create metrics through the AI Metric skill, MCP create_metric, and the API or Python SDK.

Assign CREATE_METRIC from Users & groups on the home page, or through the workspace permissions API. You can assign it to users or organization-level user groups. See Manage Workspace Permissions.

Without CREATE_METRIC, creating a metric is unavailable in the user interface (the action is hidden or disabled). The API, Python SDK, MCP create_metric tool, and AI Metric skill return 403 Forbidden.

If the metric definition references a fact, attribute, label, or metric the caller cannot access, the request is rejected with 404 Not Found, the same as an unknown identifier.

Visibility and Grants

A metric’s access policy combines a general visibility setting with grants for individual users or organization-level user groups. Workspace-level user groups are not supported.

Visibility States

Visibility	Who can read and use the metric
Restricted	Users and groups with an explicit metric grant, plus workspace and organization administrators.
All workspace members	All workspace members have implicit read access. This does not grant sharing, editing, or deletion rights.

New metrics default to Restricted, and the creator automatically receives EDIT. Until the metric is shared, other non-admin users do not have access. Workspace and organization administrators retain access regardless of visibility.

When a metric is visible to all workspace members, they have implicit VIEW access. Sharing requires SHARE or EDIT; editing or deleting requires EDIT. Administrators retain their elevated access. In both visibility states, access to the metric’s dependencies is enforced separately.

Existing metrics stay visible to all workspace members, so current access does not change. You can restrict those metrics later.

Grants and Access Levels

Metric grant	What the user can do
`VIEW`	Read the metric definition, including its MAQL, and use the metric, subject to access to its dependencies.
`SHARE`	Everything allowed by `VIEW`, plus share the metric with others. This does not allow editing or deleting the metric.
`EDIT`	Everything allowed by `SHARE`, plus update the metric definition or delete the metric.

EDIT is the highest metric grant. Use SHARE for users who should manage sharing without changing or deleting the metric. Use EDIT for users who maintain its definition.

Set Permissions for a Metric

To manage sharing, you need SHARE or EDIT on the metric, or administrator access. To use the Catalog or Metric editor, you also need the workspace permissions described in Before You Start.

Open the metric in the Catalog. You can also manage access from the Metric editor, including the embedded editor in Analytical Designer.
Open the metric’s access settings.
Choose the intended audience: Restricted, with grants for selected users or organization-level user groups, or All workspace members for read access for everyone in the workspace. When adding a user or group, choose an available grant level for the actions they need to perform.
Apply the access changes. Check that the intended users can also access the objects the metric depends on; sharing the metric does not share those objects.

Remove Access

Review all of a user’s access paths before removing a grant. Removing an individual grant does not remove access the user still has through a group, All workspace members visibility, or administrator permissions.

Changing visibility from All workspace members to Restricted removes workspace-wide read access but preserves individual and group grants. Review those grants as well when narrowing the audience.

Last EDIT Self-Removal Protection

If you hold the last remaining EDIT grant on a metric, you cannot remove your own grant. Grant EDIT to another user or organization-level user group first, then remove your grant.

Edit or Delete a Metric

A user with EDIT can change the metric definition and delete the metric, as well as share it. VIEW and SHARE do not allow changing or deleting the metric. Administrators retain their elevated access.

Updating an existing metric does not require Workspace.CREATE_METRIC; it requires EDIT on that metric or administrator access. For example, a user with Workspace.ANALYZE and EDIT can maintain a shared metric in the Metric editor without having permission to create new metrics.

Deleting a Metric Cannot Be Undone

Deleting a metric can break visualizations and dashboards that depend on it. Review the impact before deleting a shared metric. Changing its definition or removing access can also affect downstream analytics.

Behavior and Enforcement

The same metric access policy is enforced in the Metric editor, Catalog, Analytical Designer, API, Python SDK, MCP server, and AI Assistant. Using a different interface does not bypass it.

Users without access cannot see or compute a restricted metric. Direct access, including a direct link or API request, returns 404 Not Found so that the response does not disclose the metric’s existence. API access and included relationships do not bypass the restriction.

Dependent Metrics and Columns

Restrictions apply through the full dependency chain. If a user cannot access a fact, attribute, label, or metric used by a metric, the dependent metric cannot be computed. Any other metric that depends on that blocked metric is blocked as well. Visualizations and dashboards cannot use a blocked metric to obtain a result.

This remains true even when the dependent metric is visible to all workspace members or the user has an explicit grant on it. Sharing a metric does not grant access to its dependencies, and sharing a dashboard does not grant access to its metrics.

For example, sharing a Profit metric with all workspace members does not make a restricted Cost fact available. A user without access to Cost cannot compute Profit.

A blocked metric never returns a partial value. GoodData does not omit inaccessible dependencies and compute the rest of the metric. This rule cannot be relaxed by a setting. How a visualization or dashboard renders is separate from whether the metric can be computed.

See Column-Level Permissions for restrictions on facts, attributes, and labels, and Manage Dashboard Permissions for dashboard access.

Administrators and Integrations

Users with Workspace.MANAGE can access all metrics in that workspace, regardless of visibility or grants. Users with Organization.MANAGE have the same access across the organization. Metric restrictions do not hide metrics from these administrators.

API, Python SDK, MCP, and AI Assistant operations use the permissions of the identity making the request. An integration does not provide additional access to restricted metrics or their dependencies.

New metrics created by a pipeline follow the same default as other new metrics: Restricted, with EDIT granted to the creating service account. Share those metrics with the intended users or groups before expecting the team to use them. Administrators retain access.

Permission Errors

Creation and object access fail differently:

Situation	Result
The caller attempts to create a new metric without the capability provided by `Workspace.CREATE_METRIC` or administrator access.	403 Forbidden. This is a missing capability to perform the creation action.
The caller requests an existing metric without permission to access it.	404 Not Found. The response does not reveal whether the metric exists.
The caller has metric-creation permission, but the submitted MAQL references an inaccessible fact, attribute, label, or metric.	NOT FOUND, just as if the referenced object did not exist. The error does not name the restricted object or identify permissions as the cause.

For a creation-related 403 Forbidden, ask an administrator to check the workspace metric-creation permission. For NOT FOUND, check the identifiers in the definition and ask an administrator to verify the required access. The response intentionally does not distinguish a missing object from one the caller cannot access.

AI Publisher

Visualization Permissions