About Process Application Roles

Process application roles determine what data a user or group can access, and what actions they can perform in Process Automation instances, interfaces, and user tasks.

A process application role consists of users/groups and permissions. Learn more about how users, groups and permissions are defined in roles. See Users, Groups, External Applications and Permissions.

Types of Process Application Roles

There are two types of process application roles: Application roles and Global roles.
  • Application roles are specific to a particular process application and can be used only for that process application. They can't be shared with other process applications.
  • Global roles are defined once and then can be linked and used wherever they're needed in process applications.
Some key points about Global roles:
  • A global role’s users/groups are global, but their permissions are application-specific, meaning that their permissions can vary in each process application in which the role is used. For example, a HR Recruiter global role contains all HR recruiters, and these users may have Use permission in one process application but only Read permission in another process application.
  • Keep in mind that if you change a global role’s users/groups, this change affects all process applications that link to that role.
  • Process Automation Administrators can see all users/groups assigned to a global role in Workspace.
  • A global role must be present in an activated application or created in Workspace before it is available to be linked to process applications in Designer.

Recommended best practice: Using global roles can result in fewer roles. If your organization has many process applications running in the same domain, using global roles linked to process applications may make sense. On the other hand, if your organization has very different types/domains of process applications, it may be best to keep roles specific to their process applications.

See Create an Application or Global Role.

Default Process Application Roles

  • Process Application Administrator: This global role gets created by default with a Process Automation instance. The Process Application Administrator role has full permissions (that is, the Manage permission) on all applications, versions, and resources. To know more about permissions, see Users, Groups, External Applications and Permissions.

    As a Process Automation Administrator (assigned the ServiceAdministrator IDCS application role), you can assign users or groups to the Process Application Administrator role in Workspace. See Assign the Process Application Administrator Role.

    Note:

    Process Application Administrator is a system generated role and can't be deleted.
  • ProcessUser: This application role gets automatically created when you create a structured process, and gets displayed in the swimlane. You can either use it for task assignments or delete it.

The following table lists how and where Process Automation Designers and Process Automation Administrators work on process application roles.

Who What can they do and where?

Process Automation Designers

In Designer, Process Automation Designers add roles, and then assign these to user interactions such as human tasks in structured and dynamic processes. Process Automation Designers also need to allow specified users to start process requests in Workspace.

Process Automation Designers

In Designer, Process Automation Designers activate process applications, and the role assignments are made available in Workspace.

Process Automation Administrators

In Workspace, Process Automation Administrators can view all application and global roles, including their assigned users/groups and the process applications in which they’re used. Process Automation Administrators can edit and delete application or global roles, and also add global roles. In addition, they can also update role permissions.