Manage Permissions

Permissions and data filters work together to control access to your analytics. Workspace permissions determine who can enter a workspace and what they can do there. Object permissions determine who can view, share, or edit individual columns, metrics, visualizations, and dashboards. Data filters limit which rows appear in the analytics a user can access.

You can combine these permissions in one workspace. For example, you could let everyone use metrics that calculate revenue, allow selected analysts to maintain those metrics, and restrict salary data to a group you create for your finance team.

Choose What to Protect

Start with the information or action you need to control. A setup can require several of these controls:

Restricting a dashboard or visualization does not stop someone who can access its inputs from building another analysis with those inputs. For example, if your model contains a fact that stores salaries, restrict that fact to protect the data wherever it is used in analytics. If authorized users should see salaries only for their own department, also configure a data filter.

Data filters do not grant access to workspaces or objects. Object permissions do not select a tenant’s rows. Dashboard filters let viewers explore data; use user or workspace data filters to enforce row restrictions.

Workspace and Object Access

When configuring access, answer these questions separately:

Creating an object does not require edit access to other objects of the same type. Editing an existing object does not require permission to create a new one. An object grant also does not open an authoring tool: Catalog, Analytical Designer, and the Metric editor require the appropriate workspace access.

Administrators have broader access. Organization administrators can access all objects in the organization. Workspace administrators can access all objects within the scope of their MANAGE permission. Object restrictions do not exclude these administrators.

Where Permissions Are Assigned

A grant assigns a permission to a user or user group on a resource. For example, suppose you create a metric named Revenue and a user group named Finance. A grant can give that group VIEW on the metric. The same group can hold different permissions on another metric or in another workspace.

Use organization-level user groups for people who need the same access. Grants belong to the resource even when you assign them from Users & groups.

Workspaces can form parent-child hierarchies. Workspace grants can apply locally or include descendants, and grants on inherited objects follow those objects into child workspaces. See Workspace Hierarchies.

Object Access Levels

Choose the access level that matches what a recipient needs to do:

Each level includes the levels below it. You cannot grant a higher level than you hold. For columns, changing or deleting the logical data model still requires <workspace>.MANAGE, even when a user has <column>.EDIT.

An object’s General access setting determines its audience:

• Restricted: Access comes from grants to selected users or groups, including applicable inherited grants.
• All workspace members: A workspace-wide grant provides access without adding each user separately. Its default level is VIEW.

Grants to individual users or groups can give selected people a higher level. For example, you could let everyone in the workspace view a metric and give a group of its maintainers permission to edit and share it. Administrator access and capabilities such as MANAGE_VISUALIZATIONS still apply to restricted objects.

How Access Is Evaluated

GoodData combines direct grants, group grants, workspace-wide grants, and inherited grants. The highest applicable access level wins. There are no deny rules that override another permission grant. This rule describes permission grants; data filters separately limit the rows available to calculations.

For a non-administrator with workspace access, these grants on a metric produce the following results. Assume no other grants apply:

Removing one grant removes access only if no other grant or capability still provides it. A child workspace can add access to an inherited object, but cannot narrow access granted by its parent.

For an action to succeed, the user must have:

1. Workspace access: VIEW or a permission that includes it.
2. Object access: The level needed for the action on the existing object.
3. Dependency access: Access to the inputs needed for a calculation, including inputs used by filters and sorting.
4. Any additional capability: For example, permission to create a metric, export data, or use an authoring tool.

Access to Dependencies

Sharing an object does not share its dependencies. A dashboard, its visualizations, the metrics they use, and the underlying columns each have their own access settings.

Metrics and visualizations require all the inputs needed to compute their results. GoodData does not remove an inaccessible metric from a chart or skip part of a formula to produce a partial result.

Dashboards can display the content a user can access while showing placeholders for unavailable content. For example, you could create a dashboard that displays sales figures to all its viewers and salary figures only to viewers with access to the required salary data. See Dashboards with Restricted Content.

Permissions in AI and Integrations

The same object access rules apply in the UI, APIs, SDKs, AI Assistant, Smart Search, and the MCP server. Requests use the permissions of the identity making them. An API token uses its account’s current permissions.

An integration authenticated as an administrator has that administrator’s access. To preserve a user’s restrictions, authenticate requests as that user. See Apply Permissions to AI and Integrations.

Permissions and Multitenancy

When serving multiple customers, departments, or other tenants, plan workspace access, content access, and row restrictions together. Set Up Multiple Tenants explains how to organize and reuse analytics across tenants; this guide explains how to grant access to those analytics.

A workspace hierarchy distributes shared definitions. Configure and verify row restrictions separately; creating a child workspace alone does not select that tenant’s data. Likewise, inheriting a dashboard does not give its audience access to all the visualizations, metrics, and columns it uses.

Use Workspace Hierarchies to choose where grants apply. For a complete example, see Share Analytics Across Tenant Workspaces.

Configure Permissions