Skip to main content

Execution Groups

Execution Groups

This section explains how to organize independent work of two departments within one Control Server using the Execution groups function in the Automation Process Details and Groups Permissions.

Create Groups and add Users

Log in as a member of the "Administrators" group and create the required number of groups corresponding to the number of independent departments. 

Add roles to Groups

Add the following roles to every created group:

  • Group.ALL.READ
  • Administration.ALL.READ
  • HumanTaskType.ALL.CREATE
  • User.ALL.CREATE
  • Node.ALL.CREATE (in case you are going to set up a new Node) OR Node.EXISTING_NODE.ALL (in case you are going to use already existing Node)
  • Channel.ALL.CREATE
  • DocumentType.ALL.CREATE
  • Template.ALL.CREATE
  • SecretVault.ALL.CREATE
  • MlModel.ALL.CREATE
  • AutomationProcess.ALL.CREATE
  • Schedule.ALL.CREATE
  • DataStore.ALL.CREATE
  • DocumentSet.ALL.CREATE

To restrict access to modules for users in a group, the corresponding role can be removed. Please, refer to the section Role Permissions for more details.

Add required Third-Party roles

Configure third-party roles required for work of the Department. Please, refer to the section View/Edit Third Party Roles in a Group for more details.

(предупреждение) Note that it will not be possible to load an Automation Process containing a storage component without the proper MinIO console third-party role.

Add Users to Groups

Add users to the appropriate groups. Please, refer to the section User Management for more details.

Create entities as a member of the group

Group members will not have access to entities created by members of other groups. 

When Schedule, Data Store, Secret Vault, Node, Document Set, Model, Human Task Type, Document Type, Channel or Template are added by a user of a group, the newly created entity appears in the group with the following permissions: READ, UPDATE, DELETE, ACTION.

In the example below new Data Store was created by user easy_rpa_1(member of Department_1 group):

Data Store created by a member of the Department_1 group will not be available for a member of the Department_2 group.

If you create or load an Automation Process in a corresponding group, the role with the following permissions will appear on the created Automation Process as well: READ, UPDATE, DELETE, ACTION. The group will also automatically include Run User related to the Automation Process. 

(предупреждение)To avoid repetitions in names with other departments/groups, please add a prefix indicating your department/group to the name of entities created.

The Execution groups field in the details of an Automation Process indicates which groups have access to it. 

Therefore, only group members have access to runs of Automation Process, the Automation Process runs only on the Nodes that group members have access to, and Automation Process itself has access to entities assigned to the group and vice versa.

Let's take a look at the example below:

  1. User easy_rpa_1 (member of the group Department_1) uploaded Automation Process "Department_1 Automation Process". The Automation Process package contains the following entities: Automation Process "Department_1 Sample Process", Data Store "Department_1 Datastore", Document Type "Department_1 Document", Human Task Type "Department_1 Human Task Type" and Notification Template "Department_1 Template".

    Execution group "Department_1" was automatically added to the uploaded Automation Process.

    The new System Department_1 Sample Process Run User was added to the group Department_1.

    The corresponding context roles appeared in the group Department_1.
  2. User easy_rpa_1 launched the Automation Process. Since the permission for NODE 1 is added to the group Department_1, run was executed on the NODE 1



Execution rights can be manipulated by removing/adding groups in Automation Process details, or by removing/adding Automation Process Run Users.