> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/xsoar-migration-guide/cortex-xsoar-8-saas-multi-tenant-migration/migrate-from-cortex-xsoar-6-multi-tenant-to-cortex-xsoar-8-saas-multi-tenant-using-the-migration-wiz/step-3.-run-user-acceptance-tests-uat-in-a-multi-tenant-deployment-using-the-migration-wizard/users-user-groups-and-roles-multi-tenant.md). # Users, User Groups, and Roles - Multi-Tenant In Cortex XSOAR 6, management of users and roles is undertaken exclusively in the Cortex XSOAR instance. In Cortex XSOAR 8 SaaS: * Users are created in the Customer Support Portal (CSP) or Single Sign-On (SSO) from the tenant. * Administrators can manage users, roles, user groups, and SSO in the instance and in the Cortex Gateway, When migrating from Cortex XSOAR 6 to Cortex XSOAR 8, you should review and update your access management settings, user roles, and permissions to ensure they align with the new RBAC model and access management features. {% hint style="info" %} ### Note New roles for main and child tenants created in Cortex XSOAR 6 during the User Acceptance Testing (UAT) stage are not migrated to Cortex XSOAR 8. {% endhint %} For more information about managing users and roles in Cortex XSOAR 8, see [Users and Roles Management](/cortex-xsoar-8-saas/configure-cortex-xsoar/users-and-roles-management.md). **User and role differences between Cortex XSOAR 6 and 8**
User and roles | Feature | Cortex XSOAR 6 | Cortex XSOAR 8 | | --------------- | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Users | Can belong to multiple roles | Users can belong to only one role, but can belong to multiple user groups. | | Users | The primary identifier is the username. | The primary identifier is the email address. Usernames are not used in Cortex XSOAR 8. | | Users | Default Admin |

There is no Default Admin in Cortex XSOAR 8. Some permissions granted to Default Admins in Cortex XSOAR 6 are now granted only to users with Instance Administrator or Account Admin roles. This includes access to:

| | User Groups | Not supported |

Administrators can create and manage groups of users and assign them specific roles and permissions in a single operation. User groups can include multiple users and nested groups, which inherit the permissions of parent user groups. Administrators also can map groups from an organization's identity provider (IDP) and see details such as created date, updated date, and assigned roles.

User groups include the Role - Analyst and Read-Only for the relevant users from Cortex XSOAR 6.

In Cortex XSOAR 8:

| | Roles | In server |

Includes out-of-the-box roles, such as Instance Administrator, Account Admin, Analyst, and Read-Only, with specific access rights that cannot be changed. You can view and manage permissions in the instance or in the Cortex Gateway. Regardless of where the roles originated from (main or child tenant), even with the same name, all the roles are migrated from Cortex XSOAR 6 to Cortex XSOAR 8.

Note

If you use the migration wizard to move to Cortex XSOAR 8, your roles from Cortex XSOAR 6 are migrated to Cortex XSOAR 8, and the new Cortex XSOAR 8 out-of-the-box roles of Instance Administrator and Account Admin are also available in your Cortex XSOAR 8 tenant.

