Architecting for Success
One of the most frequently overlooked areas of automation in Salesforce tends to be Approvals. This begs the question, why? They are easy to create and conform nicely to the processes within the organization…or do they?
Before implementing an approval process in Salesforce, it is critical that you refine the process slated for automation to determine exactly what is needed. You may be surprised to learn that what is being requested is masking the real need.
Evaluate the Process in two steps
Step one: Evaluate the approval processes. At times you will find the scenario where a user says, “I need to approve anything matching these specific criteria.” What is the worst that could happen with that type of request? Well, for starters, if that approver is unavailable for a period of time or forgets to respond to the approval request your record will be stuck in a queue and could stop a work stream from continuing, causing a bottleneck.
If you are working with a company with existing approval processes in place with this type of rule, run a report to see if there have been any rejections where the criteria were met. The next question should be “in which scenarios would you reject the request when it meets these criteria?” If there have been no rejections, or if the response is something like “oh, I just need to know that it’s happening”, it may not necessarily need an approval.
Step two: Check the use case. Do you need someone to verify that they have seen it before it can move to the next step for compliance purposes? If so, then an Approval makes sense here. Is it to accept ownership of a record? Again, an Approval makes sense here since the user is essentially signing off that they accept the record as opposed to simply having the record ownership transferred to them. But if it is purely an “I need to know that it’s happening even if I don’t do anything with it” type of request you should consider an email alert if the occurrence is low or a report if the occurrence is frequent.
There are other process-based questions that can be addressed and enhanced using workflow automation as well, such as the “siloed spreadsheets” or “gut feeling” approvals but let us discuss those another time.
Evaluate the Workflow
To evaluate the workflow being requested, ask yourself these four questions for every step in the process.
Are approvals required?
Do the approvers all have Access to Salesforce for more than just approving a record?
Is data across multiple objects or records needed for the approval?
Is data needed from other systems for the approval?
Generally, if the answer to the first question here is ‘yes’, an Admin can start creating an Approval Process in Salesforce. For most small business scenarios that is great! No additional code is needed! But what if we start looking at some of the other questions? If all of the approvers don’t have access to Salesforce there are 2 options to complete this step. Option 1: Purchase a license for all the approvers. Option 2: Evaluate whether Salesforce Approvals is the correct solution, or if you need to integrate with a different approval engine which typically only applies to larger organizations.
What if all the approvers have access to Salesforce, but data is needed from multiple records or multiple objects to route to implement the correct approval process? This gets a little trickier, and I have seen three primary methods used to accomplish this.
First, have a large table with different fields and lookups used to build the approvals logic and have processes and flows update the object so that the correct approvals fire. This allows you to use the declarative model from Salesforce, but can lead to limits being exceeded on both model (such as the number of lookups or fields per object) and governor limits as well as performance issues as your processes increase in complexity.
Second, use fields on the object to track decision points and use Flow and Process together to update the record before submitting it to the appropriate approval process. This solution is less complex than the first approach but has the drawback that the elements that are used to make the necessary approvals are stored on the record itself. And just like the first approach, this approach has increased risks to limits being exceeded and performance being impacted.
Third, use Apex to query the records and submit to the appropriate approval. This has the overhead costs of using code instead of configuration, but it avoids storing data and overly complex configurations.
If data is needed from another system, you have a couple of options available. First, you could have the external data replicated in some manner in Salesforce either through a direct API call to update records from the other system(s) or use Platform Events to update the records as changes are made in the other system(s). Alternatively, you can use Apex to call a service that the other system(s) have exposed to get the data needed to run the appropriate approval.
But what do you do if you need data from both Salesforce and other systems, and if not all the approvers are in Salesforce? The key to solutioning this requirement is in the users: not all users are in Salesforce. So, unless you are willing to purchase the additional licenses, you may want to consider using a combination of an external approval engine and Salesforce approvals. One of the more innovative solutions that I’ve seen recently to address this very requirement used the Salesforce Streaming API to update key tables used for decision making in the approvals solution, and to indicate when a record needed to go through approvals. It used the Salesforce Approvals to lock the records from editing with a generic approval process, and then used a Camunda-driven workflow for the approvals process using data from Salesforce and other systems to determine the correct process to follow, and then used the Salesforce REST API to approve or reject the record.
Plan for Success
As we have discussed here today, there are several patterns that can be used for architecting your approvals processes for success. We did not go into the best practices around Approvals in Salesforce, but do not worry, there are plenty to go over and we will take the time to do so.
Carefully consider the needs of the users, not just the requests; and take the time to weigh your options before you begin building. It is easier to change the color of the paint once the walls are up in a house than to change the dimensions of the room. Likewise, it is easier to make minor adjustments to the approvals automation if it is designed correctly from its foundation rather than having to rewrite it entirely because of an oversight.
About the Author
Dan Curry serves as our Director of Global CRM Delivery and Architecture with over 14 years’ experience in creating specialized clients solutions in process automation, data-driven application design, and team dynamics. He holds multiple Salesforce and industry specific certifications. Outside of his professional life, Dan spends time with his family, is an active minister in his local church, and practices Gadi Kempojitsu and Krav Maga where he is both an instructor and mentor.
Director, Global CRM Delivery and Architecture
St. Louis, Mo