Access Request Submitted - No Way to Examine Request as a Whole When Multiple Items Are Requested

[Rockmus (Ilya Krivulin)]

@colin_mckibben tagging you here, since I found a topic that is directly related to this that you participated in.

Access Request PreApproval Event Trigger- Multiple Access profiles get passed as body

Hi All, When someone is raising a request for multiple access profiles (say 2 access Profiles ), then 2 access request line items are created but both the requests get passed to the same Access Request PreApproval Event Subscription. Example: John raises access request for AP1 and AP2. 2 request line items are created for API1 and AP2 in My Requests page. The Access request preapproval event trigger is getting triggered only once and passes both API1 and AP2 in the JSON body. Is this expect…

While I agree that there are benefits of getting multiple item requests split into individual access requests, the original functionality that is mentioned in the thread above that has since been removed is actually what we need.

There needs to be a way to examine and approve/deny the original access request as a whole - before it’s all split out into individual access requests. Once the split occurs, there is virtually no way to tell if the items belonged to a single “parent” submission.

Consider this use case: certain applications allow only a single application role assigned to a user at any given time. When multiple roles are requested at the same time for the same application, the request needs to be denied. Once the request is split out, it becomes virtually impossible to get this handled correctly with limited filtering ability and the concurrent nature of the “submitted” event subscriptions firing for individual requests.

What would be really nice actually is if the the “submitted” trigger looked at the request as a whole and allowed you to approve/deny individual items, and only perform the split after that.

[christophe_choumert]

@Rockmus

Consider this use case: certain applications allow only a single application role assigned to a user at any given time. When multiple roles are requested at the same time for the same application, the request needs to be denied. Once the request is split out, it becomes virtually impossible to get this handled correctly with limited filtering ability and the concurrent nature of the “submitted” event subscriptions firing for individual requests.

I don’t have a solution for your overall issue, but for this specific use case, using SoD rules to mark any 2 “roles” from this application as incompatible should achieve broadly what you want, no?

[Rockmus (Ilya Krivulin)]

Thank you, yes, considered that option, but Role SoDs are not supported as of yet, only entitlements.