Manage Users, Groups, and Permissions
In version 7.9, the following permission domain has been added:
Process Interface Release
: allow users to release process interfaces
In version 7.8, no new permission domains were added and no license features were modified.
In version 7.7, the following permission domain has been added:
PDF Export
: allow users to create and download PDF exports
In version 7.6, the following permission domains have been added:
Participant-to-User Group Assignments
: assign participants to user groupsProcess Execution
: start project processes and execute them in tools like JiraProcess Execution Configuration
: control edit access to process execution elements and configurationProcess Participant Assignments
: assign users to participantsProcess Release Administration
: control edit access to process release workflows.
In version 7.5, the following permission domains have been added:
Landing Page
: control edit access to the landing pagesRole-to-User Group Assignments
: assign roles to user groupsUser-to-Role Assignments
: assign users to roles
Detailed guidance for the various user actions and which permissions they require can be found in this Permissions Matrix.
The dependencies between permissions and licenses needed can be found in the Stages Permission-License Matrix.
Manage User Access through Groups
This approach is best used for access permissions to workspaces that exist only once, e.g. the standard processes and the reference models.
Manage User Access through Participants
Participants are users that participate in the lifecycle of a process, e.g. modeling, review, approval, or tailoring. This approach is best used for access permissions to workspaces that exist multiple times for specific purposes, e.g. modeling workspaces, playgrounds, or project- or program-specific processes. Example participants: process owner, process modeler, process reviewer, process approver, tailoring approver.
Manage User Access through Roles
This approach is best used for access permissions to workspaces that exist many times, e.g. project- or program-specific processes, but the users do not participate in the management of the process. Example roles: engineer, tester, quality manager. Project managers are typically responsible for their project's specific process and therefore can be added as process owner participants (see above).
Default Group
Permissions you assign to this group are automatically assigned to all users in the system. The purpose of this group is to provide basic permissions that all users need. This group is a system feature and cannot be removed or renamed.