Multi-Team Environments use cases

The following examples demonstrate how access rights for process, object, and resource groups can be used in different scenarios.

Dedicated process access

Restrict access to processes so they are only available to specific users

There are three process teams: Developers APAC, Developers EMEA, and Developers US, each with identical Security role permission sets. Each team is responsible for the processes for their graphical location. There is also a Developers GLOBAL team which has responsibilities in each location.

In Studio, there is a group for each geographical location containing all the processes required by the developers in that location. Currently each group has unrestricted access rights, as denoted by the icon overlay. This means that access is determined by Security role permissions and access rights have not been set at process group level.

Users only require access to the processes in the group related to their location. By updating the access rights for each group, permissions can be applied so users cannot access the processes for another location. Set the group to restricted and remove all permissions for the user roles that do not require access. The example below shows the access rights for the APAC process group with the permissions for the Developers US role removed.

When this is repeated for each group, only members of the Developers GLOBAL team can still see all groups, however the icon overlays are no longer displayed as the groups are restricted. When a user in one of the geographic specific roles logs in, they only see the group for their location.

Run a process that references a restricted object

A user attempts to run a process that references an object for which they have no permissions.

The Developers APAC role has no access rights on the folder containing the Order System object which automates an end-user application.

A process in the APAC group references the Order System object. When a user with the Developers APAC role opens the process, a message box displays informing them that the process contains references to items that are not available. This does not prevent them from opening and running the process, but when it attempts to launch the prohibited application, the process fails.

Single business object shared by multiple teams

Allow users to in different geographical locations to execute the same business object

The Developers APAC, Developers EMEA, and Developers US teams all need to use the same business object in the processes they maintain. The Developers GLOBAL team requires access to update and maintain the object. All the geographical developer roles must have at least Execute Business Object and Execute Process permissions enabled for their roles. The Developers GLOBAL role requires full permissions for Process Studio and Object Studio.

Set the access rights on the folder containing the object to give Execute Business Object permissions for the three geographical teams and full access to the Developers GLOBAL team.

When the Developers APAC, Developers EMEA, and Developers US teams run their processes, the shared business object referenced by each team runs successfully. However, they cannot view or edit the object – only users assigned to the Developers GLOBAL role have the permissions to configure it.

Multiple user roles

Where there are permission conflicts due to a user being assigned multiple user roles, the most generous permission wins

A user is in two teams:

  • Team 1, which has View Process Definition permission on Process A
  • Team 2, which has Edit permission on Process A

The user has full access to open and edit Process A as this is the most generous level. Colleagues who are only in Team 1 can open and view Process A but cannot edit it.

Multiple groups

Where there are permission conflicts due to a process being in multiple groups, the least restrictive permission wins

The Order System object is in the restricted Default group and it is subsequently added to the unrestricted Global objects group. The Order System object inherits the permissions of the unrestricted Global objects as the permissions are the least restrictive.

Although the Default group is restricted, the object displays the unrestricted icon overlay as the permissions are inherited from the unrestricted Global objects group.