Perhaps as an example to give some inspiration, here is a custom access request process I created in ServiceNow that is backended by IdN
On the request form, the user can either request a “template role” (which is just a role in IDN) or request a specific access profile that is mapped to a specific sap system
The drop-down is filtered based on what the user selects in the drop-down above. Since my ServiceNow instance stores all the SailPoint roles/entitlements/access profiles in a table, I am able to let the user select more than one access profile at a time. For each access profile selected, the workflow will generate an additional RITM tied to the same REQ record, so that each access profile has an individual approval.
The workflow has two approval stages - the manager of the requestor, and the owner of the access profile. The latter is populated by querying the SailPoint API at runtime and storing the owner record in the workflow scratchpad.
Since I have these records stored in a ServiceNow table, I have a flag on each record to say whether or not the provisioning is manual or automated. If it’s automated, it sends the request to IdN. If it’s manual, it assigns it to a specific assignment group that comes from a custom reference field on the catalog item itself.
This workflow is able to be shared across multiple catalog items, so creating catalog items for specific applications is very easy. It also contains a couple of extra features like the ability to set a delayed provisioning start, a sunset date on the access, a check to see if the user already has the access assigned, as well as a preventative SOD check
Here’s a screenshot of that workflow
