Create a new access review campaign.
The review's initial status depends on whether apps are provided and whether a target_launch_date is set:
- With apps: the review starts in
IN_PREPARATIONwhile account and entitlement snapshots are taken. Status automatically transitions toIN_PROGRESSonce snapshotting completes. - Without apps: the review is created directly in
IN_PROGRESS. - With a
target_launch_date: the review is held for that date inSCHEDULED, orSCHEDULED_IN_PREPARATIONwhile its apps are snapshotted, and returns toSCHEDULEDonce snapshotting completes. A daily job launches it on the date, moving it toIN_PROGRESS.
A recurrence_config or recurrence_days_frequency takes effect only alongside a target_launch_date; sent without one it is rejected.
Poll GET /access_reviews/{id} to observe the status transition. To add apps after creation, use POST /access_reviews/{id}/apps (allowed on any status except COMPLETED).
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Validation error — the request violated a business rule (e.g. duplicate review name, deadline in the past, review not in the required status for this operation).
Forbidden — the caller lacks permission for this change. Creating a review requires the access_reviews.create permission on the domain. Organization admins and App Admins have it, and a custom role can grant it. Changing an existing review requires access_reviews.manage on that review. Organization admins and the review's owners have it, and a custom role can grant it.
Not found — the referenced review / app does not exist.