Please give details of the problem



Roles and Access Rights

For access control at project level, DigitalSuite uses roles that provide users with the access rights required to fulfill their tasks. Learn more about:


A role represents a set of a user's responsibilities and the access rights required to take the corresponding actions. Users are assigned one or more roles within a project in order to give them the access rights necessary to meet their responsibilities. The access rights defined for a role are granted to all users who are members of the role.

DigitalSuite allows customers to define any number of roles and assign them to users as required. Roles are grouped into organizations, and organizations can contain many roles.

The role-based access defined at project level applies to all resources that belong to the project. For subprojects, the access rights may differ from those defined for the main project.

Access Rights

DigitalSuite distinguishes between the following types of access rights:

  • Designer: Designer access allows a user to modify a project's resources and launch processes and web interfaces in the Test execution mode.
  • Supervisor: Supervisor access allows a user to monitor launched processes in all execution modes and view web interfaces and manual tasks in Test mode. Supervisors cannot modify any project resources.
  • User: User access allows users to launch web interfaces in Live mode and see the tasks they need to perform. Users cannot see the complete execution paths of the processes they have launched.
  • Observer: Observer access allows users to view web interfaces and manual tasks in Live mode.
  • Translator: Translator access allows a user to create, read, update, and delete dictionaries for use with the App Translator standard portal application.

Organizations and Role Hierarchies

Organizations are a means to group roles. How a customer makes use of organizations is a design decision and depends on the projects. For example, organizations may reflect the structure of a company, or each project may have its own organization. A role can only belong to a single organization, but a project can use roles from different organizations.

Role hierarchies are another way to organize roles, for example, to represent the structure of a company. A parent role may have multiple child roles. The number of child generations for a parent role is limited to three.

Role Membership

The assignment of users to roles can be done in different ways, spanning both static and dynamic allocation. The same role can have different members for the Live and Acceptance execution modes. For the Test mode, the members are identical to the Live mode.

Static Allocation

Static allocation means assigning users to roles independent of projects and application execution.

  • Everybody Roles: Roles which include every active user that belongs to the account. All users within a company have the right to perform the functions related to these roles.
  • Static Roles: Roles to which users are manually assigned in order to give them the rights necessary to perform the related functions.
  • Scripted Roles: Roles to which users are assigned by DigitalSuite based on the execution results of a script. The script can filter the users based on static values such as settings, metadata, preferences, or role membership.

Dynamic Allocation

Dynamic allocation means assigning users to roles at runtime of an application, depending on current data.

  • Dynamic Roles: Roles to which other, static roles with their users are assigned at runtime.
  • Runtime Roles: Roles to which users are added at runtime.

Roles with dynamic allocation are empty when they are created.

Roles in Projects

Roles are defined independent of projects and then assigned to projects as required. A project can use roles from different organizations, and a role can be used in different projects.

The role assignments are made at the processes and composite APIs of projects. In the design of the process or composite API, each role is represented by its own lane. Lanes representing roles of the same organization are grouped in the same pool.


The illustration shows a process with one pool, indicated by 1, and three lanes, indicated by 2.

The roles with their defined access rights apply to all activities and referenced resources in the corresponding lanes.

An exception to this rule are resources of subprojects which are included in the current project. This means that resources that require their own access rights, for example, individual web interfaces, can be defined in their own projects, which can then be included as subprojects into others.