How To

Build Efficient, Performance Optimized Processes

Teamwork works together to build a gear system

People who work in Salesforce know, most often, there are different ways to build something within Salesforce. However, the solution chosen may not always be the best solution. I think coming up with a solution that is optimal comes with experience. Whether you are an intermediate admin looking to kick your business logic skills up a notch or a developer looking for a more efficient, easily maintainable way to implement common business logic declaratively, this blog’s for you.

By all means, I’m not an expert, but I’ve found that the more time I spend configuring processes using process builder and visual workflow, the more I’ve learn and the more advanced I’ve gotten with my declarative techniques. If you take a look at my solutions a year ago versus today, I think you will see vast improvements in my declarative solutions over time.

Salesforce has provided great declarative tools to automate processes with process builder and visual workflow (and they continue to enhance them. Thank you, Salesforce.) so we can move more and more towards declarative solutions versus custom code. Just as developers should adhere to best practices for apex development to built efficient, performance optimal code, system administrators or platform app builders should consider building efficient, performance optimized processes.

In this blog post, I will cover 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 more time upfront to analyze and document the process. #StartOffRight
  • Spend a little more time and effort to make your process solution SMART or (insert Steve Molis’ Bostonian accent here) wicked SMART with maintenance in mind.

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. Addison is training a junior system administrator, Scott Te, and asked him to come up with declarative solutions to meet the requirements.

Solution:

Perform Analysis and Document the Process. #StartOffRight

Scott and Addison spent some time understanding the business process and analyzing the requirements with Sally. They learned from her that her sales reps were manually creating reminder tasks for themselves for opportunities with the Opp2 record type but only for certain opp stages. In reviewing the information for the opportunity tasks created, Addison noticed that the information is essentially the same in regards to field values except the task subject being the distinction based on opportunity stage.

OppVisio.JPG

Scott Te and Addison came up with the three declarative solutions* to meet the business requirements for Addison to review. While none of the below solutions are wrong, one of the solutions below was built with maintainability and performance in mind.

*Note: I purposely did not include the routine flow element to send the fault email to production support (a best practice noted in all my  visual workflow How To’s) so that all three declarative solutions are exactly the same.

Let’s review each solution and discuss pros/cons of each

(Scott’s) Solution #1: Process Builder only

  • Overview: The requirements are met with process builder on the Opportunity object, when it is created or edited. There are 4 criteria nodes where the Record Type is Opp2, the Opportunity Stage field is changed and the Opportunity Stage is either Prospecting, Qualification, Closed Won or Closed Lost. There is an immediate action to create a task record with subject “Follow up on opp stage: <opportunity stage name>” and the same values for the other task fields.
  • Pros:
    • Uses only one component.
    • This is a fairly simple configured process builder.
  • Cons:  
    • Every time an opportunity record is created or edited, Salesforce will evaluate all 4 criteria to determine whether to take action, even if the opportunity is not the Opp2 record type. Not optimized for performance.

The immediate action of creating the task with basically the same information (except for the task subject) is replicated 4 times. If the task field requirements change in the future (same field(s) across all 4), this would require edits to four individual create task immediate actions. Can become a maintenance issue.

ProcessBuilderWithManyNodes.JPG

(Scott’s) Solution #2: Process Builder Invoking a Visual Workflow

  • Overview: The requirements are met with process builder and visual workflow.
    • 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 field. It then creates a task record with the subject “Follow up on opp stage: <opportunity stage name>” and the same values for the other task fields
  • Pros:
    • Uses only one criteria node in process builder that evaluates whether the record type is Opp2 and the opportunity stage field is changed to then push the heavy lifting in flow. Optimized for performance in process builder.
  • Cons:  
    • The 4 individual Task record create flow element has basically the same information (except for the task subject). If the task field requirements change in the future (same field(s) across all 4), this would require edits to four create task flow elements. Can become a maintenance issue.
    • Uses visual workflow, which would require intermediate admin/developer skills.

ProcessBuilderWithOneNodeMultipleElements.JPG

VisualWorkflow-GenerateaTaskNoWaitAlternateSolution.JPG

(Addison’s) Solution #3: Process Builder Invoking a Visual Workflow, Referencing Custom MetaData Type

  • Overview: The requirements are met with process builder invoking visual workflow and visual workflow referencing custom metadata type.
    • 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 looks up the custom metadata type containing the task subject based on the opportunity stage and then creates a task record with the subject “Follow up on opp stage: <opportunity stage name>” and the same values for the other task fields.
  • Pros:
    • Uses only one criteria node in process builder that evaluates whether the record type is Opp2 and the opportunity stage field is changed to then push the heavy lifting in flow. Optimized for performance in process builder.
    • Uses only one record create flow element to create the task record. Using a formula, the flow pulled in the appropriate task subject based on the opportunity stage and the same values for the other task fields. If updates are needed to the task field (same field(s) across all 4 opportunity stages), it is maintained in the one flow element. Optimized for performance and maintenance in visual workflow.
    • Task subject can be updated outside of the visual workflow via the custom metadata type. Optimized for maintenance.
  • Cons:  
    • Uses visual workflow, which would require intermediate admin/developer skills.

ProcessBuilderWithOneNode-NoWait.JPG

VisualWorkflow-GenerateaTask-NoWait.JPG

CustomMetadataType-Task.JPG

Will the best solution please stand up…

Solution #1, which was built solely in process builder, was not efficient or optimized for performance as each new or updated opportunity record will need to go through and evaluate 4 criteria every single time. Updates to the task is replicated 4 times.

While Scott’s second solution (Solution #2) was more along the lines of optimizing the process for performance because it did the criteria check once in the process builder and had flow do the rest, it may cause a maintenance issue down the road if more stages were added or more task fields were added/updated.

Solution #3, while more complex and took more time to build, is the the SMARTER solution, optimized for performance (only one criteria in process builder) and built with efficiency and maintainability in mind (uses custom metadata type to store the task subject and a formula to determine which task subject to use in the one record create flow element). This is the WINNER.

Advertisements