Attention Salesforce Admins! Check out this Salesforce Automation Guide

Share this article...

We all know that Salesforce offers different tools for automating business processes. As a flexible and scalable CRM platform, it means that Admins are often given multiple options in Salesforce for achieving the same thing, which often leaves us asking: ‘which automation should I use, and when?’

Introducing the Salesforce Automation Guide – a handy page you should all bookmark. Michael Schmidt-Korth, a Senior Technical Architect at Salesforce, has compiled everything you need to know into one place, including limits, and that all-important ‘future-proofness’. Here are some important Admin questions you can answer with this free, self-service resource.

Salesforce Automation Best Practices: for Flow, Process Builder, Workflow, and Apex

When it comes to automation, there’s a lot to learn in terms of best practice. Michael has a skill for writing one-liners that you can learn as rules of thumb:

“Use the simplest tool for your use case – but consider likely future requirements: Process Builder first, then Flows, then Apex (tool of last resort)”

Not only should you learn best practice for each automation option, but evaluate when to use one tools versus another. For example, learning how to use Salesforce flow correctly is important, but learning when to look to Apex for the solution is just as important:

“Do not be deceived by ‘endless possibilities’ and avoid creating too complex flows”

How to Trigger a Flow, Process Builder, Workflow, or Apex?

The ‘functionality’ tab opens up to a double comparison table, which compares the actions, triggers, record access, flow control, and distribution of all 4 Salesforce automation features.

For triggers, specifically, Michael gives us suitable workarounds for the more declarative features, too.


Scalability is “how extensible the approaches are in regards to future requirements and feature requests

Workflows vs. Process Builder

You may have wondered, ’should I be using workflows or Process Builder?’ Certainly, in terms of scalability, you should look to Process Builder, where you can add additional branches for complex logic, whereas with workflows, you will be limited to one condition (and multiple workflows per object, as a result).

Availability: Why Can’t I Use Apex?

That is determined by the edition of Salesforce you’re using! If you are a Professional Edition customer, you won’t have complete access to Salesforce’s full automation features. If you upgrade to Enterprise Edition, then you will be able to leverage Apex (Workflow rules, and as many Process Builders as you wish!)

Check out the ‘Availability’ tab to see the whole overview.

Why is Future-proofness Important?

Future-proofness is a neat way to say ‘will this feature stick around for the long-term?’ The last thing you will want to do is to build out lots of automation using an automation feature that is slowly phasing out, and won’t receive any improvements!

Luckily, Michael keeps us informed on the Salesforce Life Cycle (whether a product is constantly being updated in each release) and whether that typically requires Admin action.

What are the Per-org and Per-Transaction Limits?

How many active flows and total flows per flow type you are allowed? Which automation features contribute to CPU limits? The maximum criteria nodes and scheduled actions in Process Builder?

Check out the ‘Limits’ tab for the in-depth overview. This section, in particular, is very comprehensive!

A Note From the Guy Himself!

“The tools and options for automating Salesforce keep getting more refined with each release, but it is certainly not easy keeping up with the changes. The line between admin and developer tools gets blurrier as well – which can be a good think, but also daunting. Choice is great but it is important to understand when to take which path. If you start plastering your walls with screenshots of your flow, you’re certainly on the wrong path!”

-Michael Schmidt-Korth, Senior Technical Architect at Salesforce 

Bonus: Interactive Automation Spider Diagram

Have a play with the spider diagram on the ‘General’ tab. This diagram plots the factors in one place, and make for interesting exploration:

A note of thanks 

I would like to thank Michael for compiling this information. The topic of Salesforce automation feature can often be challenging to learn and keep up to date with. So, thank you! Connect with Michael here.

6 thoughts on “Attention Salesforce Admins! Check out this Salesforce Automation Guide

  1. I think this already needs to be updated. Summer 20 changed Flow so significantly that we can stop using Process Builder. From what I understand, Process Builder is going away at some point. As most of us know, Process Builder is simply making Flows anyway. Now that you can start a Flow by Platform Events or Record Changes, there’s no need to use Process Builder. You can build everything in Flow instead and simplify everything.

    1. Michael Schmidt-Korth


      Hi Matthew – you are right, Processes are Flows with a simpler GUI. I can’t comment on the roadmap, but Flows are receiving great attention, so everyone may be their own judge on that. Flows are definitely future-proof. I can only recommend the TrailheaDX session to see where we’re headed. It is also important to consider the available skills – Processes still have a lower bar when it comes to required skills, they are more accessible – but that’s changing already. Flows do require more strict guidelines and adhering to best practices to avoid becoming maintenance disasters. If your team has the skillset, go with Flows – they are more extensible, more feature-rich, more future-proof, have better performance, error paths and allow for far better flow control in general.

      And thanks for the reminder, I’ll update this section soon.

  2. I’m working in an org that uses Process Builder and Flows to an extent that only one opportunity edit can happen at a time, updating or importing two or more gives a too many SOQL statements error. Trying to figure out what is going on and eating the resources is impossible, there are about 400 arrows in the flows (including many loops).
    This is not maintainable.
    There are no built in tests to see if it’s working right.
    So I wonder why Apex has a low maintainability score. I’m finding the exact opposite.
    To me a better rule would be to use Workflow, Flow, Process Builder, Apex in the order of mounting complexity of the problem being solved. The simplest tool is not the best tool for a very complex problem. You can build complex wooden legs for a chair with a chisel and file, but I’d rather use a lathe (if I knew how!)

    1. Michael Schmidt-Korth


      Hi Jochen – I can relate. Maintenance for flows is OK, but only if you keep them limited to a reasonable complexity. What often happens is that simple flows are implemented, and they grow over time as people want to avoid moving to Apex. This not only makes such flows unmaintainable but also prone to fail due to governor limits, as you mentioned. The fact that flows have very limited testing capabilities makes this even more dangerous. Typical examples are implementations that grow drastically over time and/or have not been architected properly, as future requirements were unclear. Or there was simply a lack of appropriate skills.

      Some of the reasons that the Apex maintainability score is low are:
      1. You need to keep track of API versions used and ideally keep them close to the latest release; if not, changing from one API version to another requires you to investigate the impact of API changes in-between (declarative tools are always on the latest release)
      2. In complex Apex-heavy orgs the dependencies and side-effects can be very challenging to evaluate, making any change potentially cause unexpected actions if you haven’t performed a proper impact analysis beforehand
      3. While non-code tools have a certain limit to what they can do, the limits using Apex are much higher, again increasing complexity of code and potential effects. It is also much more dependent on the type of each developer (their coding style etc.). The impact of Apex developers leaving is higher than e.g Flow developers leaving due to their knowledge they take with them if not documented properly
      4. Apex requires strict coding guidelines and code reviews, especially in diverse and large development teams
      5. Apex requires test classes to be updated (which is a good thing, but still effort you don’t really have when using e.g. Flows)
      6. All changes require deployment (again, a good thing)
      7. No built-in versioning

  3. Michael Schmidt-Korth


    Hi Lucy, a colleague mentioned your blog post – thanks a lot for linking my content and providing this overview! The tools and options for automating Salesforce keep getting more refined with each release, but it is certainly not easy keeping up with the changes. The line between admin and developer tools gets blurrier as well – which can be a good think, but also daunting. Choice is great but it is important to understand when to take which path. If you start plastering your walls with screenshots of your flow, you’re certainly on the wrong path 🙂

    1. Thanks Michael, I will add your thoughts as a quote in the post too. Such a wonderful resource to share with us all, and will educate many, many people I am sure.

Add Comment