Customers can register users to their account as needed. They can add and modify users individually or use bulk and mass operations to do so. The users can access the customer's applications and participate in processes according to their permissions.
Each user has a unique account. However, the same person can have more than one DigitalSuite user account within the same customer account or different ones. In this case, the user and customer account to work with need to be specified when the user logs in.
A user account and its configuration comprises the following settings and considerations, which are described in detail in the sections below:
The following settings identify a user in DigitalSuite:
- Name: The user's name, specified in a format chosen by the customer, for example, first name followed by last name. The name does not need to be unique within a customer account.
- Email: The user's email address. It is used to log in to DigitalSuite. It must be unique within a customer account.
- Alias email: An alias email address the user can use to log in. It must be unique within a customer account.
- Account ID: A generated number used to uniquely identify the user account.
DigitalSuite sends notifications for different purposes to the users' email addresses. If sending to an email address results in too many bounces, the address is added to a blacklist for a period of time that depends on the reason. Administrators can remove an email address manually from the blacklist before it is removed automatically.
Each user can set a password for DigitalSuite and change it as needed. Administrators can reset a password for other users, if required. The password is applicable for the Login/Password authentication method, which is always available.
For the SSO with SAML 2.0 and Google OAuth2 authentication methods, users need to set and change their password in the SAML identity provider system or Google, respectively.
The profile determines the basic permissions a user has in DigitalSuite. It can be one of the following:
- Administrator: Users with this profile have full access to all items of their customer account.
- User: Users with this profile can only access specific items, for example, a subset of their settings and project resources to which they have been granted access.
Users can select their preferred language from the languages supported by DigitalSuite for the following environments:
- DigitalSuite Studio
- Applications implemented on DigitalSuite. As a prerequisite for the selected language to be displayed to the user, the applications must provide for the corresponding localization.
User Preferences and Metadata
User preferences and metadata are means to add custom information as attributes to each user belonging to a customer account, for example, postal addresses, phone numbers, identifiers, accounts, passwords, or data required for applications.
Users can enter values for these attributes depending on their profile:
- User preferences: Each user can enter values for these attributes.
- User metadata: Only users with an Administrator profile can enter values for these attributes.
Administrators can set different restrictions for a user. They can prohibit the user from:
- Accessing DigitalSuite Studio.
- Viewing other users' data.
- Viewing user metadata.
The restrictions related to user data and metadata apply to the interfaces of DigitalSuite as well as to applications developed on it. This means that the user will not be able, for example, to view user data and metadata in DigitalSuite Studio or to retrieve such data in a web interface of an application.
For access control at application level, each user can be assigned one or more roles for each execution mode of DigitalSuite.
For details, refer to Security and Access Control.
Users can delegate the tasks assigned to them in applications to representatives, for example, because they plan to be out of office. In addition, administrators can actively take over the tasks of other users and become their representatives, for example, in the case of unexpected leave or employee offboarding.
Delegations can be limited to specific applications or global for all applications except for those for which specific delegations exist. They apply to all manual and email/notification tasks in the applications which are not configured as "not delegable". The representatives receive all the relevant notifications and are assigned the required permissions for the tasks, even if otherwise they do not have access to the applications. However, they are not able to launch new process requests on behalf of the delegator.
A delegation is set for a specific time period. Exactly one delegation can be active at a certain time. Tasks created before the activation of a delegation become accessible to the representative as soon as the delegation is activated. A delegation ends when the specified end date and time is reached, or when it is terminated explicitly by the delegator. The representative can no longer access the delegator's tasks.
DigitalSuite keeps a history of each user's delegations as a reliable record of whether and when the user's tasks were available to someone else. Delegations which are deleted before they become active are not included in the history.
Support Team Access
Users can grant members of a support team access to their data for a certain period of time. The support engineer can access the same data and is granted the same permissions as the user.
The support engineer must be one of the following to be granted access:
- An administrator of the user's customer account
- An authorized member of the RunMyProcess support team
- An authorized RunMyProcess partner who manages the user's customer account
DigitalSuite keeps a history of each user's support team access authorizations as a reliable record of whether and when someone might have logged in and acted on the user's behalf.
DigitalSuite can be integrated with third-party services, for example, at Google by means of the OAuth 2.0 data sharing protocol. Users can be authorized to access such services from their DigitalSuite account as well as grant such services access to their data on DigitalSuite.
A user account can have one of the following status:
- Active: The user account has been configured and the user can access DigitalSuite.
- Inactive: The user has been deactivated by an administrator and can no longer access DigitalSuite.
- Pending: The user account has been configured. The authentication method set for the customer account is Login/Password. Either the user has not yet logged in to DigitalSuite, or the user's password has been reset. Once the user has logged in and changed the password the status changes to Active.
- Blocked: The user account has been locked because the permitted number of login attempts has been exceeded.
When a user account is created, the status can be set to Active or Pending, depending on the authentication method configured for the customer account for Live execution mode. With the Login/Password method, the creating administrator typically will set the status to Pending. When users are created manually or automatically with the SSO with SAML 2.0 or Google OAuth2 authentication method, the status is set to Active. In this case, DigitalSuite does not generate a password for the user. This is not required, because the password is maintained at the SAML identity provider or Google, respectively.
A valid license is required for every user to work with DigitalSuite. If there is no valid license, the user cannot perform any activity on the platform.
Tasks are activities that users need to complete in the applications developed on DigitalSuite, such as filling in a form, providing specific documents, or approving certain steps in a process. The applications can notify the users about their tasks by email or by push notifications to mobile devices through RunMyApp.
At all user interfaces of DigitalSuite, users are provided with immediate access to their tasks and all relevant information related to them. This includes:
- Task name
- Task status: pending, completed, cancelled, or overdue
- Date and time when the task was created and last updated
- User or role assigned to the task
- Execution mode in which the task is to be completed