This article introduces the Access Request Expiry feature.
- Okta Identity Governance (OIG)
- Access Requests Console
Over time, the lack of expiration causes a buildup of "stale" requests. This can be caused by some requests being stuck in an unresolvable state, but it is most often caused when a request is generated with an incorrect task assignee (they are sick, on PTO, etc.), and the user’s remediation is to create a new request with a new assignee, leaving the old one in the void.
Available in Preview at the end of January and Production at the beginning of February 2025, Access Request Expiry provides a solution where requests now automatically expire after 60 consecutive days of inactivity. Any requests created before the general availability of this feature expire after 60 days of inactivity (on or around April 7, 2025).
The feature includes:
- A new status for requests "expired".
- The status of a request changes to expired when there is no activity on the request for 60 days.
- A request will not expire if it has an active running timer.
- Notifications to requesters and step assignees (30 days, 5 days, 1 day before expiration, and on expiration).
- Send notifications to admins about all existing stale requests that need to be cleaned up.
- Mark all stale requests as expired.
- The user setting to receive daily reminders about overdue tasks and requests is no longer available. It is replaced by the new request expiration notifications.
- Requests that are not in an open or pending state (for example, expired, canceled, or resolved) will be archived one year after their creation date. This behavior is also consistent with our API (
/governance/api/v1/requests).
NOTE: At this time, notification expiration periods are not configurable by the end user.
