In Metric Insights, the Security Model comprises a set of features that define the capabilities and content access available to different Users. Access to system components is controlled through the application of Permissions and Privileges.
Please refer to this article for recommended best practices on securing your MI instance.
1. Assign Privileges and Permissions to Groups
There are two key concepts when it comes to Metric Insights security:
- Privileges, or functional access, define what a User can do in the system. For example, Privileges define the right to create Elements or Objects, manage other Users, or add comments to Elements.
- Permissions, or content access, define what content a User can view or edit. These are applied to specific Objects, Categories, or Folders, allowing for granular control over content.
When it comes to Administrators, they can view and operate everything in the Metric Insights instance. However, when there's a need to allow Power Users or Regular Users to access something, they must receive a corresponding Privilege and Permission.
1.1. Privileges
Privileges assigned to a Group are inherited by all Group members. We recommend granting access to Groups rather than individual Users to ensure more efficient control over the security model.
Additionally, rather than assigning every Privilege individually, assign Privilege Sets to Groups. A Privilege Set is a combination of Privileges that corresponds to a specific User Type. Using Privilege Sets ensures greater consistency across your security measures..
1.2. Permissions
In Metric Insights, every individual User can be granted Permission to view or edit any given Element. Once again, we recommend assigning Permissions to Groups rather than to individual Users.
Permissions regulate content access, so it's best practice to apply them at the Category level rather than to individual Elements or Objects within that Category. This approach simplifies access management and improves overall efficiency.
Permissions can be granted either from the Category Editor or from the Group Editor.
2. Manage Access Requests
By default, only the tiles for Elements that a User has permission to view or edit are displayed on the Catalog page. However, Administrators can make specific Elements discoverable to Users who don't yet have access, in which case those Users will be able to request access directly.
Metric Insights supports three Access Request Processing options. You'll need to determine which one best suits your organization's requirements:
- Within Metric Insights. The Access Request is processed entirely within Metric Insights. In this case, Access Request Security is applied to it.
- Via external tool. The Access Request is processed by the external tool that your organization uses for access management (e.g., SAP's GRC) via API request.
- From webpage. The Access Request is sent to a webpage.
For more details on Access Request management, refer to the Access Request Overview article.
Apply User Maps for Content Security
A User Map is a Dataset that defines what access each User in a list has. Depending on the Element to which it's applied, it either restricts Users from seeing certain Filter Values or applies a default Value to a specific User.
There are two types of security based on the User Map, and you'll need to decide which is best suited to your needs:
- Dimension-Level Security: By applying a User Map to a Dimension, you can control which specific Dimension Values each User or Group is allowed to see. Once configured, the User Map automatically enforces these restrictions across all related Elements—Metrics, Reports, and External Reports—so each User only sees their permitted Dimension Values. For more information, refer to this article.
- Row-Level Security: Implemented via User Maps, this approach restricts data at the row level in the underlying Dataset, granting Users/Groups access only to the rows that match their assigned values. For setup details, refer to this article.