> 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/cortex-xsoar-8-on-prem/8.11/configure-cortex-xsoar/users-and-roles-management/roles-management/role-based-permissions.md).
# Role-based permissions
When creating or editing a role, you can set permission levels (RBAC) for specific components (such as playbooks, scripts, jobs, etc.), set page access, define preset role queries, and set up shift management.
In the Cortex XSOAR tenant, you can set permission levels for each role by going to **Settings** → **Settings & Info** → **Access Management** → **Roles** and editing or creating a new role.
{% hint style="info" %}
### Note
You can only create, edit, copy, or delete a role if you have administrator (Instance/Account Admin) permissions. You cannot change the predefined (Instance Administrator or Account Admin) role permissions.
{% endhint %}
Each role contains the following tabs:
**The Components tab**
The Components tab includes the following areas where you can define permissions.
**Data**
{% hint style="info" %}
### Note
You need to select View/Edit to see the permissions for the components.
{% endhint %}
| Component | Description |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data | 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. |
| Execute potential harmful actions | Allows executing integration commands that are marked as Potentially Harmful in the integration code/settings. Users can run these commands from the 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 incident status | Allows closing or reopening an incident. |
| Delete incidents | Allows deleting incidents. We recommend only granting this permission to the default Admin or select Administrators. |
| Manage incident workplan | Allows interacting with the playbook for the incident. |
| Edit indicators | Allows editing indicators either from the Threat Intel pane or when viewing the indicator via its 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. |
| Incidents Table Actions | Limits table actions in the **Incidents** page, such as delete, command line actions, edit, close, and mark as duplicate. |
**Exclusion list**
| Component | Description |
| -------------- | ----------------------------------------------------------------------------------------- |
| EXCLUSION LIST | Limits permissions when editing, creating, or deleting an indicator in an exclusion list. |
**Playbooks**
| Component | Description |
| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Playbooks | Limits permissions for creating, editing, and deleting playbooks.
Note
You can also add, change, and remove roles from a playbook by clicking Settings on 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.
On the Scripts page, you can define which roles are permitted to run a script, and according to which role the script executes.
|
**Jobs**
| Component | Description |
| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Jobs | 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. |
**Marketplace**
| Component | Description |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Marketplace | 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 Marketplace.
- View/Edit: The user role can install, upgrade, downgrade, and delete content packs in Marketplace.
|
**Configurations**
| Section | Component | Description |
| --------------- | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| General Setting | Auditing | Whether a user role can access the **Management Audit Logs** page. |
| General Setting | Alert Notifications | Whether a user role can forward Management Audit Logs to an email distribution list. |
| Integrations | Public API | Whether a user role can access the API Keys page. View/Edit enables the user role to manage API keys, including creating, editing, and deleting.
Note
If you select None, the user role can still use the API, but they cannot view API keys in the UI.
Whether a user role can view, add, edit, or delete integration 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 | Integrations Permissions | Enables you to set the permissions on 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.
|
| Integrations | Credentials | Whether a user role can add, edit, or delete integration credentials. |
| Object Setup | Fields and Types | Whether a user can add, edit, or delete fields and types for indicators, incidents, and Threat Intel Reports. |
| Object Setup | Layouts | Whether a user can add, edit, or delete layouts for indicators, incidents, and Threat Intel Reports. |
| Advanced | Administration | Limits permissions for administration tasks, such as server configurations, audit trails, and changing logos. |
| Advanced | Propagation Labels | (Main tenant) Whether a user can add, edit, or delete propagation labels in the **Tenant Management** |
| Advanced | Tenant Management | (Main tenant) Whether a user can add, edit, or delete child tenants in the **Tenant Management**. |
**Page Access**
Select the pages the user role should have access to.
{% hint style="info" %}
### Note
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.
{% endhint %}
**The Advanced tab**
Define access to default dashboards, pre-set role queries, and shifts. For more information, see [Manage roles in the Cortex XSOAR tenant](/cortex-xsoar-8-on-prem/8.11/configure-cortex-xsoar/users-and-roles-management/roles-management/manage-roles-in-the-cortex-xsoar-tenant.md).
| Component | Description |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DEFAULT DASHBOARDS | 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. |
| PRE-SET ROLE QUERIES | Select the preset query for each of the available components. |
| SHIFTS | Weekly shifts start on Sunday and are specified in the UTC zone. |
---
# 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/cortex-xsoar-8-on-prem/8.11/configure-cortex-xsoar/users-and-roles-management/roles-management/role-based-permissions.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.