Multi-team environments

Click this icon on the toolbar to view and download the full PDF version of this guide.

Multi-team Environments provide a way for multiple lines of business, operating within a single deployment of Blue Prism, to share artifacts. This is achieved by extending role-based access controls to enable more granular configurations.

These capabilities better enable organizations to share Blue Prism assets, such as business objects and runtime resources, with multiple teams within a given Blue Prism environment by allowing permissions to be assigned, not only based on the type of asset, but also based on the hierarchical structure of those assets.

For example, users who are members of a team may have full access to some business objects but may only have the ability to view or execute others, as may be appropriate for assets that are shared by multiple teams.

The list below shows where multi-team environments are effective in the Blue Prism interactive client:

• Home – The data displayed on the Home page is not filtered by the access rights applied to groups.
• Studio – This is where users with the appropriate permissions manage access rights for process groups and object groups.

• Control – Users are given a custom view of the Control Room so they only see and interact with the processes and resources appropriate to their role. This does not include the Queue Management area – users with access to this area can view information related to any conventional queue within the environment.

  For active queues, users only see a queue if they have execute permission on the process that works the queue and control permission on all target resources for that queue.

• Analytics – The data displayed in dashboard tiles is not filtered by the access rights applied to groups.
• Releases – Only items to which a user's permissions allow access, can be included in a release or package.
• System – The following areas of System Manager have been updated for multi-team environments:
  • Resources – This is where users with the appropriate permissions manage access rights for runtime resource groups.
  • Audit (Session Logs) – Process logs and object logs are subject to the logged in user's permissions – they can only see the logs for the items that their role allows. Audit logs are not filtered by the access rights applied to groups.

The Find References and View and Compare operations are also updated so they only return objects that the user has access to.

Access based on hierarchical group membership

If group level permissions are not defined, users granted permissions for a particular item type, such as processes, have the same permissions for every item of that type in the system.

By restricting permissions to a group of processes, objects, or resources, the permissions defined by user roles can be configured to give the required access rights to the items in the group.

This example shows the permissions applied to the APAC process group for users assigned the Developers US role. The access rights for this group have been restricted to only allow users with the Developers US role to execute processes.

Permissions applied at group level cannot grant users access rights beyond the maximum permitted by their role. For example, if a role allows a user to edit processes, that permission can be removed for a group. If the role does not allow a user to delete processes, that permission cannot be granted for that role at group level.