×

Please give details of the problem

Skip to content

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:

Roles

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.

Details on the actions possible with each type of access right are provided here.

Organizations and Role Hierarchies

In order to reflect the structure of responsibilities, customers can use 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 departments or subsidiaries 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.

    A good practice is to create a dedicated organization with separate roles for each application, and to use the same name for the application and the organization. An additional organization with the name of the company may group cross-application roles, for example, marketing, sales, or legal.

  • Role hierarchies are a way to organize roles in structures, 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. In Test mode, the members are identical to 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 by an administrator 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, which applies to all execution modes. The script can select the users based on the static values of user settings, metadata, preferences, or role memberships.

    The members of a scripted role are re-computed with each change to the script itself, to a role referenced by it, or to a user's settings, metadata, or preferences. Since more than one scripted role could be affected by such changes, the re-computation may take a few minutes to complete.

Dynamic Allocation

Dynamic allocation means assigning users to roles at runtime of an application, depending on current data and process variables specified in the process and web interface design.

  • 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. After their creation, runtime roles cannot be changed to another role type, and other role types cannot be changed to runtime roles.

Roles with dynamic allocation are empty when they are created.

Naming Recommendations

When creating roles, it is good practice to add the type of member allocation as a suffix to the role name, enclosed in parentheses, i.e. (everybody), (script), (dynamic), or (runtime). Static roles do not get a name suffix.

In role hierarchies, parent roles which do not have members of their own, can be denoted by adding the suffix (empty) to their name.

Roles in Projects - Pools and Lanes

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.

Lanes

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

The lanes clearly show which process step is assigned to each role. 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.