---
title: "Access control entitlement checks for Scheduler data resources"
slug: "access-control-entitlement-checks-for-scheduler-data-resources"
updated: 2025-01-23T11:58:08Z
published: 2025-01-23T11:58:08Z
canonical: "support.lusid.com/access-control-entitlement-checks-for-scheduler-data-resources"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.lusid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access control entitlement checks for Scheduler data resources

Scheduler performs entitlement checks before any user can call any [Scheduler API endpoint](https://www.lusid.com/docs/api/scheduler/intro) and interact with the data resources returned.

For much more information, [read our IAM documentation](/v1/docs/identity-management-and-access-control-iam). In summary, each Scheduler user must have (at least one) feature policy and data policy:

- A feature policy controls access to API endpoints. This is irrespective of whether a user interacts with Scheduler by calling its REST API directly, or indirectly via a proxy such as the SDK, the LUSID web app or Luminesce (since all proxies themselves call the Scheduler REST API).
- A data policy controls access to data resources returned by API endpoints.

To perform any real-world operation in Scheduler, a user must be assigned both types of policy. This is because a feature policy without a corresponding data policy yields no data, and a data policy without a corresponding feature policy cannot perform operations. [Work through a tutorial](/v1/docs/setting-up-access-control-for-different-scheduler-users).

The following table lists the data resource entitlement checks that Scheduler performs for each API endpoint. For example, consider a feature policy granting a user the right to call the [ListImages](https://www.lusid.com/docs/api/scheduler/endpoints/images/ListImages/) API endpoint. In the corresponding data policy, you should include:

- The `Repository` resource with the `Read` action to grant access to read the repository.
- The `Image` resource with the `Read` action to list any images in that repository.

| **API endpoint** | **Date resource checks** | **Notes** |
| --- | --- | --- |
| **Resource type** | **Action** |
| `UploadImage` | N/A | N/A | This endpoint does not interact with Scheduler but rather with Docker CLI. |
| `ListRespositories` | `Repository` | `Read` |  |
| `ListImages` | `Repository` | `Read` |  |
| `Image` | `Read` |
| `DeleteImage` | `Image` | `Delete` | You cannot delete an image using the Docker CLI; you must use this endpoint. |
| `GetImage` | `Image` | `Read` |  |
| `DownloadImage` | `Image` | `Download` |  |
| `ListJobs` | `Job` | `Read` |  |
| `CreateJob` | `Job` | `Create` |  |
| `Image` | `Read` |
| `GetHistory` `GetRunHistory` `GetJobConsoleOutput` | `Job` | `GetAllJobHistory` | You can allow an admin user to see history and results for a job even if they are not the user who originally executed the job. To do this, give that admin user these permissions. |
| `Schedule` | `GetHistory` |
| `UpdateJob` | `Job` | `Update` |  |
| `Image` | `Read` |
| `DeleteJob` | `Job` | `Delete` |  |
| `RunJob` | `Job` | `Run` |  |
| `Image` | `Use` |
| `GetSchedulesForAJob` | `Job` | `Read` |  |
| `Schedule` | `Read` |
| `ListSchedules` | `Schedule` | `Read` |  |
| `CreateSchedule` | `Schedule` | `Create` |  |
| `Job` | `Read` |
| `Image` | `Use` |
| `GetSchedule` | `Schedule` | `Read` |  |
| `UpdateSchedule` | `Schedule` | `Read` |  |
| `Schedule` | `Update` |
| `Job` | `Read` |
| `DeleteSchedule` | `Schedule` | `Read` |  |
| `Schedule` | `Delete` |
| `RunSchedule` | `Schedule` | `Read` |  |
| `Schedule` | `OverwriteTrigger` |
| `Job` | `Read` |
| `Image` | `Use` |
| `EnabledSchedule` | `Schedule` | `Read` |  |
| `Schedule` | `Enable` |