Need solution for looping approval requests

[chadlockwood]

I have a service catalog item that allows the requestor to select any number of distribution groups, from a slushbucket, to become a member of. The catalog item 'workflow' simply creates a task for our helpdesk to manually acquire approval from each groups' owner/manager. We would like to automate this further by sending an approval request and automatically add the group membership, but we run into an issue with potentially requiring multiple, concurrent, unrelated approvals. Let me give an example:

Requestor selects from the slushbucket:

Group1

Group2

Group3

Groups 1 and 2 require approval from Manager1 and Manager2, respectively. Group3 does not require approval, so the workflow can automatically add that membership.

At this point we need to send an approval request to both Manager1 and Manager2.

1. Each request should not affect the other.

2. If Manager1 approves, membership to group1 should be granted. This should not approve the request for Group2.

3. If Manager2 rejects access to Group2, it should not affect the request for Group1.

4. If Manager1 approves immediately and Manager2 takes a couple of days to respond, this should also not hold up the approved access to Group1.

Has anyone had any luck with this kind of looping approval requests or found another way to accomplish this?

Thanks,

Chad

[Michael Ritchie]

How do you determine if a group requires approval or not?

This is tricky and I was composing a response and realized there are still holes in the approach given the complexity of one group not holding up another.   It's a lot to manage in a single request.   Honestly the best thing to do is to create a request with a request item for each group chosen.   This way each group request can operate independently.   You can lookup if group requires approval or not, route for approval if necessary, and add the user to the group.

You can leverage the Cart API to create child request items for each of the groups chosen.   You could have a generic record producer that doesn't generate a record, but in the script loops through the groups and uses the Cart API to generate the request and items.

I hope this makes sense, it's a complicated but interesting requirement.

[chadlockwood]

Michael,

Thanks for your reply. To start with, if the group record in SN listed a manager from AD, that person would receive an approval request. Going forward, at least for Distribution Groups, I would query Exchange for the Membership Approval settings.

I like the idea of using the Cart API to spawn child RITMs, however, I am concerned that my requestor may potentially be immediately buried in RITMs in CMS, depending on how many groups they selected. This catalog item is also incorporated in our on-boarding order guide so the hiring manager may be selecting quite a few groups for their new employee. Of course I would want my requestor to know the status of their membership request; I would just like to do it without adding so many RITMs for them/us to track.

It would make sense though if the approval is applied to the RITM level, I would need individual RITMs to fully use the approval functionality.

I will try out this idea and let you know how it goes.

Thanks,

Chad

[Michael Ritchie]

I completely understand the concern over the number of Request Items that may show up in the queue.   Thinking out-loud here based on your additional explanation... Approvals can happen on any record in ServiceNow.   With this said, you could create 1 request item as you do today but create a task for each individual group selected.   Then create a special workflow that launches on the creation of the sc_task records that will then request approval.   Then once the task is approved (or not if not required) have it automatically add the user to the group.   Given that Service Request has this additional task layer you could push it down a level.

I mention a "special workflow" because I wouldn't expect you to want a workflow to launch for every sc_task that gets created.   Thought would need to be put into defining when this workflow would start or not.   Maybe add an attribute on the sc_task table that this workflow leverages.

This would mean no approvals are required at the request item level, and you would have a run script activity that loops through the groups chosen and generate a sc_task record for each of those groups via script.   Then you need to implement logic for these manually created tasks to report back to the request item so it knows when the workflow should end.   Based on what you said there could be a large number of groups so you may need to add a "percent complete" type field on the sc_req_item table anyway so the requester has visibility into where their request is.   You could then have your workflow look at that percent field to get to 100 to end.

[robm]

This just came up for me at work today as well. Only thing I could think of was to create a separate RITM for each group.