> 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-xsiam/reference-and-developer-docs/role-based-access-control/investigation-and-response-permissions/automation-permissions/jobs-permissions.md).

# Jobs permissions

Configure access to automation jobs. Jobs are scheduled playbook tasks that run at predefined intervals or in response to feed changes.

By default, the **Jobs** permission is set to **None**. While you can enable the Jobs permission itself, you will not be able to select playbooks to run within the job unless you have at least Viewer access to those playbooks. Additionally, viewing the results of a job within a case requires access to the Cases & Issues component.

| Permission | Description                                                                                                            | Roles Example                                                                                |
| ---------- | ---------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| View/Edit  | Users can create, edit, enable/disable, and delete jobs. They can also manually trigger a job to **Run now**.          | SOC Manager / Security Engineer: Needs full control over scheduling and operational tasks.   |
| View       | Users can view the list of all scheduled jobs, their status (Running, Error, etc.), and their next scheduled run time. | Compliance Auditor: Needs to verify that automated cleanup or reporting tasks are scheduled. |
| None       | Cannot access the Jobs page or view any job configurations.                                                            | Standard User: Does not require access to backend automation scheduling.                     |

### Required and recommended permissions

To work with jobs, an administrator must configure your user role with specific RBAC permissions.

<table><thead><tr><th width="238">Component</th><th>Permission Level</th><th>Reason</th></tr></thead><tbody><tr><td><strong>Scripts</strong> (under <strong>Investigation &#x26; Response</strong> > <strong>Automations</strong>)</td><td>Enabled</td><td>Required to view and manage the underlying scripts used in automation workflows.</td></tr><tr><td><strong>Playbooks</strong> (under <strong>Investigation &#x26; Response</strong> > <strong>Automations</strong>)</td><td>Enabled</td><td>Required to select and view the playbook logic that a job will execute.</td></tr><tr><td><strong>Jobs</strong> (under <strong>Investigation &#x26; Response</strong> > <strong>Automations</strong>)</td><td>View or View/Edit</td><td>Enables access to the Jobs page to monitor or manage scheduled tasks.</td></tr><tr><td><strong>Cases and Issues</strong> (under <strong>Cases &#x26; Issues</strong>)</td><td>View or View/Edit</td><td>Required to view the results (War Room/Work Plan) of jobs executed within an investigation container.</td></tr></tbody></table>

### Important considerations

* **Visibility**: For all users with View or Edit permissions, all Jobs are listed regardless of the user's object-level access to the specific Playbooks used in those jobs.
* **System execution**: Playbooks triggered by jobs run as "system". They are governed by the permissions of the involved integrations rather than the access context of the user who created the job.
* **Execution results**: To view the War Room or Work Plan for an investigation opened by a job, the user must have the **Cases & Issues** permission set to **View** or **View/Edit** (which in turn requires **Playbooks** and **Scripts** to be enabled).


---

# 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-xsiam/reference-and-developer-docs/role-based-access-control/investigation-and-response-permissions/automation-permissions/jobs-permissions.md?ask=<question>&goal=<endgoal>
```

`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.