Permission Configuration Examples

Use these examples to combine workspace capabilities, access to individual objects, and data filters. Start with Choose What to Protect to select the controls you need. The object, group, and subscription-plan names below are illustrative. Use names and resources that fit your organization; access comes from the permissions you assign.

Before applying an example, review how access is evaluated. Every additional group, workspace-wide grant, or inherited grant can increase a user’s access. Test with users who have the intended memberships and no administrator permissions.

Shared Content and Self-Service Analytics

Goal: Let everyone use a maintained set of metrics and visualizations while analysts create and share their own content in the same workspace.

For this example, create organization-level groups for the people who maintain shared content and those who create their own analyses. We call these groups Content Maintainers and Self-Service Analysts. Configure their access as follows:

1. Make the maintained content available to All workspace members at VIEW level.
2. Grant Content Maintainers EDIT on that content.
3. Set creation defaults for metrics and visualizations to RESTRICTED.
4. Let creators share their own objects with selected users or groups. Make the intended recipients discoverable.
5. Share the dashboards and all dependencies needed by their audiences.

Members of Self-Service Analysts can use maintained content without changing it. Their new content starts restricted, and they choose when to share it. A creator’s EDIT grant allows them to manage their own object.

Review MANAGE_VISUALIZATIONS before relying on this separation: it allows managing every saved visualization. In migrated organizations, also review automatic visualization-management grants.

Protect Sensitive Columns in a Shared Workspace

Goal: Show company-wide analytics to employees while limiting salary data to an authorized group.

For this example, suppose your model contains a fact you named Salary. You have also created a shared dashboard and an organization-level group named Finance for the users who should have access to salary data.

1. Give the intended dashboard viewers access to the workspace and the dashboard.
2. Set the Salary fact to Restricted and grant Finance VIEW on it.
3. Review other columns that expose the same sensitive information, including attributes and secondary labels, and restrict them where needed.
4. Give Finance access to the metrics and visualizations needed for salary analysis. Share general company analytics with the broader audience.
5. Test the dashboard with one member of Finance and one user outside the group.

Assuming no other grant provides access, a non-administrator outside Finance cannot use Salary to compute a result, even through a metric or visualization shared with them. The dashboard still opens, with placeholders for widgets that depend on Salary. Widgets using accessible inputs continue to work.

If a visualization combines a metric that uses Salary with metrics whose inputs are accessible, the whole visualization is unavailable to a user who cannot access Salary. Put the accessible metrics in a separate visualization when that user should still see them.

Use user data filters when users or groups should see different rows of the same accessible column within a workspace. For tenant child workspaces, see the multitenant example below. Review columns referenced by user data filters before restricting them; the filter’s dependencies are also subject to access checks. See Columns.

Share Analytics Across Tenant Workspaces

Goal: Maintain analytics in a parent workspace while each tenant uses those analytics with its own data in a child workspace.

Suppose you have a parent workspace named Shared Analytics and two child workspaces named Tenant A and Tenant B. Create separate organization-level groups named Tenant A Readers and Tenant B Readers. In the parent, maintain a Revenue metric, a saved visualization that uses it, and an Overview dashboard that contains the visualization.

1. Build the workspace hierarchy. Keep access to the parent workspace with the people who maintain shared content. In each child, grant local workspace VIEW to that tenant’s reader group. Do not grant those readers access to the parent or the other tenant’s workspace.
2. Configure workspace data filters and assign the appropriate tenant value in each child. Check the filter mappings for every dataset that contains tenant data; a dataset without the required mapping is not restricted by that filter. Reserve MANAGE for trusted administrators who can change the model and permissions.
3. Review inherited grants before sharing content. For content shared by both tenants, give each tenant group VIEW on the required objects in its own child workspace, as shown below. Check the full dependency chain, including inputs used in filters and sorting.
4. Keep tenant-specific content Restricted and grant it only to its intended audience. Add tenant-specific grants in the child. A grant inherited from the parent cannot be removed or lowered there. An All workspace members grant made in the parent refers to the parent’s membership; do not assume it covers child-only users.
5. If users within a tenant need different rows, add user data filters for those users or groups. Keep the columns required by those filters accessible.
6. Test with a non-administrator from each tenant, including through any integration that serves the analytics.

Both audiences use the inherited analytics, and data filters limit their results to the intended rows. Sharing only the dashboard would leave widgets unavailable wherever required inputs are inaccessible.

Verify that each reader can use the complete analytics in their own workspace, sees only their tenant’s data, and cannot enter the parent or sibling workspace. Check tenant-specific objects separately. When authors share through the UI, also make the intended recipients discoverable; discoverability does not grant access to content.

Offer Different Analytics by Subscription Plan

Goal: Give customers on different subscription plans different analytics while maintaining shared content.

Suppose your product offers two subscription plans that you call Basic and Premium. In this example, you create organization-level user groups with the same names and assign your customers to the appropriate groups.

If customers also need different data rows, configure user data filters or workspace data filters separately. The groups’ grants control access to content; row filters control which customers’ data can appear in it. A subscription-plan group can contain users from several tenants, so plan membership alone does not isolate tenant data. For a workspace-per-tenant setup, use Share Analytics Across Tenant Workspaces alongside this example.

For objects reserved for Premium subscribers, set General access to Restricted and grant access to the Premium group. Check for other grants that would give members of Basic access. Tags and naming conventions do not restrict access.

On a shared dashboard, members of Basic see content they can access and placeholders for widgets that require access to objects reserved for Premium. If you also create a separate dashboard for Premium subscribers, share it with the Premium group.

If members of Basic can create their own analyses, restricting only a visualization included in Premium does not protect data they can still access through its inputs. Restrict the relevant metrics or columns according to what your plan is intended to protect.

In a workspace hierarchy, configure grants in the workspace where they should apply. Access granted in a parent cannot be withdrawn in a child. See Workspace Hierarchies.

Apply Permissions to AI and Integrations

Goal: Let users work with AI Assistant or an integration while preserving their access to analytics.

1. Configure workspace and object access for the intended audience.
2. Grant USE_AI_ASSISTANT to users who need AI Assistant.
3. Add creation capabilities only when users should save new objects. For example, saving a metric requires CREATE_METRIC; reading an existing metric does not.
4. Authenticate integration requests as the user whose permissions should apply. For a service account, configure the account’s groups and grants for the work it needs to perform.
5. Test both accessible and restricted content through the interface users will use.

The authenticated identity determines access. An MCP server or another integration configured with administrator credentials has administrator access, even when a person with fewer permissions asks the question.

Objects created by a service account follow the configured creation defaults. When they start restricted, share them with the intended audience before expecting other users to find or use them.

Verify a Restricted-Data Setup

Goal: Check that an audience can use its intended analytics and cannot use sensitive data.

Use groups to make the grants easier to review. For each test user, record the workspace access, group memberships, relevant object grants, and inherited access, then check:

For a multitenant setup, also verify row isolation with a non-administrator from each tenant. An accessible object can still expose the wrong rows if data filters are missing or misconfigured. Check both the returned data and access to parent or sibling workspaces, using the tenant example.

Object restrictions cannot exclude an organization administrator or an applicable workspace administrator. Review who holds MANAGE, including through groups and hierarchy grants, as part of the access review.

Also review exports and scheduled delivery before using them to distribute restricted content. A dashboard check alone does not establish what a scheduled attachment will contain.