I’m looking for some assistance with a workflow that I’m building with the Access Request Dynamic Approval external trigger. We’re implementing the ServiceNow Service Catalog integration for access requests, and I’m trying to block users from submitting access requests through the ISC UI, so they can only go through ServiceNow. I’m aware that I can change the config parameter to block all but external requests, but we would still like to provide the ability for our access team to submit access requests on behalf of other users.(and those team members aren’t Org_Admins) I’ve been following along with Colin McKibben’s write-up regarding how to implement this external trigger, and I’ve been successful getting it to cancel requests that I don’t want to occur, but I can’t get the http call to the callbackURL to allow the requests that I do want. The call is completing successfully, but the access request fails with an “Error: Please contact your administrator” message.
The message body that Colin shows in his request does not reflect what the documentation for this trigger shows, which just states to reply with null values if you don’t wish to add an approver.
Calling with the latter format completes successfully, but results in the access request failing.
I’ve also tried just passing what the documentation shows and adding the secret to it, since I’m using the trigger in async mode, but I’m getting json format errors with that method. Can anyone shed some light on what the response body should look like for an async callback on this trigger when you want the request to continue without adding an approver?
In this kind of scenarios, as you said we use the requestMustBeExternal flag in the AR Configuration but in your case I would recommend creating a simple Segment with all your requestable items and flag the users that should do the request in SailPoint. The segment won’t impact your SNOW integration and the visibility will be limited.
Your dynamic approver approach is a bit tricky because the goal is to add or not an additional approver, unless the additional approver that you add rejects the request, in that case it’s understandable.
To be able to assist you, you might need to share the workflow that you’re using because the async method requires the secret and the output of the approver to add or the secret with the approver value as {} to skip.
Thanks for your reply. After poking this thing for most of this morning, I was finally able to have some success with it. It took me a little bit to get the JSON format correct, but once I passed:
It finally allowed the access request to complete successfully. I’m still a little confused as I don’t see where the other attribute values are being stored (approved, approver, comment), since I don’t see it being displayed anywhere. The posted sample showed those values displaying in the access request in ISC. I can post the workflow, if you want to take a look at it.
That being said, while I do feel like this is probably using the trigger for something it wasn’t necessarily intended for, since I have no intention of adding an approver to these requests, the process does work for what I was needing. We currently have the Service Catalog module configured for “client credentials” so whenever it sends a request, it’s always coming in as an Org_Admin. I’m unsure if that would be case if we were using the authorization code, so I may test that in the next couple of days. I did test with a user that only had “HELPDESK”, and they were allowed to submit the request from ISC. I think I’m happy enough with it right now, though I’ll probably investigate some other methods to handle this eventually.
BTW, I did start looking into segments, but my understanding is that would also limit what a user sees in ServiceNow, provided you are using the authorization code method to connect in the module. Is that not the case?
From what was explained to me, segments do NOT apply in the SNOW catalog connector since it authenticates as an org admin and therefore doesn’t respect segment visibility.
I’m having a similar problem where I want dynamic approvals based on identity attributes, and the original plan was segments, but the catalog connector doesn’t seem to respect them.
Dynamic Approval Workflow may not help in this case, rather you should have Access request submitted trigger. And add the logic if request coming from Admins/help desk.