Role-based Permission Levels - Administrator Guide - 8 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Administrator Guide

Cortex XSOAR
Creation date
Last date published
Administrator Guide

RBAC permission levels for Cortex XSOAR components, including investigations, jobs, scripts, playbooks, and settings. Category permission levels for user roles.

When editing or creating new roles, you can set permission levels (RBAC) for specific components (such as playbooks, scripts, jobs, etc.) and set page access, define shifts, etc.


You can only create, edit, copy, or delete a role if you have administration (Instance/Account) permissions. You cannot change the Instance Administrator role permission.

The Components Tab




Sets the permission level generally for data related to investigations, dashboards, and reports. If you select none, the user role cannot view and edit incidents, indicators, dashboards, and reports.

When View/Edit is selected, you can limit the following permissions:

  • Data

    • Execute potential harmful actions - allows executing integration commands that are marked as Potentially Harmful in the integration code/settings. You would be able to run this from the XSOAR CLI. Playbook tasks that use these commands would not be affected, as they are run by the DBot user as part of playbook execution.

    • Edit incident properties - allows editing an Incident's fields from the layout or via the Actions menu.

    • Change the incidents status - allows editing an incident's status, which includes Closing an Incident, or investigating an Incident which is in the Pending status.

    • Delete incidents - allows deleting incidents. We recommend only granting this permission to the default Admin or select Administrators.

    • Manage the Work Plan - allows interacting with the Playbook on the Incident.

    • Edit indicators - allows editing indicators either from the Threat Intel pane, or when viewing the Indicator via it’s full layout or quick view tab.

    • Retain incidents - allows marking an incident for permanent retention or disabling retention for an incident. Retained incidents cannot be deleted.


    If you want to limit dashboards and reports, but allow other permissions, you need to remove access to those pages in the Page Access section.

  • Incidents Table Actions. Limit table actions in the Incidents page, such as delete, edit, close, mark as duplicated, etc.


If you want to enable chat in the War Room, but exclude permissions for everything else, you should give the role View/Edit permissions under Collected Data but remove all other granular data permissions. Also remove permissions in Integrations (under Settings). This leaves the role with access to chat only.


Limits permissions when editing, creating, or deleting an indicator in an exclusion list.


Limits permissions for creating, editing and deleting playbooks.


You can also add, change, and remove roles from a playbook when clicking Settings in the Playbooks page.


Limits permissions for managing scripts. If the role has read/write permissions, you can enable user roles to create scripts that run as a Super User.

In the Scripts page, you can define which roles are permitted to run a script, and according to which role the script executes.


Limits permissions for managing jobs. Roles that have read permissions to content items, retain partial read access. If you do not want to retain partial read access, set the permission to none.


You can set the following permissions for Marketplace.

  • None: The user role is not able to view Marketplace.

  • View: The user role can view, but not take any action in the Marketplace.

  • View/Edit: The user role can install, upgrade, downgrade, and delete content packs in the Marketplace.


You can set the permission level according to the following:

  • Integrations

    • Public API: Whether a user role can access the API Keys page. View/Edit enables the user role to create, edit, delete, etc., API keys.


      If you select None, the user role can still use the API, but they cannot view API keys in the UI.

    • Integrations: Whether a user role can view, add, edit or delete instances, pre-process rules and classify and map incidents and indicators.

      Roles that have view permissions for content items, retain partial read access. If you do not want to retain partial read access, set the permission to none.

    • Integrations Permissions: Enables you to set the permissions in the Integration Permissions page. Integration permissions enable you to assign different permission levels for the same command in each instance.

      • None: The user role cannot view the page.

      • View: The user can view the page.

      • View/Edit: The user can view and edit permissions.

    • Credentials: Whether a user role can add, edit, or delete integration credentials.

  • Object Setup

    • Fields and Types: Includes indicators, incidents and Threat Intel Reports.

    • Layouts: Includes indicators incidents and Threat Intel Reports layouts.

  • Advanced

    • Propagation Labels: (Multi-tenant only) Enables the user role to determine which content items can be synced to child tenants. You can select:

      • None: The user role cannot select a propagation label.

      • View: The User Role can select from existing propagation labels.

      • View/Edit: Create new and select propagation labels.

    • Administration: Limits permissions for administration tasks, such as server configurations, audit trails, changing logos, etc.

    • Tenant Management: (Multi-Tenant Only). If you have View or View/Edit permissions, you can select whether the role can sync content to tenant accounts.


Select the pages you want the user role to have access.


If you select None in the Data section, even though you allow page access, the user role cannot access those pages. For example, if you allow page access to Dashboards, but DATA is set to none, the user role cannot access the Dashboards page.

The Advanced Tab




Select the default dashboards for each role. If a user has not modified their dashboard, these dashboards are added automatically, otherwise users can add these dashboards to their existing dashboards.

If you select Only allow these dashboards, the current role will only be able to access the designated default dashboards. The role will not be able to import, edit, create, or duplicate any other dashboards. It will not be possible to share any additional dashboards with this role.


If a user had a role that accessed certain dashboards and the Admin changes the role to access only specific default dashboards, then the user will lose access to the previous dashboards.

To regain access to those dashboards or to allow access to any additional dashboards:

  1. The admin unselects Only allow these dashboards for the role.

  2. The user exports the relevant dashboards and shares them with the Admin.

  3. The Admin then adds the relevant dashboards to the default dashboards list for the role and reselects Only allow these dashboards.


Select the Preset Query per Role for each of the available components.


To define a shift period to the role, click Add Shift.

Weekly shifts start on Sunday and are specified in the UTC time zone.