Executive Summary

In Salesforce the "out of the box" Approval Process functionality will generally address the needs of most solutions in which an approval is required from any/all users configured as approvers when predetermined entry criteria are met on a given record. However, in the scenario where the entry criteria for these approval processes contain many steps and are subject to frequent significant changes, limitations within the standard offering become apparent;

• Updating the configuration for many different Approval Processes can be a very time-consuming process from solution discovery to release, leading to an increased ticket scope and a decrease in capacity for working on other tickets within the team handling the Salesforce Organisation

• End-users may find it difficult to recall which combinations of data are applicable to and are valid for each different Approval Process leading to a loss of efficiency and a reliance on external documentation to find the entry criteria for each Approval Process

Approval Processes also revolve around the idea of a person reviewing a record and making a decision based on the data saved against it. In many cases this is the most sensible method of vetting a record, however, in some situations, data entered against a record may not require additional checks other than that the given fields contain specific values but a paper trail is still required to make clear that at the time of submission the record was in an approvable state. These kinds of scenarios can be thought of as a record being “Pre-Approved”. Using out of the box standard Salesforce Approval Processes these records cannot be automatically approved as a user must manually perform the approval despite the fact that the only checks they would be making are simple cross-checks against a set of pre-approved criteria, a process that introduces potential human error and slowdowns for the user requesting the approval.

Our Approach

As part of the new functionality required by our client, we set about designing a solution that would overcome the mentioned shortcomings. The high-level requirements were:

• To guide users through entering data into a set of dependent picklist fields with each field containing only values which would result in a valid final combination of approval criteria which was either pre-approved or required a manual decision. 

• Be highly scalable

• Provide a quick way of modifying approval criteria

• Grant the capability to automatically approve records matching pre-approved field value combinations

The first step for the development team was to draw up a high-level architecture diagram and corresponding notes on how we would go about delivering the requested functionality. This was achieved in a design session by using a virtual whiteboard collaboration tool which allowed each team member to remotely contribute to the solution design. 

Next, we needed to design out exactly what the solution would look like to the end-user. We noted down what functionality the end-user would need in any given scenario and came up with a mockup for each section of the component based on these notes. These first two stages together gave us a starting point to begin designing out what the backend solution would be as we were able to determine what data would be needed to populate the UI as well as what data we would be providing back from the UI. We were then also able to provide initial screenshots of the UI to the client for initial impressions and feedback.

While awaiting feedback from the client on the UI the team began to break down the architecture diagrams further into smaller pieces with additional technical details which would eventually be turned into workable tickets. The initial broken down technical details for the requirement included the creation of new custom objects to store picklist value combination data, a Lighting Web Component which could be added onto a record page to allow the user to interact with the picklists, various new APEX classes to handle determining whether the combination of data that the user selects can either be pre-approved or requires manual approval.

We also decided to make use of the standard Approval Request approval screen for manual approvers to be able to use a familiar UI by creating a generic Approval Process with disabled criteria which could only be entered via APEX. This allowed us to have much greater control on when the Approval Process should be invoked, which users should be included as Approvers and allowed us to bypass a Salesforce limitation on how many users an Approval Process can have chained after each other. Using a standard Approval Process to handle this also allowed us to make use of the in build Approval History tracking.

During the design process, a concern was raised on how performant using APEX or JavaScript would be at processing the huge amount of data which could potentially be stored within the new custom object into a data structure that can be efficiently parsed into picklist dependencies. To ensure that the solution would be scalable for any amount of data we made the decision to offload the processing of this salesforce record data into a batchable APEX class which can be invoked once all approval criteria have been entered into the custom object. We decided that the most efficient way of storing and processing this data was to generate a JSON data structure which does not require any additional processing by the Lightning Web Component. We debated storing this JSON data structure as a Static Resource but found that the session cashing benefits would be outweighed by the difficulty in retrieving the file when compared to the file being saved as a standard Salesforce File, with another benefit being that the JSON data would be automatically versioned on subsequent invocations.

The final piece of functionality which needed to be added was the ability for a pre-approved record to be automatically approved, while this could be done in the APEX trigger which is invoked by the user submitting the picklists for approval directly, we chose to instead make use of a Platform Event to handle approving the Approval Request. This decision was made to ensure that the Approval History record correctly showed that the approval was given by an  “Automated Process” user rather than the user who submitted the Approval Request.

Outcomes

Once the aforementioned solution was agreed upon by the client we underwent the process of developing, testing and finally releasing it into the production environment.

This solution was then incorporated into the client's main Opportunity sales pipeline and is estimated to generate considerable time savings.