No matter what your work process is, you're probably going to have some approvals in it somewhere. You might have multiple places where approvals can pop up. You might even have some negotiations with outside parties, which can only mean one thing: you'll need to get the right approvals from the right people for all those changes.

So how do you get approvals? If you don't already have a module in a system capturing the approvals, like most people, you'll probably turn to email. Let's go through why email is a terrible way to gather approvals.

First of all, the biggest problem is that email is not a permanent storage system. An email chain is generally only visible to people who are in the email chain. So what do we do? Include everyone in the email who could possibly want to know about the existence of this approval flow. And then we complain we are flooded with emails :/

The next thing wrong about a chain of emails, is well... it's a chain of emails. Each approver has to successively, one at a time, reply all, each person after that. If you have 20 approvers, that's 20 emails that you have to keep track of (and they all have to receive, adding to the flood!). Count to see when you've reached all 20 and chase anyone who hasn't approved. Are you keeping a spreadsheet of these somewhere else to track all this?

How are people showing approval? Do they simply reply all with "I approve"? Or do you have some kind of PDF attached that everyone must sign? Do they have to download the PDF then add their signature? Do you have people who don't know how to add a digital signature so they download the PDF, print it out on paper, wet sign, and then scan back to PDF and upload the PDF to attach it back into the email chain? Did you just lose all prior digital signatures because they did this? Or even if an approver knows how to digitally sign, did they accidentally check (or leave checked) a box that says "Lock document after my signature" making it so nobody can change the document after them? And what about the cursed "crossing of the streams" of emails when two people sign their version of the PDF and send it to everybody at once? So now you have two slightly different versions of the PDF for signing. So we have to back up the train wreck and decide that we're going to go with one of the versions and make the other person re-sign the other version. What a mess. What a terrible, terrible way to do things.

In the end, if you're lucky, you have a long email chain or a document with everybody's signatures. And you leave it in your email box. Auditors years from now will be looking over your transaction and ask "Who approved this exception?" Answer: "It's in so-and-so's email box... Ooops, they left the company". Even if the auditor is lucky and they find the email chain or the PDF with signatures, they might ask "What about the attached documents that they reviewed and approved? Can I see copies of those documents?" Whoopsie, email attachments don't always travel well with the rest of the chain of emails. They certainly are not in that signature PDF. "We got approvals, but we're not sure what they approved." :(

How do we overcome this mess?

Using something like DocuSign or AdobeSign might seem like the logical way to go. It involves yearly license fees for anyone to send a document to others for signature. If you're in a large company where everyone needs to gather approvals as part of their job, these fees add up fast. And plus digital signatures are overkill when all you need is internal approvals. Plus, you can't always add context to the request for signature. Or you may want feedback comments when someone gives approval, which they can't give with a simple signature. With things like DocuSign and AdobeSign, even when they are all signed, we still have the same problem only now each signed document is in an individual's repository of signed documents, not in a central place that is visible or discoverable.

Here is what I would do if I were to design my ideal approval system.

First of all, approvals are all captured and stored in an online database. Period. Not in emails.

I would make my approval system be flexible. Yes, we may have set stages where we always need to get approvals. But the need for approvals can always come up at the strangest times. We need to allow for that. We also have a LOT of existing systems that are simply lacking an approval module. So we need to allow somebody to run the approval work flow or to connect into it with any system, and then pipe the results of the approval back to any system. Even in a manual way in case we never link the automation to all the various existing systems. How do we do this? Ultimately, I would make my approvals system produce a PDF that shows all the details of the approval flow. Place a unique URL on that PDF. Now I can take that PDF and upload it to any system that for whatever reason doesn't have an approval module.

What about security? Approvals are everywhere throughout companies. Your boss might want you to run a top-secret presentation by 10 people before you present it to the CEO. You wouldn't want just anybody in the company to be able to access your approval flow and then see the contents of your presentation that is attached to the workflow. So I would make it so each approval flow has a unique, non-guessable ID. Part of the URL. So you can only see a list of the approvals that you have been involved with. Either you created it or were asked for approval, or you were CC'd to be aware of it.

