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. Customers can define any number of roles, group them in organizations and hierarchies, and assign them to projects and users as required.

The following image provides an overview of the access control at project level, which is described in detail below.

Roles

A role represents a set of responsibilities within a customer organization, for example, employee, manager, QA, or HR. Each user can be a member of any number of roles as required by the organization.

Roles are assigned to projects in order to give its users the access rights necessary to meet their responsibilities. A role can have the same or different access rights in different projects. Within each project, the given access rights are granted to all active users who are members of the role.

Customers can define any number of roles and assign them to projects and users as required. Roles are grouped in organizations and can be structured in hierarchies. A role can only belong to a single organization but a project can use roles from different organizations.

Access Rights

DigitalSuite distinguishes between the following types of access rights which can be assigned to a role in a project:

• Designer: Designer access rights allow a user to modify a project's resources and launch processes and web interfaces in the Test execution mode.
• Supervisor: Supervisor access rights allow a user to monitor launched processes in all execution modes and view web interface instances and manual tasks in Test mode. Supervisors cannot modify any project resources.
• User: User access rights allow 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 process requests they have launched.
• Observer: Observer access rights allow users to view web interface instances and manual tasks in Live mode.
• Translator: Translator access rights allow 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 rights 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. Each role belongs to exactly one organization, but an organization may include any number of roles. A project can be assigned roles from different organizations.

  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 a separate organization with its own set of roles.

  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 levels of responsibility within a company. A parent role may have multiple child roles, but each child can have only one parent. The number of child generations for a parent role is limited to three.

  The access rights assigned to a parent role in a project also apply to the children, but not vice versa.

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 customer 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 permissions necessary to perform their tasks.

• Scripted Roles: Roles to which users are assigned by DigitalSuite based on the execution results of a given script. The script applies to all execution modes. It 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 scripted roles are processed in batch and more than one role could be affected by a change, the re-computation may take a few minutes to complete. The same role is not re-computed more than once every 5 minutes.

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

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

When a role is assigned to a project, the access rights for its members in this project are specified. Each project requires at least one role with Designer rights. Roles with other rights can be added as needed.

The role-based access rights defined at project level apply to all resources that belong to the project. For subprojects, the access rights may differ from those defined for the main project. Resources that require their own access right - for example, individual web interfaces - can thus be defined in their own projects, which can then be included as subprojects into others.

Users can perform activities on the resources of a project according to the access rights assigned to their roles in this project. An exception to this rule are public resources, which can be accessed by anybody without requiring any role assignment and authentication. Details on the actions possible in each case are provided here.

Roles in Processes - Pools and Lanes

The processes and composite APIs of DigitalSuite use roles to specify the users who are intended and allowed to execute the individual steps. In the design of a 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 , and three lanes, indicated by .

The lanes provide a clear overview of which process steps are associated with each role. In order to execute a manual activity, a user has to be a member of the role the activity is assigned to by the corresponding lane. An exception to this rule are manual tasks which are defined as public and thus executable by anybody without authentication or access control.

A process and composite API requires at least one lane which includes the start event. In order to trigger the process or composite API, a user needs to be a member of the corresponding role with the appropriate access rights defined at project level. This also applies to the senders of emails used as triggers and to developers who wants to start their processes or composite APIs in Test mode.

Processes often have several lanes. On the other hand, composite APIs are usually executed within a single lane, because they do not involve manual tasks to be carried out by users with different roles.