Salesforce Automation: Understanding the Automation Pyramid

Updated: 4 days ago

Seasoned Salesforce developers, admins, and architects are frequently asked questions about Salesforce capabilities: “can Salesforce do …”. Typically, the answer is “yes”, but what is more important than “can it” is determining the best approach to achieve the desired outcome.


The paradigm that I work by and try to encourage newer developers to follow is this: “Why make it code when it can be configuration? Why make it Configuration when it can be Data-driven? Why make it Data-driven when it’s included in the platform already?” This line of thought follows the Salesforce Automation Pyramid.


Abraham Maslow said, “if the only tool that you have is a hammer, everything will be treated like a nail.” The same thought holds true for Salesforce developers. Those that align to programmatic side of the platform, will start with that for their solutions. Developers who align more to the declarative side, tend to stay as far away from coding a solution as possible. This poses the question can there be a balance?


A common question I have seen asked when interviewing developers is: “your stakeholders want Salesforce to automatically update the owner of all Contacts and Open Opportunities so that they are owned by the new Account owner whenever the Account’s Owner is changed. Tell me how to solution this?”


Responses tend to be grouped into two different groupings. Someone that is accustomed to writing code for their solutions will instantly begin talking about the way that they will write the apex trigger to solve for this. Another developer that is used to the more declarative side of Salesforce development will stick firmly with a solution using Lightning Flow’s Process Builder. This begs the question “why make it code when it can be configuration?”


A large proportion of developers, while both solutions are viable, only go with the custom solution. In fact, I have only had a couple of candidates over the past decade of interviewing that have answered this question correctly: “Salesforce does that already.” According to the Salesforce documentation there are actually several Out of the Box objects that have special handling when their ownership is changed, and this is one scenario that is covered.



So how do I know which one to use?


With all the options available, how do we select which automation to use? I would start by reading the rest of this article. Then I would recommend that you take a look at Trailhead.


Ask the right questions


Existing Functionality


First, determine if there is something that exists from Salesforce already, or if there is something that already exists that can meet the need.


  • Is there a standard object that does what is being asked for?

  • Is there standard functionality that does that is being asked for?

  • Is there a Salesforce Cloud that does what is being asked for?

  • Is there an Appexchange Package that does what is being asked for?


Salesforce has spent a lot of time, money, and resources into building out the core parts of the platform so that it can accomplish most tasks for most businesses while still allowing customers the flexibility to customize their implementation to fit their specific needs. Lead routing and conversion logic for Sales and Marketing, Case routing and omni-channel support for Service, Customer Communities for self-service, security features and the ability to share records as needed…Salesforce has put it all into their platform.


And for things that might be a little more than their core platform, they have a “cloud” for that. There are a sets of Salesforce products that can be sold together to do everything from creating a 360° view of your customers to providing industry-specific solutions.


And if Salesforce hasn’t built it, look on the Appexchange: Salesforce’s community marketplace! There are many companies that have built products to solve even more types of problems, and those can generally be installed into your Salesforce implementation with a few quick steps.


Next, look at the process diagram for what is being asked for, and consider the steps along with the Salesforce Order of Execution.


  • Is input needed from the user to start the transaction?

  • Is the automation being used to manage records?

  • Are updates being made to records other than those in the transaction?

  • Are you trying to validate data before a record can be saved?

  • Are you notifying someone that something has been or needs to be done?

  • Are multiple systems involved?

  • Is an approval required?

  • Is the expectation that the automation happens in the same transaction, later, or at a specific time or interval?

  • What existing automation approaches do I currently have in my Salesforce implementation?


If users are going to be required to provide input to drive the automation, consider using a Flow.


If the automation going to update records, consider the records being updated. Is it for the existing record, or other records? If it is updating the same record, do the updates need to go through any validation rules or should they avoid them? Do you have any other updates happening in the same context (before or after the update)? You may consider using either a Flow, Process, or a Trigger for that. Are you updating related records? You might consider either a Flow, Process, or Trigger. The main thing to consider when updating records other than the one that caused the automation is that querying the record to update and updating the records via Flow and Process will count toward your governor limits, so complex updates might warrant a Trigger or at least invocable Apex to make sure that your automation is designed to handle large numbers of records.


If you are updating external systems, consider the capabilities of the other systems as well. You would not want to create a Push Topic or Platform Event to stream the changes if the system that needs to know about the change does not have the capability of using the streaming API from Salesforce. Likewise, you want to avoid writing single-use code whenever possible.


Do you want to schedule an activity for a later time, or to be run at a specific time? Process Builder and Flow both have the ability to schedule activities based on a specific date or time interval, but if you want something to be executed at a specific time and day (such as a process that runs every Saturday at midnight to deactivate users that have not logged in in 14 days) you will need to use scheduled Apex.


And what about Approvals? Well, that can be easy or complicated depending on how complex your approvals processes are. There is a lot to say on approvals, and it is worth taking the time to say at another time.


Take time to plan


There was an Italian author in the 1500s that wrote that a foundation can be redone after the building has been built, but it will come at great cost and danger to the architect. Without a solid foundation, whichever approaches that you take to automating your processes will come with a greater risk of technical debt for the future. This may present itself as decreased performance for your users, hidden defects, and unexpected behaviors, or even ‘outage’ causing defects in Production. Take the time to understand the processes that you are working with, and to carefully select the right tool for the right job.


Measure twice and cut once. And please, do not use the sledgehammer to hang the portrait on the wall.


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.


Daniel Curry

Director, Global CRM Delivery and Architecture

daniel.curry@onissolutions.com

St. Louis, MO

44 views