Thus, you will only see approval flows that you are authorized to see. What about the auditor that needs to see the document trail five years later? Well, she would have a copy of the PDF produced which has the unique URL on it. Having the URL, she would be able to go to the page to see the archive of the approval flow. How is this better than simply the PDF? Well, the archived web-page is not changeable and thus we can vouch that it is a true archive. We would lock it down so no changes can be made once approvers submit their approval/rejection and optional comments. We would also have the contents of the original documents there that were attached to be reviewed. And certainly the contents of those files will not be editable once the approval flow has been kicked off.

How would a requester know WHO needs to approve something? This is an interesting rabbit hole to go down. I would leave this discussion out of the general tool. Keeping a list of approvers and prescribing who needs to approve an infinite number of scenarios is just asking for trouble. Especially in a huge company. That list will change all the time and almost certainly never be up to date. For using this approval tool as its own separate tool, I would not tell the requester who the approvers need to be. Just make it flexible and let the requester decide that. Plus if something in a project changes halfway through collecting signature, or if an approver says "I'm not the one to approve this. This needs to go to Sally." Well, then the requester can just start another approval flow where they just get Sally's approval. See how flexibility is required here?

I'm not saying to never prescribe who the approvers should be. Certainly, when you link the approval module to a specific, existing tool that is missing the approval module, you might very well have a narrow list of "potential" approvers. You might present that list to your requester and train them on who needs to approve what and when or you might build that matrix into your other tool. Narrow your scope for when you want to engage in this.

When an existing tool connects to your approval module, here are the parameters it will need to pass on to your ideal module:

This request would come from your existing (outside) system and connect to your approval module. The approval system takes in the data and makes a line in the database for this request. Our approval module generates a unique ID for our approval system and passes it back to the originating system (we know which system because we got a unique identifier identifying that system and we can also pass back the unique identifier for the originating system to know which of its records it should update with the new unique identifier the approval module just created.) Now our approval system sends an email to each of the approvers with the URL where they should go to review and give their approval/rejection and optional comments. Anyone who is CC'd receives a similar email notifying them that the approval flow is in process and the URL where they can follow progress.

An approver goes to the URL where they can download copies of the files that were attached (read only access, they cannot make changes to the files) and they have buttons to approve/reject and an optional text field where they can leave comments.

When an approver submits, the system checks whether all approvers have submitted feedback. When this is true, an email goes to all approvers and those CC'd to notify them that the approval flow is done and they can see the results. Notice that? We got it down from a ridiculous number like 20 emails down to two. Goodbye flood of emails. And the document trail is not stuck in emails.

Also upon completion, the system generates a PDF and there is a button on the archive page to download the PDF. The system also communicates back to the originating system (we have the unique identifier identifying that system), we pass back the unique identifier for the approval flow and let the system know that the request is complete. The administrator of that system can do whatever it wants with this information.

We now have an approval system that is so general and flexible that it can handle any scenario. It can be linked into any other existing system. We no longer have to build thousands of approval modules for existing systems. We can build it once and connect it into all the existing systems. Or our users can come to a stand-alone tool to use it for any scenario.

Do you have any thoughts to add on approvals? I realize we skipped over a couple of topics. What about allowing approvers to delegate to someone else? Or what about making it so approvers have to approve linearly in a set chain instead of allowing all to approve asynchronously? I chose not to build in these features personally, because it would add a lot more complexity to the user experience for the requester (simple is better) without much benefit in the end. Like I said above, if a requester is not the right person, they can reject the request and the requester can make a new approval request which will go only to the correct approver.

Would you like to see how I built this in Microsoft Office using SharePoint and Microsoft Power Automate? It took me three days to build this, mostly because I was writing a step-by-step tutorial as I was building. Feel free to leave comments below or on LinkedIn or at our other social media channels.

UPDATE: Here is the article where we go through the solution of putting these principals and scenario into a specific set of tools and coding languages. Solution: Creating an Approval System with Power Automate