I was looking everywhere for a fresh perspective on Salesforce approval processes… and it was nowhere to be found.
Approval Processes are a feature set in Salesforce that may be outgrowing their usefulness. On my project, we had been dealing with some of their downsides for years, but it wasn’t until we changed internal processes that we decided to kick Approval Processes to the curb… and replace them with custom automation built in Flow.
Approval Processes pain points
Let’s discuss some Approval Process downsides:
- We had major issues with records “locking” during an Approval Process. I can see why the feature was built this way (to prevent edits while a record is being evaluated for approval), but in our work process, some fields were being finalized and needed to be edited while approvals were pending. Moreover, some approvals took a very long time to be processed, leaving the record locked for days or weeks on end. There are ways to “unlock” records, but it’s just another thing to manage when it has no benefit for us.
- Reporting is a nightmare. While you can report specifically on the records generated in the Approval Process itself, it is difficult to bring data from the record being approved into a report, a view, or a page. We know that we could create Custom Report Types for this, but that would mean we need different report types for every object that has active Approval Processes. We still can’t show staff a list of All Pending Approvals (WITH relevant context) without using custom code.
- Related to above, User Experience was also a nightmare. We needed more flexibility with how and when records are “submitted for approval,” and what reviewers see when they go to approve something.
- It is not easy to design extra automation based on an Approval Process (especially if you want to reference Approval Process Comments) because of the AP data model. With OOTB functionality, the person who submitted the record for approval never receives a notification about the approval decision, unless you build it out to do so. However, unless you use helper fields, it’s difficult to design useful notifications that fire from “Process Instance” records.
- Once an Approval Process is “active”, you cannot revise the Approval Steps unless you “clone” it (link)
- Taking one whole chunk of automation (approving… and the routing, field updates, email alerts, record creation, and everything else that happens) and putting it in Approval Processes instead of Flow makes debugging more difficult when there are inevitable issues. It’s harder to answer the question, “I want to change how this automation works. Now, where IS this automation?” This is a carryover from when Salesforce used to have Workflow Rules/Big Deal Alerts/Approval Processes as the only types of declarative automation. Now, they are quickly becoming obsolete.
The issues above were small enough that we were ok with “living with them.” Though now that I type them out, it’s clear to me that we were making too many big compromises and we probably should have made the switch sooner. However, when the new issue arose (below), I knew it was time to cut our losses and start over.
- Approval Process ‘routing’ (not technical term) from one reviewer to another was not “smart” enough for us. We have two layers of reviews, UNLESS the person submitting is themself a reviewer, in which case, we only need one layer of reviewers. There was not an obvious way to prevent people from approving their own records, or the same person approving the same record twice, which is obviously silly and annoying.
what I built
These are all of the “components” of the Approval Process Replacement. Ha, now that I look at it, the table below is reminiscent of a change set. If you build something similar, you can use a list like this as a guide.
| Type | Name | Purpose | |
| 1 | Custom Field (picklist) | Review Status | Where is the record in the approval process? Default is “Draft.” |
| 2 | Screen Flow | Submit for Review | Displays text with instructions, and Screen Flow allows staff input (comments) which the Reviewer will be able to see later. |
| 3 | Button | Submit for Review | When the Submitter pushes the button, a screen pops up and shows the “Submit for Review” flow. When Submitted, Review Status field is updated to “Pending Reviewer 1” or “Pending Reviewer 2” depending on logic. Added button to Lighting Record Page. Button is conditional based on the Review Status, so you cannot see it if a record is already “pending review” or “approved.” |
| 4 | Screen Flow | Approve or Revise | Displays text with instructions. Screen Flow allows Reviewer input (comments). Screen Flow also updates Field and cues automation. Embedded this Screen Flow in Lightning Record Page. It is conditionally viewable if a record is “pending review.” |
| 5 | Record Triggered Flow (after save) | Notify staff | Sends Chatter notifications based on the Current and Prior value of “Review Status.” |
| 6 | Dashboard | Review Dashboard | Shows the status of all records pending Review. |
| 7 | Field History Tracking | Turned on Field History Tracking for Review Status, and various custom fields where comments are stored. Added Single Related List to Lighting Record Page to display field history for selected fields. This is also useful as an audit trail, which is one of the (few) benefits of formal Approval Processes. | |
| 8 | Documentation | How to Submit a Record for Review and Review Pending Approvals | Added article to manual. |
| 9 | Staff training | How to Submit a Record for Review and Review Pending Approvals | Held hands-on training with senior staff after pilot phase of roll out. |
deeper dive on flows
As you saw above, this solution required 2-3 different “Flows” to reproduce similar functionality to the old Approval Process. I’m going to break down the Flow design below, including HOW and WHY to use Flows to meet these objectives.
flow 1: submit for review
We wanted to mimic the “Submit for Approval” button that comes from Salesforce, but we also wanted to change the name of the button, the design of the pop-up screen, and the automation that happens when a colleague pushes the “Submit for Review” button. So basically… change everything.
If you used “entry criteria,” and/or multiple APs for different “types” of records, this is also where you would keep that logic.
The blue “Screen” elements are where the magic happens. In these two screens, the Submitter is prompted to write brief comments. The screens are different depending on the type of Submitter, which is handled with logic that is a bit too much minutiae to type here. Most importantly, they have buttons on the screen that lead to different automations. You’ll learn more about this in the next section.
Next, you “distribute” the Flow by using a Custom Button. Here is what mine looks like. Don’t forget to add the button to the page layout or the Lighting Record Page!
flow 2: Approve or Revise
Here is a screenshot of the component Reviewers see on the Lighting Record Page. It’s pretty simple for them. All they need to do is write comments and then click a handy button. We made the buttons friendlier than the standard version. Instead of “rejecting,” the reviewer has the option to request revisions.
To create a screenflow like this, you need to pull in the appropriate record. Then, you can design a Screen element with any info that you want to show. This can include instructions, data fields, images, etc. The most important part is to add the Flow Button Bar component to the Screen element. (This must be installed separately, but it is free!). You can give the buttons any name you want, just make sure that you keep track of the names, because you will use them later to configure automation that happens when each button is pushed.
flow 3: notifications
The last major step of the rebuild was to create a notification engine. I moved these to a Record Triggered Flow based on the automation conventions in my org, but you could also put notifications in your “approve or revise” flow. We did our notifications in Chatter, but you could do them with email alerts, scheduled reports, Slack messages, or any other method that works in your org’s culture.
Since this type of automation is not unique to the buildout for modified approval processes, I’m not going to into detail here. Leave me a comment if you would like to learn more about the notification methods that I built! TL;DR: I used the updated field value in Review Status to launch a series of Chatter notifications which tag appropriate colleagues at each Review step.
additional steps: page layout considerations
Implementing this approach to approvals will require a little bit of surgery on the Lighting Record Page. Make sure you don’t forget to:
- Add Submit for Review button to “actions” section. I suggest making this conditionally viewable only if the Review Status is in a submittable state.
- Create a tab for Reviews (if you are using tab or accordion components already)
- Add Screen Flow component and select “Approve or Revise” flow. I suggest making this conditionally viewable only if the Review Status field is in a reviewable state.
- (optional) On Object>Fields and Relationships, open Field History Tracking and check off Review Status field and any other fields that you want to capture for historical/auditing purposes
- (optional) Add Related List-Single component to the Review History tab
My organization is delighted with this new build because it’s prettier and more custom. As an Admin, I’m delighted too! I got to brush off some dusty Flow skills, tear out some technical debt, and make a cumbersome process streamlined and easy to maintain over time. I enjoyed the challenge of building this from beginning to end, not doing it piecemeal or haphazardly. It’s always a good idea to release documentation at the same time as the feature and I’ve fallen out of that habit. This was a good reminder to see how rewarding and fulfilling it is to “wrap everything up with a bow.”
There is a lot of conversation in philanthropy orgs about the best ways to build custom processes in Salesforce. I don’t think there is “one right answer” here, but I hope that posts like this can contribute to the dialogue. I’d love to hear from you if this sparks any ideas for you, or if you’ve come up with different workarounds! Don’t be a stranger, I read every comment. And yes, WordPress makes me “approve” them!