Description
We’re bringing new functionality and options to access request approvals! Enhancements include:
- My Requests can now show the assigned people behind a governance group approval!
- Approvals now automatically expire (with a configurable lifespan) when they get old and stale with no decision made.
- Escalations and reminders are now more flexible for admins to configure.
Note: The enhancements have been built in a new approvals service that will be running all net-new access request approvals. There will be a 90-day transition period during which old requests will still be processed by the old service. As such, these enhancements will only apply to new approvals, and you may see a mix of behaviors and options during that transition window.
Solution
Governance Group Visibility
The access-request-config endpoint now includes a flag called govGroupVisibilityEnabled. When set to true, requesters and requestees viewing the Process tab details of any My Requests record will see an option to expand a governance group approval step to show the people behind the group. The first 10 members of the governance group can be displayed there, to help the user know who to reach out to for help. This visibility configuration applies to all governance groups in the tenant and impacts all users.
Automatic Expiration
Until now, approval requests that went unaddressed simply lingered in a pending state indefinitely. Recognizing that stale access requests represent, at a minimum, access the user probably doesn’t really need and, at worst, a possible security risk, we are instituting approval expiration. By default, access requests will now expire after 90 days if they have not been fully approved by that time. Admins can configure a shorter span if desired. By default, expiration results in auto-denial; however, the approvals configuration includes an option to instead have expiration trigger auto-approval, based on customer preference.
Escalations and Reminders
The approvals service that will now be managing approvals has its own set of configuration options. For convenience and continuity, the configurations you have previously set for access request reminders and escalations will be migrated over to the new service, but there’s more flexibility available if you want to adjust the settings. For example, you can:
- Set up reminders without escalations
- Set up escalations without reminders
- Define the reminder/escalation cadence with more options – including all the way to the granularity of a Cron string
All of this can be done via the sp-approvals config API.
Approvals Flow Improvements
You will also notice a a couple of adjustments to approval assignment in the case of assignee gaps, escalations, and multiple assignment.
- Approver resolution: When an approval assignment can’t be resolved (for example, a manager approval is required but no manager is configured), the approval escalates through the full escalation chain, up to the fallback approver, before applying our prior behavior of filling approval gaps with an ISC Org Admin. The Org-Admin-assignment behavior is used only when no escalation chain is configured or when the escalation flow still cannot identify an assignee.
- As an extension of this change, when a governance group assignment is escalated to the members’ managers, we will not fill in the escalation gap for a member who has no manager by escalating to an Org Admin. Instead, while the other approvals will escalate to managers, the user without a manager will retain the approval for that escalation level. If none of the members have managers to escalate to, the escalation path will proceed to the fallback approver.
- Consolidated approval assignment: A user assigned as an approver more than once for the same request/item (for example, as both manager and owner) will receive only a single approval request. Their decision will be applied and audited for the whole set required approvals from that user.
Consolidation of Approvals via API
Organizations who heavily use our APIs should make note that an additional option available to you after this migration completes is a single API endpoint for retrieving all pending approvals - beyond just those for access requests - including workflow “generic” approvals, entitlement LLM description approvals, and more (as we continue to add other approval types to our approvals service). You can decide whether to filter by approval type or not, depending on your requirements.
Retirement of the Old Approvals Flow: Special Considerations
For the first 90 days of this transition, requests that were submitted before the enhancement was deployed will be processed by the old approvals service/flow, while any new requests submitted after deployment will be processed by the new service. There are some important details for you to note, with regard to this transition.
One-Time Expiration: At the end of 90 days, a one-time job will run in your tenant to auto-expire any remaining outstanding approvals being managed by the old approval flow, to enforce the new expiration behavior even on the older approvals. This means that, for example, requests submitted 5 minutes before and requests submitted 12 months before will get an additional 90 days from feature deployment for someone to resolve them.
Configuration support: Until now, the access-request-config API endpoint has controlled the reminder/escalation config as well as the auto-approval config for access requests. The new approvals service supports more options than the old service did and has its own config API endpoint where you can configure those more advanced features. Our guidance to you with respect to these endpoints is as follows:
- To change approval-related settings for the new service, use the approvals service config API endpoint instead of the access-request-config API endpoint.
- We are releasing a /v2026 version of the access-request-config endpoints (GET and PUT) that omits the approval-related attributes, to minimize confusion. If you are planning to take advantage of the new service’s expanded options, you should update any scripts that call the access-request-config endpoints for other access request settings to invoke the /v2026 endpoints.
- For backward compatibility, the /v2025 and earlier versions (which are being marked as deprecated) will continue to allow you to set its supported configs, and any values submitted with those PUT endpoints will be pushed across to the approvals service. This means that use of the /v2025 and earlier PUT endpoints will overwrite any of the more advanced feature settings you may have set directly with the approvals service config endpoint. This is why, once you choose to take advantage of the new features, you must discontinue use of these earlier access-request-config endpoints.
Who is affected?
This will impact all access request customers.
Action Required
The migration itself will be automatic - no customer action required for the automatic expiration and the other noted approval behaviors, and your approval reminder and escalations should continue as before. Actions are only required to take advantage of some of the enhanced behaviors:
- An admin needs to configure governance group visibility for My Requests, if that behavior is desired.
- You can modify your reminder and escalation configs as needed.
- You can shorten the expiration period for approvals as you prefer.
- You should update any scripts that call the access-request-config endpoints to use the /v2026 versions instead.
Note: Action details for each are listed in the Solution section above.
Important Dates
Our planned rollout of these enhancements is as follows:
Calendar
By RSVP’ing to this event you will be reminded of this release prior.
- Sandbox: Week of Feb 9, 2026
- Production: Week of February 23, 2026