Catalog Item with many approvers based on items selected.

[EricG2]

I'm sure this has been done and not able to find where to start.

I've been asked to create a Integration hub flow for a catalog item that:

1.  Allows users to select multiple (over 500) Security Groups to be added to.

2. Each group will have an approver for it or possibly more.

3. When the item is ordered, it should then:

• Get approval for each item separately
• If rejected, then user is not added to group
• If approved, system adds them to the ad group (easy enough)
• Ticket should document approval for each item.
• Each item approved is added to a separate table which is used later to remove access.

This last part I have handled.  I'm just not sure how to handle the first 4, except  to limit the catalog item to only one security group select.   User then could add to cart for the remainder.

Thoughts?

[kmohammed]

Hi Eric — this is a good fit for Flow Designer, and you do not need to limit the item to one group. The key is one approval record per group, created inside a loop, rather than one approval for the whole request.

Suggested structure:

1. One approval per group

In the flow, after the RITM is created, loop over the selected groups with a For Each action (from the multi-select / List Collector variable). Inside the loop, call a subflow that handles one group end to end:

- Look up that group's approver(s) from your group/approver mapping (do not hard-code approvers in the flow).

- Use the Ask for Approval action to create one approval record per group, tied to the RITM (sysapproval = the RITM). If a group has more than one approver, use a group approval and decide up front whether any one approver or all approvers must approve.

- Wait for that approval's outcome, then branch. Do not let one group's rejection fail the whole flow.

2. Approved vs. rejected

- Approved: run the Active Directory spoke action to add the user to that group, create your tracking record in the separate table (include the approval record reference so the later removal process can trace back to it), and add a work note to the RITM naming the group and the approver.

- Rejected: skip the AD add, add a work note recording the rejection for that group, and continue with the next group in the loop.

3. Do not use a single approval for all groups

A single Ask for Approval action with all approvers gives you one decision for the whole request, not a separate decision, audit trail, or rejection per group. That is the part to avoid.

4. Turn off the catalog item's own approval

Set the catalog item's approval to No approval (or otherwise disable the standard item-level approval) so you do not get a second, item-level approval on top of the per-group flow approvals. The flow approvals are the approval record.

5. Documentation comes free if you do this

Between the per-group approval records (sysapproval_approver, linked to the RITM) and the per-group work notes, the ticket documents every decision. Your separate tracking table then only needs to hold the approved memberships for the removal process, which you already have handled.

One scale warning: a For Each loop over a large selection runs sequentially, so a request for hundreds of groups will be a long-running flow execution with approvals waiting in turn. That is fine for typical requests, but test with a large selection in sub-production before go-live. If large selections are common, consider splitting the request into one RITM per group (for example via an order guide) so each group's flow runs independently.

Regards,

Karimuddin