Has anyone successfully included Access Request details, specifically the Access Request ID, in a SailPoint ISC email template?
I’m trying to populate the Request ID in an email template. I attempted to use $__contentJson.accessRequestId, but it doesn’t appear to be working. If anyone has implemented this before, could you share how you retrieved the Request ID or any access request attributes?
Thanks in advance!
Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
Please consider addressing the following when creating your topic:
What have you tried?
What errors did you face (share screenshots)?
Share the details of your efforts (code / search query, workflow json etc.)?
What is the result you are getting and what were you expecting?
$__contentJson is only available in version 2 templates. The Access Request Decision template uses version 1 variables, and accessRequestId is not exposed as a template-specific attribute, so $__contentJson.accessRequestId will not resolve.
If you need the request ID in a notification, one way to do it is through a workflow using the Access Request Decision trigger. The trigger payload includes accessRequestId at the top level. In the Send Email action, you would map it in the templating context like this:
Implemented this using a custom workflow on the Access Request Submitted trigger with a Send Email action, referencing {{$.trigger.accessRequestId}} directly in the body/subject — this gives you the actual Request ID since it comes straight from the trigger payload, not the system template’s rendering context.
Reference: Access Request Submitted trigger
To avoid duplicate emails, I suppressed the OOTB notification for that specific application by adding a check in its Subject field: if the object name contains “test”, it hits #stop, halting that template before it sends — so only my custom workflow email goes out for that case.
Reference: Using Email Templates
One thing worth flagging for anyone reusing this: #stop only prevents that specific template from sending — if the requested item spans multiple applications/roles in the same submission, the OOTB email still sends normally for the others, since #stop halts the whole template render, not just the matched line. Also worth confirming your custom workflow doesn’t fire twice per request if the access item type triggers both Access Request Submitted and a downstream Provisioning event separately, depending on your source’s provisioning setup.
Reference: Send Email workflow action
One additional thing to be aware of: if you’re using this approach to suppress the OOTB email by adding logic in the Subject field, keep the subject length within the supported limit. The rendered subject (including your conditional logic) should not exceed 250 characters; otherwise, the template may not behave as expected.
For example, if you want to suppress the email when the access request contains specific roles:
#set($roles = $requestedObjectNamesByType.get("Roles"))
#if($roles && ($roles.contains("test1") || $roles.contains("test2")))
#stop
#else
${requesterName} has requested access on your behalf.
#end
This approach checks whether the requested roles include test1 or test2. If either role is present, #stop prevents the email from being sent; otherwise, the subject is rendered normally. This is also useful when you want to suppress notifications based on multiple requested roles in a single access request.
Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.