Update changes in Automation Co-Pilot for Business Users from Automation 360 v.21 or later versions

From version Automation 360 v.21 or later, there is a change in how the teams work in Automation Co-Pilot for Business Users on the web interface. Advanced team management now helps business managers define how a request can be created. They can also specify who can view or delete requests.

To ensure that there is no discontinuity in the existing behavior for users who had any access to a process or created requests from a process (regardless of existing team assignment), the following conditions should be maintained:

  • The user access to create a request for a specific process is retained.
  • The user access to view the requests from a process regardless of the team they were part of is also retained.

How existing teams are changed

To maintain the current access to processes and the current teams, the existing teams remain with the following:

  • Existing process assigned to them.
  • Same members assigned to the team.
  • The team type is configured to shared. This ensures that all the members of the team can view the migrated processes and requests.
  • Members of the team have one of the following team roles:
    • Co-Pilot Manager or Co-Pilot Admin has the admin role
    • Co-Pilot User has the member role

To maintain the current access to requests, new teams are created for each process and the new team has the following:

  • Existing processes assigned to the team are named "Teams Migrated for Process X" where X is the process ID. This helps reference the migrated processes. Teams are created for existing processes with this name.
  • Users who had access to the process previously are assigned to this team regardless of their existing team assignment, and the team is assigned to the process.
  • The team type is configured to shared.
  • Members of the team have one of the following team roles:
    • Co-Pilot Admin
    • Co-Pilot Manager
    • Co-Pilot User

Previously, the Co-Pilot Manager could create requests without assigning the processes to teams. After the update, they must create teams and ask the Co-Pilot Admin to assign their team to a process in order to create new requests.

Important: After the migration process and the creation of the migrated team, in the request creation, there will be two processes (one for each team) for you to select. The two processes will have different behaviors for the request visibility.

Example

The following scenario helps illustrate how the update works.

Consider a process named Loan Closing with process ID 47. Georges has an Co-Pilot Admin role in the Control Room.

Before Update

Two teams HR and IT have access to the Loan Closing process and the team structure is as mentioned in the table below.

HR IT
User Name Control Room Role User Name Control Room Role
Bob Co-Pilot Manager Grace Co-Pilot Manager
Carol Co-Pilot User Steve Co-Pilot User
Debby Co-Pilot User Debby Co-Pilot User
The behavior before the update is as given below:
  • Users from the HR team can see requests created in the IT team and vice versa.
  • Bob and Grace can assign the processes that have been previously assigned to them by Georges to the HR and IT team respectively.
  • Bob can manage the HR team and similarly, Grace can manage the IT team such as add members, assign processes, rename the team, so on.

After update

The two initial teams (HR and IT) still remain and additionally one new team (named Team Migrated for Process 47) is created during the update. The team structure of all the three teams are mentioned in the table below:
HR IT Team Migrated for Process 47
User Name Team Role Control Room Role User Name Team Role Control Room Role User Name Team Role Control Room Role
Bob Admin Co-Pilot Manager Grace Admin Co-Pilot Manager Bob Admin Automation Co-Pilot manager
Carol Member Co-Pilot User Steve Member Co-Pilot User Carol Member Automation Co-Pilot user
Debby Member Co-Pilot User Debby Member Co-Pilot User Debby Member Automation Co-Pilot user
Co-Pilot User Grace Admin Automation Co-Pilot manager
Steve Member Automation Co-Pilot user
The behavior of the teams after the update is as given below:
  • Members from the HR team cannot see the requests created in the IT team and vice versa anymore.
  • As Debby is a part of both HR and IT team, this user can create requests in both the teams. Two different process cards are displayed to the user during request creation.
  • Old requests created inside the HR and IT teams are treated like they were created inside the common team named Team Migrated for Process 47 which has only the Loan Closing process (47) assigned to it.
  • Members from both HR and IT teams are all part of Team Migrated for Process 47 and so they can access the old requests. Deleting the team Team Migrated for Process 47 deletes the requests associated with it, so old requests access is removed and cannot be restored.
  • Members from HR or IT team can create requests inside the team Migrated for Process 47 and those requests are visible to all the members of the HR and IT team.
  • Bob and Grace can manage the HR and IT team respectively as well as jointly manage the Team Migrated for Process 47. This means they can add members to the team, rename the team, remove members from the team, so on.
  • Bob and Grace can now only view the processes assigned to their teams by Georges.
Important: During the update, issues with team admin assignment might occur intermittently, whereby either the creator of the team is incorrectly assigned the member role instead of the team admin role or other team members are assigned the team admin role instead of the member role. After the update, the Co-Pilot Admin must always verify the team admin assignment.

The following example explains the team admin assignment issue:

Before update: Bob creates the HR team and has the Co-Pilot Manager role, with Carol, Debby, Grace, and Steve as team members and having Co-Pilot User roles.

After update: Bob is assigned the team admin role along with Carol. Debby, Grace, and Steve are assigned the team member roles. In this case, Carol is incorrectly assigned the admin role instead of the member role. The Co-Pilot Admin must verify the team admin assignment and change Carol's role to team member.