Long running approvals with many dynamic approvers

[Anonymous]

I have a process for approving an item in a SharePoint list. There can be up to 15 approvers, but each case is different because only the users who are affected need to approve (it's always the same 15 people). Some of these approvals can take up to 90 days as well.

I have many different active approval flows, but none are as complex is this one.  At first, I thought that I should have 15 parallel approvals with conditions before each one, but then it'll be very complex to create the second flow to extend the approval time. then I thought that maybe I could do one approval with "Everyone must approve" but i'm not sure if that's the best idea either. Does anyone have any idea how I should go about this? Any suggestion is appreciated 🙂

[wskinnermctc]

15 approvers for a sharepoint item? It can take up to 90 days?

Seriously that process sounds bad from the start. Are these approvers just looking at the item and not even touching it?

If that process is absolutely necessary, I would still try to rethink how this work is supposed to get done and come up with a way to chunk or divide these approvals. Then use some kind of additional column status or something to move it to the next person/group.

I don't think having approvals floating all over the place is an effective approach. Might be worth the time to look into using other tools like Microsoft Planner/Microsoft Project/Tasks or To Do notifications. 

Also think about how you can use a Switch action. I've seen a lot of examples of approval flows using chains of conditions when a Switch would probably keep it more organized. Doesn't necessarily change the flow, but I think it does look cleaner. 

Sorry I don't have a more positive answer. If you can say more about the work that is getting done, I might help think of a way, but I'm more thinking of the overall process and getting that organized better. I mean, how is this process getting done currently? Stamps on paper? Spreadsheet approval tracker?

[Anonymous]

I completely agree. These are for supplier change requests and the 15 approvers are the teams that could be affected by the change. There are multiple different change types; some require physical part testing to see if the requested change will work, which is why some can take up to 90 days.

The person who receives the request runs a report to see which of the 15 teams are affected, and they approve on an Excel sheet attached to a SharePoint item. All the tracking is done manually through every SharePoint item and by opening the attached document and we have about 300-500 of these a year. 

This is the current process as it was handed to me and I'm really thinking it'll need a complete overhaul.

[wskinnermctc]

Thank you, can you help me detail the Current process a little further:

1. The supplier submits this request through sending an email/form or something
2. An internal employee receives the request
   
   • Does the internal employee input this request into some software or tracker?
   • Is the internal employee always the same or like designated change request processor dept?
3. The employee uses the change request info (in some tool/program?) that has an output report which lists the possible (up to 15) teams that are affected by the change request.
4. The internal employee creates a list of teams in an excel file.
5. The internal employee creates a sharepoint list item and attaches the excel file.
   • Does the list item have like a status or number of approvers info for tracking?
   • How are the teams notified that they need to review the item?
6. The team(s) review the change request and does any testing.
   • Is there an established priority or approval order of the teams? (Like physical test team comes before the paint department team.)
7. The team(s) representative goes into the excel file and puts their approval.
   • Do the teams add any notes or summary about this change?
   • How does the change request processor know the excel file was updated?
   • What if the team doesn't approve or requires adjustments? (Would that start another internal change request?)

So you don't have to get super detailed, but I just want to get a better idea of the process. Like who is contacted and when, so I can think of triggers or notifications. Also about what data needs to be transmitted such as notes or documents, like does the physical test department need to keep their test results attached to the change request or something?

And how are declines or adjustments handled if they don't approve, is there like a "maybe if" type of approval?

--------------------------------------------------------------------------

Trying to brainstorm a process below, feel free to come up with other ideas or identify problems.

----------------------------------------------------------------------------------------------------

I'm kind of brainstorming like a primary change request list with 15 sharepoint columns that would be 1 column for each team and it has a status like "Needs Approval" - "Under Review" - "Approved" - "Rejected" - and default "N/A" 

So the request processor can create the item and put "Needs Approval" for each team that has to do an approval and "N/A" for the ones that don't.

SO this might start sounding messy, and this is just brainstorm so don't think this is the only or correct way, but hear me out. (You might also want to create a Subsite just to hold all of this.)

You have 15 different sharepoint lists, where 1 list is for each team. When the Primary change request is created or a status for the team is set to "Needs Approval" then it will create the change request item for the individual team's sharepoint list.

Making lists is easy, but now it will start getting messy with the flows only because of the quantity, but you can put all of this is in a Solution to help keep it organized better. It also allows for the ability to use Child and Parent flows.

You can decide how the team's are notified or process their change request. 

• Going to their sharepoint list and updating the item status manually.
  • Use scheduled flow to send reminders. (Basic but helps with long turnarounds and notifications can be sent to many people or groups.)
• Sending an custom approval that changes the item status automatically.
  • Use approval flow. (Convenient for approvers, but complex with reminders and long turnarounds.)

Whenever you come up with a method, you will have to make 15 different flows that are the same but based on the different lists. These can be triggered using a parent flow in some situations and the parent flow would wait for responses.

So tell me what you think about that idea, it will for sure be a project and not just a single flow. The approach sounds complicated, but I think it has a lot of additional benefits. One of the main benefits is the long term use and scalable options, especially for creating a Power App and change request dashboard. 

A single Power App could be used as a portal, drawing from all 16 of the sharepoint lists. Teams could go into the app an see everything they need on a dashboard as well as make selections or options.

That might sound like a lot, but I literally did not know how to use power automate or power apps a little over a year ago. I was able to make rather complex Power App that does scheduling, documents, and triggers approvals.

Another person in my organization is the exact same, he didn't know anything about power apps or flow, and over the past two years they have made a complete ticketing and service center app that is used across our state. (Neither of us work in IT, but we both are like analyst, so at least a little more understanding of logic and data than some other jobs.)

The power app isn't required. Mainly thinking of the Primary Request list as like the hub/dashboard/control point for most everything.

Hope that helps, let me know what you think.