| | User Management | In server | In the Cortex XSOAR 8 instance or in the Cortex Gateway, you can view and manage permissions, role-based access control (RBAC), and user group settings. In Cortex XSOAR 6, administrators may have the Users and Roles permission, which includes invitations and editing permissions. In Cortex XSOAR 8, only administrators have user editing permissions. |
User groups In Cortex XSOAR 6, a user can have multiple roles (there are no user groups). For example, a user can be an Analyst and a Content Developer. In Cortex XSOAR 8, a user can have a single role and belong to multiple user groups, where each group has a role. During the migration process, existing Cortex XSOAR 6 users, with multiple roles, are converted to assigned roles within a user group with corresponding roles. For example, in Cortex XSOAR 6, User A has three roles: Employee, Analyst, and Content Developer. When migrating, Cortex XSOAR 8 creates the following: * User groups: Employee, Analyst, and Content Developer * User Roles: Employee, Analyst, and Content Developer User roles are assigned to the user groups, so the Employee role is assigned to the Employee user group, the Analyst role is assigned to the Analyst user group, and the Content Developer role is assigned to the Content Developer user group. User A is assigned to the Employee, Analyst, and Content Developer user groups. {% hint style="info" %} ### Note In Cortex XSOAR 6, roles with **SAML Group Mapping** are migrated to **User Groups**, adding the name of the SAML under **IDP Groups**. {% endhint %} Users from child tenants that have inherited roles from a main tenant are shown in **User Groups** where the **Group Name** includes the suffix *-main*
Nested roles Roles are nested in the same way in Cortex XSOAR 6 and 8, but how nesting works is different. * Role nesting Cortex XSOAR 6 uses basic role nesting, where the role with higher permissions includes the role with lower permissions. For example, the Admin role includes the Analyst role permissions. * User group nesting Cortex XSOAR 8 uses group nesting, where the group with higher permissions includes the permissions of the group with lower permissions, but as a subset of the group with lower permissions. For example, the Admin user group is included as a subset of the Analyst user group, as shown in the following graphic. The Admin role includes the permissions of the Analyst role, the same as in Cortex XSOAR 6. ![nested-roles.png](/files/czMssUsyEgtroc6RDL1k) For example, from the user group example above, you have the following roles: * Employee * Content Developer * Analyst In Cortex XSOAR 6: The Employee role is nested in the Content Developer role and is also nested in the Analyst role. In Cortex XSOAR 8, the Employee, Content Developer, Analyst roles, and user groups are created separately. The nesting is reversed, so the Content Developer and Analyst User Groups are now nested in the Employee User Group rather than the Employee role being nested in Content Developer and Analyst roles in Cortex XSOAR 6.
**User migration** All users who were enabled in Cortex XSOAR 6 are enabled in Cortex XSOAR 8. Users who were configured as disabled in Cortex XSOAR 6, remain disabled in Cortex XSOAR 8. Any new users that were created in Cortex XSOAR 6 after the initial data sync are not migrated at switchover and must be added manually. {% hint style="info" %} ### Note If an invitation was sent to a user in Cortex XSOAR 6 and the user did not accept the invite before the migration, that user is not migrated to Cortex XSOAR 8. {% endhint %} Users are migrated from Cortex XSOAR 6 to Cortex XSOAR 8 in each of the following tenants: {% tabs %} {% tab title="Main/Development tenant" %} Only users with a unique email address in Cortex XSOAR 6 are migrated to Cortex XSOAR 8 with the migration wizard. Email addresses should be valid and unique (you cannot reuse the same email address). SSO users SSO users from Cortex XSOAR 6 are migrated to the Cortex Gateway. During the switchover, all Single Sign-On (SSO) users are automatically activated in Cortex XSOAR 8. Local users Local users from the main tenant are not migrated to the Cortex Gateway. Before you start the migration process, create CSP users with a valid email address in your CSP account. During the initial data sync (at the end of the pre-migration stage), the users are mapped from Cortex XSOAR 6 to the CSP using the email address that was added for each user. {% hint style="info" %} ### Note During the UAT stage, the user is active only if the **Direct Role** is set to **Account Admin**. {% endhint %} {% endtab %} {% tab title="Child tenant" %} Only users with a unique email address in Cortex XSOAR 6 are migrated to Cortex XSOAR 8 with the migration wizard. Email addresses should be valid and unique (you cannot reuse the same email address). SSO users Users can only access the Cortex XSOAR child tenant using SSO. SSO must be set up separately on your child tenants. There is no propagation of SSO from the main tenant to child tenants. Local users Local users from the child tenant are migrated according to a defined email address and designated **PANW IDP** user type. All of these users are synced to the Cortex Gateway and set as disabled until the switchover date. Local users from the child tenant maintain an email address, which is not added to the CSP. {% hint style="info" %} ### Note During the UAT stage, the user is active only if the **Direct Role** is set to **Account Admin.** {% endhint %} {% endtab %} {% endtabs %} **User role migration** All roles created on the main tenant are migrated to Cortex Gateway and propagated to all the child tenants. Roles from a child tenant in Cortex XSOAR 6, are migrated to the child tenant in Cortex XSOAR 8. Roles from the main account migrated from Cortex XSOAR 6 to Cortex XSOAR 8 are mapped to **User Groups**. The **Group Name** takes on the name of the **Role**. In addition, Cortex XSOAR 8 comes out-of-the-box with Instance Administrator and Account Admin roles. Account Admins have access to all Cortex instances, but the Instance Admin only has access to a specific instance. Roles, including custom roles from Cortex XSOAR 6, are migrated at the initial data sync stage when the UAT phase begins. At the switchover date, users and roles are not resynced, so any roles created during the UAT phase in Cortex XSOAR 6 are not migrated. {% hint style="info" %} ### Note During the User Acceptance Testing (UAT) phase, only Instance Administrators and Account admins can access the Cortex XSOAR 8 UAT instance. You can invite more users to access the UAT instance, provided they have been assigned the Instance Administrator or Account Admin user role. To give them access, go to **Settings** → **Settings & Info** → **Access Management** → **Users**, select the user, and then select the Activate option. The user will then receive an email about how to log in. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/xsoar-migration-guide/cortex-xsoar-8-saas-multi-tenant-migration/migrate-from-cortex-xsoar-6-multi-tenant-to-cortex-xsoar-8-saas-multi-tenant-using-the-migration-wiz/step-3.-run-user-acceptance-tests-uat-in-a-multi-tenant-deployment-using-the-migration-wizard/users-user-groups-and-roles-multi-tenant.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.