In version 7.11, the following permission domains have beed added:

• AI Prompts: allow users to edit the AI prompts to generate and refine process element descriptions. (This feature is only available on managed service.)
• API Tokens: allow users to generate API tokens for external services to authenticate against the new SCIM API (see https://scim.cloud)

In version 7.10, the following permission domains have been added:

• Process Cleanup: allow users to create rules for automatic archiving and deletion of old process versions for better performance and overview
• Superuser Mode: allow users to temporarily assume superuser privileges using their own profile

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 have been 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 groups
• Process Execution: start project processes and execute them in tools like Jira
• Process Execution Configuration: control edit access to process execution elements and configuration
• Process Participant Assignments: assign users to participants
• Process 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 pages
• Role-to-User Group Assignments: assign roles to user groups
• User-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.

This approach is best used for access permissions to workspaces that exist only once, e.g. the standard processes and the reference models.

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.

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).

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.