Assigning granular user permissions
While EMS admins have a defined set of permissions, you must assign permissions to your analysts, members, and groups of users within your EMS.
You can assign granular permissions based on service, container, and object levels within your EMS. These levels work on a hierarchy, with the highest level (the service level) overriding any conflicts in either the container or object level.
![]() |
Service level
This is the highest level, giving user permissions across a service within your EMS, such as the Studio. In this example, you are granting the user permissions to the whole Studio.
To set service level permissions, click Admin & Settings - Permissions and then edit the relevant service.
![]() |
Container level
This is the top-level object within a service, such as Studio - Space. In this example, you are granting the user permissions within just the space.
To set container level permissions, once inside the service click Options - Permissions:
![]() |
Object level
This is the specific object within a container, such as Studio - Space - Package. In this example, you are granting the user permissions within just the package.
To set object level permissions, once inside the space click Options - Permissions:
![]() |
Permissions overview
To help you identify the permissions you need to set, use this table.
Service | Container | Object |
---|---|---|
Data Integration | Data Pool | Data Model |
Studio | Package | View / Analysis / Action Flow / Data Explorer / Skill |
Action Engine | Project | Skill* (N/A) |
Machine Learning | Workspace | App |
Process Analytics | Workspace | Analysis |
Process Automation | Agents* (N/A) | |
Process Repository | Category | |
Transformation Center | Objective | KPI* (N/A) |
*Permissions can’t be assigned to these objects.
For example, the Studio service needs service level permissions, a studio package needs container level permissions, and a views, analysis, action flows, data explorers, and skills needs object level permissions.
![]() |