Upgrade changes in AARI from A360.21 or later versions

From version A360.21 or later, there is a change in how the teams work in AARI 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's access to create a request for a specific process is retained.
The user's 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:
- AARI manager or AARI admin - admin role
- AARI user - 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:
- AARI manager AARI admin
- AARI user

Previously, the AARI managers could create requests without assigning the processes to teams. After the upgrade, they must create teams and ask the AARI 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 upgrade works.

Consider a process named "Loan Closing," with process ID 47. Georges is a user AARI admin role in the Control Room.

Before Upgrade

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	AARI manager	Grace	AARI manager
Carol	AARI user	Steve	AARI user
Debby	AARI user	Debby	AARI user

The behavior before the upgrade 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 Upgrade

The two initial teams (HR and IT) still remain and additionally one new team (named Team Migrated for Process 47) is created during the upgrade. 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	AARI manager	Grace	Admin	AARI manager	Bob	Admin	AARI manager
Carol	Member	AARI user	Steve	Member	AARI user	Carol	Member	AARI user
Debby	Member	AARI user	Debby	Member	AARI user	Debby	Member	AARI user
					AARI user	Grace	Admin	AARI manager
						Steve	Member	AARI user

The behavior of the teams after the upgrade 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 upgrade, 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 upgrade, the AARI administrator must always verify the team admin assignment.

The following example explains the team admin assignment issue:

Before upgrade: Bob creates the HR team and has the AARI manager role, with Carol, Debby, Grace, and Steve as team members and having AARI user roles.

After upgrade: 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 AARI administrator must verify the team admin assignment and change Carol's role to team member.

Automation 360