Hello, we’re looking into using the GoodData API to show analytics info outside the GoodData UI but are trying to understand if there is a way to restrict insights and metrics per user similar to how we have dashboard permissions set up. Can you confirm how permissions work for insights and metrics? • Is there a way to control who can see or use specific insights or metrics the same way as dashboards? Or is access only via workspace role, with data filters for row-level control? • If we call the API as an end user token, is there a way to control what insights and metrics that user can see? • Do you have any workarounds or ideas as to how we could implement this?

Great question! Here's what the knowledge sources confirm about permissions for insights and metrics in GoodData: Permissions for Insights and Metrics Insights and metrics do not have their own granular permission settings like dashboards do. As confirmed by GoodData support: > "Metrics and Visualizations don't contain permission setting as Dashboard or Workspace. The available user roles can only distinguish whether a user can create or manage a metric." [Slack thread] So to directly answer your questions: 1. Can you control who sees specific insights/metrics like dashboards? No — there is no object-level permission for individual insights or metrics. Access is controlled at the workspace level via roles (VIEW, ANALYZE, EXPORT, MANAGE, etc.), not per insight or metric. [Manage Permissions] 2. API tokens and what users can see API tokens are tied to a specific user and inherit that user's permissions. So if a user has limited workspace access, their API token will reflect those same restrictions. However, you cannot restrict a token to only specific insights or metrics — the token operates at the user's full permission level within the workspace. [Slack thread] 3. Workarounds / Recommendations The recommended approaches for data-level restriction are: • User Data Filters (UDF) — Row-level security using MAQL expressions, applied per user or user group. These restrict what data a user sees across all insights and metrics in a workspace, propagating through the Logical Data Model (LDM). [User Data Filters] • Workspace Data Filters (WDF) — Restrict data at the workspace level, useful in parent-child workspace hierarchies. • Workspace hierarchy + roles — Place users in workspaces where they only have access to the relevant content, and use workspace-level permissions to control what actions they can perform. > Important note: Dashboard filters alone are not a proper security mechanism. GoodData support has confirmed that relying on dashboard filters to restrict data can result in unintended data access (e.g., via tabular export API). Only WDFs and UDFs are considered proper data restriction features. [Slack thread] In summary, if you need to restrict what data users see in insights/metrics when calling the API, User Data Filters are the recommended approach. If you need to restrict which insights/metrics are visible at all, the knowledge sources do not describe a native mechanism for that beyond workspace-level role separation. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

@kapa.ai, user data filters are still the recommended approach when accessing data via API token outside of GoodData?

Yes, User Data Filters (UDFs) remain the recommended approach for restricting data access when using API tokens outside of GoodData's UI. GoodData support has explicitly confirmed that API tokens are tied to specific users and inherit their permissions — meaning the token will reflect whatever data restrictions are applied to that user. [User Token Docs] Critically, it has also been confirmed that dashboard filters are not a security feature and should not be relied upon for data restriction when accessing data via API. For example, using the tabular export API endpoints can bypass dashboard-level filters and expose data outside the intended scope. [Slack thread] The GoodData team's guidance is clear: > "Only Workspace and User Data Filters are considered proper features to restrict the data." So whether a user is accessing data through the GoodData UI or via API token, UDFs and WDFs are the only mechanisms that reliably enforce data-level security. UDFs in particular are well-suited for per-user or per-group restrictions, as they use MAQL expressions that propagate through the Logical Data Model and apply consistently regardless of how the data is accessed. [User Data Filters] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

@Steve Fox for reference

@kapa.ai what about using gooddata groups? • We primarily drive our workspace permissions through gooddata groups • Do the group permissions get reflected when a user leverages the API to receive data?

