As a follow up to my original post Build Efficient, Performance Optimized Processes, I thought I’d give another example of a scenario where we have a use case that can be solutioned declaratively in three ways (there are more ways, but I’m only going to focus on these three) and will discuss why one of the three is a more efficient, performance optimized solution over the other two.

Here are the takeaways from this blog post:

• Process builder and visual workflows are awesome process automation tools but with such power comes responsibility. Use that responsibility wisely and don’t build processes that aren’t efficient or suck up performance unnecessarily.
• Spend a little more time and effort to come up with a smarter design that gets the job done but is designed with maintenance in mind.

If you’ve worked in Salesforce, you know there are many ways to solution requirements. Often times, we just want to get it done as quickly as possible. But done as quickly as possible does not always lend itself to the best results. Sure, it may meet the requirements in the end, but as someone supporting the system as well, you want to build a design that is sustainable and easily maintained going forward. Let’s take the example of a surgeon. A good surgeon will perform his operation in a way that is least invasive and minimize any future need to open up his patient again, if possible. You want to do the same with your solutions.   

Business Use Case: Addison Dogster is a system administrator at Universal Container. Sally Sunshine is the Sales Manager. Sally would like to automate task creation after an opportunity’s stage is either changed to Prospecting, Qualification, Closed Won or Closed Lost when the Opportunity Record Type is Opp2. The task subject and task creation time criteria may be different based on opportunity stage. Addison is training a junior system administrator, Scott Te, and asked him to come up with declarative solutions to meet the requirements while she also came up with design solutions.

For those who read the prior blog post, this is a similar use case. The only variation here is the wait requirement.  Addison’s design solution will take into account the current design and minimal changes to it to meet the new requirement or refactoring what was built to further improve her prior solution. (We are all about continually improving our solutions!)

Here are a few lessons learned from implementing this revised use case:

• Uses only one record create task flow element to create the task record with different wait times in addition to the appropriate task subject based on the opportunity stage with the same values for the other task fields. Optimized for performance and maintenance in visual workflow.
• Task wait number and unit and task subject can be updated outside of the visual workflow via a custom metadata type for each opportunity stage. Optimized for maintenance.
• Data records associated with a custom metadata type are deployable via a changeset. You can locate the data records by looking for the custom metadata type’s name under the Component list. Do not look for it under Custom Metadata Type.
• Provide descriptions, where provided, in Salesforce. This may be tedious step, I know, but your future self will thank you when you are trying to remember what you configured or assist other/future admins when troubleshooting or enhancing what was built. This includes noting the data stored in a custom field, providing the purpose of a process builder, etc.

Solution: As you know, there are many ways to solution requirements in Salesforce so it’s not surprising that Jeffrey and Addison both came up with two different declarative solutions using the following components:

• Custom Metadata Type, stores the task subject and wait time values in configuration so if it needs to be updated in the future, changes can be made outside of touching the flow.
• Visual workflow, looks up the task subject and wait from the custom metadata type and creates a task.
• Process Builder, to initiate the process when the opportunity stage field is changed to Prospecting, Qualification, Closed Lost or Closed Won for an opportunity record with the record type Opp2. Note: We will not be covering the process builder configuration here but rather visit our previous post: “Build Efficient, Performance Optimized Processes.”
• Add the “Run Flows” system permission to allow users to run visual workflow.  

There are many ways to implement solutions in Salesforce

(Scott’s) Solution #1: Process Builder and Flow

• Overview:
  • The Process Builder executes on the Opportunity object, when it is created or edited. There is only one criteria node: Opportunity Stage field is changed and the Record Type is Opp2. The immediate action is to invoke a flow, passing userId, opportunityId and opportunity stage name to the visual workflow.
  • Visual workflow performs a decision based on the opportunity stage, which then goes to individual wait flow elements, which are configured for each opportunity stage that then creates a task for that opportunity stage.

• Pros:
  • Solution can be implemented quickly to meet the requirements, requires little design. Quick implementation.
• Cons:  
  • Every time a new opportunity stage is added to the mix or task or wait times need to be modified, Scott needs to make an update to the flow and regression test the entire flow to ensure nothing has broken. Can become a maintenance issue.

(Addison’s) Solution #2 [Minor enhancement to solution from the original blog post]: Process Builder, Flow and Custom Metadata Type

• Overview:
  • Custom metadata type created to capture individual fields for each opportunity stage subject and wait number (wait time for all tasks are in days).
  • [Same as Scott Te’s] The Process Builder executes on the Opportunity object, when it is created or edited. There is only one criteria node: Opportunity Stage field is changed and the Record Type is Opp2. The immediate action is to invoke a flow, passing userId, opportunityId and opportunity stage name to the visual workflow.
  • Visual workflow performs a record lookup to the one custom metadata type record to pull the individual opportunity stage task subject and wait number then execute the wait task  (using a formula based on opportunity stage, and lastly, create the task record where the task subject uses a formula based on opportunity stage.

• Pros:
  • Solution has a cleaner flow design as compared to Option #1, where maintenance (updates to the task subject, wait number) is handled in the custom metadata type, outside of flow. Design allows for variable updates outside of flow.
• Cons:  
  • Using a single custom metadata type record that will need to be modified to add or remove individual task subject or wait time. Visual workflow will need to be modified to take into account a new or removed opportunity stage. May cause a maintenance issue later – update to custom metadata type and flow.

(Addison’s) Solution #3: Process Builder, Flow and Custom Metadata Type

• Overview:
  • Custom metadata type created to capture individual fields for each opportunity stage subject, wait number and wait unit. There will be a custom metadata type record for each opportunity stage.
  • [Same as Scott Te’s] The Process Builder executes on the Opportunity object, when it is created or edited. There is only one criteria node: Opportunity Stage field is changed and the Record Type is Opp2. The immediate action is to invoke a flow, passing userId, opportunityId and opportunity stage name to the visual workflow.
  • Visual workflow performs a record lookup to the custom metadata type based on the opportunity stage to pull the task subject, wait number and wait unit, then execute the wait task (using information from the custom metadata type record) and lastly, create the task record (task subject pulled from the opportunity stage’s custom metadata type record).
• Pros:
  • Solution requires more time to come up with a cleaner flow design, where maintenance (updates to the task subject, wait number and unit) is handled in the custom metadata type, outside of flow. Smarter design results in easier maintenance, updates handled in custom metadata type, no impact to flow.
• Cons:  
  • This type of solution takes more time to design upfront. Optimized design takes greater effort/upfront design time.

Will the best design, please stand up?!

Solution #1, built in process builder and flow, is optimized for performance because it did the criteria check once in the process builder and had flow do the rest. However, it is not efficiently built nor is it built with maintenance in mind. As opportunity stages are added and removed or the business changes the information they want to capture in each task creation, the flow will need to be updated and regression tested.

Solution #2 (the original smart solution) while is optimized for performance and is overall a good design, it will not hold up after all in terms of maintainability as the business adds/removes opportunity stages for automated task generation as it will require a change to the custom metadata type and the flow.

Solution #3, while a little bit more complex and takes more time to build, is the SMARTER solution, optimized for performance (only one criteria in process builder) and built with efficiency and maintainability in mind (uses individual custom metadata type records to store the task subject, wait number and unit as opposed to the one CMT record as in solution #2). This is the WINNER.