Configure access rights

System Administrators can configure access rights for all processes, objects, and resources in an environment. This ability can be delegated to other users by applying the Manage Access Rights permission to their role for specific groups.

Changes to access rights are applied at login so it is recommended that users are logged out when permissions are updated.

When configuring multi-team environments, it is important to first define the maximum capabilities for each role using the Security role permissions.

Click System > Security > User Roles and select a role to configure its permissions.

Once the maximum capabilities are set for each role, configure access rights for particular process, object, and resource groups to limit access based on the requirements of the user:

• To configure access rights for processes and objects, click Studio, right-click on a process group or object group and select Access Rights.
• To configure access rights for resources, click System > Resources > Management, right-click on a resource group and select Access Rights.

The Manage Access Rights dialog lists all user roles that have Security permissions to access that particular area of the product. Select a user role to configure the permissions for the users assigned that role – listed at the bottom of the dialog.

The built-in roles, System Administrators and runtime resources, are able to access all restricted and unrestricted items secured under multi-team environments. Users with these roles have access to all items regardless of their assigned permissions. As a result, these roles are not available as an option in the Manage Access Rights dialog.

A group can be in one of the following three states:

• Unrestricted – As access rights have not been specifically determined for the group they are determined by the permissions set in the roles assigned to the user. This is the default setting for all new and pre-existing groups. Unrestricted groups are identified by an icon overlay .
• Restricted – Access rights have been configured for the group, refining the user role permissions for all items in the group, including any child groups and their contents. The access rights defined for restricted groups are impacted by subsequent changes to role permissions – remove a permission for a role and it is removed for that role on all groups.
• Inherited – The item is already in a restricted group and its access rights are set by a parent group – when permissions are set for a group, they are automatically applied to all child groups. This could be the direct parent, or any higher-level folder as access rights are taken from the highest level restricted parent group. The name of the group from which the access rights are inherited from is shown alongside the Inherited radio button.

If there is a requirement to prevent users from seeing processes, objects, or resources in a particular group, remove all permissions on all groups for the required role. The items in all such restricted groups will not be visible to users assigned that role anywhere in Blue Prism and will cause processing to fail if they try to run those items or ones that reference them.

For an example of this scenario, see Dedicated process access.

Show all unrestricted groups

If an unrestricted object or process group contains only restricted child groups (i.e. does not directly contain any objects, processes, or any unrestricted groups), users that do not have permissions to view any of the child groups will not see the unrestricted parent folder within the hierarchy. This streamlines the user's view by omitting the groups that they are unlikely to need to access from the navigation tree.

The display can be toggled to show unrestricted parent groups by selecting Show all unrestricted groups from the context menu in Studio. Once selected, unrestricted parent groups are visible but any restricted child groups remain hidden. This option applies to all groups in Studio for the duration of the user's session – if users log out and back in again, the option is reset to the default setting and unrestricted parent groups with restricted child groups are not displayed.

In the example below, the unrestricted Sales group contains three restricted groups that can be viewed only by the users responsible for the processes in their geographical location. When a user who is not part of the Sales team and therefore does not have the required permissions on the restricted groups logs in, the Sales group is not visible. When that user selects Show all unrestricted groups the Sales group displays but does not show the restricted child groups.

Group Structure	Restricted user's view	Unrestricted groups option	Updated view