Yes, group-based permissions are fully reflected when users access data via the API. Here's what the knowledge sources confirm: Group Permissions and API Access API tokens inherit the user's permissions, which includes any permissions granted through group membership. Since workspace permissions are commonly assigned at the group level, a user's API token will respect those group-based workspace roles (VIEW, ANALYZE, EXPORT, MANAGE, etc.). [Slack thread] User Data Filters and Groups Importantly, UDFs also work with user groups — you can define data filters at the group level, not just for individual users. The effective filters for a user are inherited from all user groups they belong to throughout the workspace hierarchy, and multiple group filters are combined using the AND operator. [User Data Filters] This means if you're already managing workspace access through groups, you can extend that same group-based approach to row-level data security using UDFs. Setting Up Group Permissions To manage group-based workspace permissions via API, the typical flow is: 1. Create a user group via

POST /api/v1/entities/userGroups

2. Assign the group to a workspace via `POST /api/v1/actions/workspaces/`workspaceId`/managePermissions/` 3. Add users to the group via `POST /api/v1/actions/userManagement/userGroups/`userGroupId`/addMembers` [Create a User Group] So your existing group-based permission model will carry over seamlessly to API access, and you can layer UDFs on top of those groups for data-level restrictions. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

@kapa.ai unfortunately, we rely today on groups to manage what dashboards you're allowed to see. We do leverage some UDF to restrict within a group but our primary interface todate for exposing data has been at the dashboard level which lets us manage this through group access. Do you have any plans coming up to associate filters and insights to groups?

Based on the knowledge sources available, there are no confirmed plans to introduce object-level permissions (like group-based access control) for individual insights/metrics or to associate filters directly with insights at the group level. What the knowledge sources do confirm is: • Insights and metrics do not have their own permission settings like dashboards do — access is controlled at the workspace level via roles, not per insight or metric. [Slack thread] • Dashboard sharing permissions are not designed as a security feature. GoodData support has explicitly stated this, and there was even a recent bug where dashboards not shared with a group were still visible to those users. The recommended fix was to rely on WDFs and UDFs rather than dashboard-level sharing for data security. [Slack thread] Regarding conditional visibility of insights on dashboards (e.g., hiding/showing insights based on logic or user group), a community member raised a similar request and was told: > "I am afraid this is not on a roadmap yet." [Slack thread] Given your use case, the knowledge sources suggest that UDFs assigned to user groups are the recommended path forward for data-level security, rather than relying on dashboard sharing. If this is a critical gap for your organization, it would be worth raising directly with your GoodData Account Manager to ensure it's captured as product feedback. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

@kapa.ai I'm not sure I understand the point of groups and permissions if they are not meant for security. What are they for then?

That's a fair and understandable point of confusion. Let me clarify the distinction: Groups and Permissions Are for Security — With an Important Nuance Groups and workspace permissions absolutely serve a security purpose. They control: • Who can access which workspaces (VIEW, ANALYZE, EXPORT, MANAGE, etc.) • What actions users can perform — e.g., whether they can only view dashboards, or also create, edit, export, or manage the logical data model [Workspace Permissions] • Which dashboards are visible to a user, via dashboard sharing combined with workspace permissions [Dashboard Permissions] The key nuance is that dashboard sharing permissions are not a data security feature. Specifically: > "Users cannot access the dashboard layout, but they can still access the data the dashboard is using via API." [Dashboard Permissions] So if a user knows how to call the GoodData API directly (e.g., using a tabular export endpoint), they could potentially access underlying data even if a dashboard isn't shared with them. That's the gap that WDFs and UDFs are designed to fill. In Summary | Layer | Purpose | | - | - | | Groups + Workspace Permissions | Control access to workspaces and what actions users can take | | Dashboard Sharing | Control UI visibility of dashboards (not a data security boundary) | | UDFs / WDFs | Enforce row-level data security regardless of how data is accessed | So groups and permissions are very much a security mechanism — they just operate at the workspace and action level, not at the data row level. For robust data security, GoodData's guidance is to combine both: use groups/permissions to control access and actions, and UDFs/WDFs to restrict what data is returned. [Manage Permissions] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

@kapa.ai we have some pretty fine-grained access controls in our system are there limits to data filters on users? Can we do attribute based filters? OR does it require explicit MAQL

New message text here