ServiceNow Catalog Integration - Re-requestable Access Profiles

Question:
Is there a way to unlink/remove access profiles from a user’s identity cube without going through the access request “revoke” process to avoid triggering provisioning, with the goal to free up this access profile for future requests on the requestee? We do not want to completely remove ticketing on access profile removes for this source, as there are valid uses for that provisioning event. If access request “revokes” are the only means, maybe a before provisioning rule that has a conditional check that if the provisioning event is from an API call with some sort of tracking id, skip the ticketing integration and go straight to access profile removal?

Use Case:
Disconnected application source containing a catalog of requestable items exposed by the ServiceDesk Catalog Integration (ServiceNow). These are very generic items requested by managers during onboarding, usually with a single entitlement representing overall applications access and is intended as a simple solution to allow a collection of disconnected applications to be combined in 1 IdN source that can grow over time without setting up a disconnected source per app. Some items may represent a “change” request on an application, where the swivel seat provisioning details are in the comments. Catalog entry examples:

  • NurseTracker - New Account
  • NurseTracker - Modify Account
  • OtherApp1 - New Account
  • OtherApp1 - Elevated Rights Request
  • AnotherOne - New Account
  • AnotherOne - Location Change
  • AnotherOne - Other Change

Example:
Catalog Item Selected: NurseTracker - Modify Account
Comments: Give userx access to the Orlando fax queue.

Results in:

  • Ticket routed to the “NurseTracker” queue, with the selected item and comments. (note the CI for assignment queue is embedded in the entitlement name and is parsed out with velocity)
  • Ticket closed
  • Access Profile added to userx in IdN.

Problem:
Future changes for userx on “NurseTracker - Modify Account” are now blocked, as the user already has this access profile.

Possible Solution: script remove all access profile membership from this source in some interval.
Problem with that: this would result in a ticket since its SDCI integrated, when all I want to do is strip the access profile from the user.

Thanks everyone!

If anyone else in the community runs into a similar scenario, here’s how I solved the ability to re-request an access profiles.

  • Event Trigger - post-provisioning, filtered to source and status=committed.
  • EventBridge - Lambda Function, kicks off an access request (revoke) with a token in the comments to indicate the revoke request was from my trigger.
  • Modified JDBC provisioning - remove requests, if comments contain my “token”, bypass ticketing, immediately revoke the access profile, otherwise flow standard revoke requests to the ticketing integration.
  • if your client has workflow, id recommend going that route but that was not available in this case.
1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.