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.
I would start with “Access Request Submitted“ Event Trigger
@iamnithesh is correct - you’d need to use the Access Request Submitted trigger with a workflow
I would suggest having the workflow checking if the identity that created request was your identity ServiceNow is using OR one of your ISC admins. There are times when a provisioning request fails for whatever reason and the fix is to manually resubmit it.
Rather than having them go back and re-request it in ServiceNow, making an API call that mimics the ServiceNow call (specifically the request metadata it includes) would be a good option to have.
If the workflow sees that neither ServiceNow nor one of your admins submitted the request, it can respond to the trigger with false so that the request is cancelled.
I did a similar use case for this, but wanted to make sure only people who were members of a specific AD group were able to submit requests in request center, otherwise they’d be cancelled by the workflow.
I think this is what you need :
Thank you. Using an AD group is a good idea too. We’ll have to experiment with how to utilize this and see if we can get something figured out. We have not utilized workflows or event triggers much so appreciate the direction for sure.
Option 2 of this was the direction I was leaning.
The AD group approach allows you to be a bit more flexible around who can submit an access request in case you want non admins to be able to submit “back door” requests. Note the links @lampard08 posted - if you set approvalsMustBeExternal to true, only admins can submit requests via request center
I did see that was Option 1 on that link. Option 2 is creating a workflow to evaluate the origin of the access requests and cancel if it did not originate from the ServiceNow Service Catalog connector. I am just not sure which attribute to look at to make that determination and then tell the workflow to cancel it if it wasn’t from SN. “In the workflow, add an Approver Action to reflect the individual that would be assigned an approval task if a request is not assigned from ServiceNow. If applicable, configure the HTTP action to cancel the request.”
What I suggested is slightly different from option 2 in that it uses a different workflow trigger (access request submitted vs access request dynamic approver). You don’t have to assign an approval using the trigger I recommended, you can just evaluate using a conditional statement on whether or not the request should continue.
Makes sense! Do you have a sample you’d be willing to share?
We did this in our ISC tenant, to stop all requests in Request Center UI, and to only use Service Now
How we did this is put all Roles and Access Profiles in a Segment, and then add no users to that Segment.
I created separate Segments for Roles and Access Profiles…
Here is some ruby code to get you started. It was a while ago I wrote this, so that is why below code uses /v3 and /beta
roleSegmentID = createSegment("Role Segment", "Contains ALL ROLES")
offset = 0
count = 40
assignmentBody = ""
url = "#{$config['baseUrl']}/v3/roles"
url2 = $config['baseUrl'] + "/beta/segments/#{roleSegmentID}/change-assignments"
puts "Posting #{url2}"
while count == 40
responseBody = IDNAPI.getWithCount(url,offset,count,"",$config['access_token'])
count = responseBody.length
puts "Roles - offset: #{offset} - count: #{count}"
assignmentBody = constructRoleBody(responseBody)
#puts "assignmentBody: #{assignmentBody}"
response = IDNAPI.post_json(url2, $config['access_token'], assignmentBody)
sleep(5)
offset = offset + count
end
As we add roles and AP’s to our ISC, we re-run the script to add them to the segment.
Note that after you create a segment and add roles and AP’s - it can take a few hours for ISC UI to refresh, so wait a day before you check Request Center UI
Thank you for your guidance!!
Thank you so much! We’ll review this option too! Truly appreciate all of the ideas!