We have integrated our ServiceNow (SNOW) service catalog with Identity Security Cloud (ISC), and all access requests are initiated through the ServiceNow UI.
We have observed that when an access request is cancelled by the system in ISC due to the following error, the “Access Request Submitted Email for Requester After Validation” email template is triggered:
error: “The provided end date does not align with the required end date configuration of the requested item.”
However, the email notification is being sent to the service account used to configure the ServiceNow–ISC integration, as the integration uses this account’s PAT, rather than to the intended recipient.
Our requirement is to send an email notification to the user for whom the access was requested or to the actual requester when an access request is cancelled by the system.
We have explored the available workflow triggers and out-of-the-box (OOTB) email templates but have been unable to identify a suitable option to handle this scenario.
Has anyone encountered a similar requirement or implemented a solution for this use case in ISC?
Specifically, we would appreciate guidance on the following:
Is there an OOTB trigger or workflow condition that can be used to send an email notification when an access request is cancelled by the system due to an end-date configuration mismatch?
Is it possible to configure the notification to go to the actual requester or the identity for whom access was requested, instead of the integration service account?
If this is not supported through the existing workflows or email templates, is there a recommended alternative approach?
Any suggestions, insights, or workarounds would be greatly appreciated.
Hello Ashwin. Since ServiceNow submits requests using a service account PAT, ISC records that account as the requester, which explains why the “Access Request Submitted Email for Requester After Validation” notification goes to the service account.
A few things I would suggest checking:
1. Getting the notification to the actual requester: The standard ServiceNow Service Catalog integration supports a User Account (Authorization Code) connection method, where requests are submitted under the logged-in user’s identity. This allows the validation email to reach the actual requester. Moving from your current PAT setup would require an integration change, and notifying the Requested For identity would still need separate handling. ServiceNow Connection Methods
2. Trigger for system-cancelled requests: From the available ISC event triggers, I do not see a dedicated OOTB trigger for requests cancelled during validation. The Access Request Cancelled email template is also different, as it applies to pending requests being cancelled rather than this validation failure. Available Event Triggers
3. End-date validation: I would compare the Require End Date and Maximum Duration settings on the requested item against the startDate and removeDate values ServiceNow actually submits, including timezone conversion. One important detail: when a start date is supplied, ISC calculates the maximum duration from that date rather than the request time. I would check the actual submitted API payload rather than relying only on the dates displayed in ServiceNow.
Also, fallbackAccessDurationInDays only helps when an end date is required but missing and the requested item has no maximum duration configured. It will not correct an explicitly submitted date that exceeds the maximum. Access Request Configuration
4. Alternative notification approach using ServiceNow: If you prefer to continue using the current PAT-based integration, I would suggest handling the notifications through ServiceNow. SailPoint’s Create Access Request API can return accessRequestIds in its response. If your integration captures these IDs, you could associate them with the corresponding RITM and query the Access Request Status API (GET /access-request-status/v1), filtering on accessRequestId, to check the status and notify the actual requester or Requested For user.
I would first reproduce the end-date failure and confirm that the request ID and a usable failure reason are available. A Canceled status alone is not sufficient, since duplicate requests and user cancellations can also produce that status, and I would not assume the reason is always available in cancelledRequestDetails.comment or errorMessages. This may also require some customization if your ServiceNow integration does not currently capture the request IDs. Access Request ID Enhancement
When ISC cancels the request, does the corresponding ServiceNow RITM also move to a cancelled or failed state, or does it remain open? If ServiceNow already captures the validation failure, handling the notification directly through Flow Designer would be simpler than adding another API-based check.
There is no OOTB trigger specifically for “system-cancelled due to end-date validation failure.”
OOTB notifications will typically go to the ServiceNow integration account if that account submitted the request.
The recommended workaround is a custom workflow that monitors access request status/events and sends email to the target identity or original requester using request metadata.