I have to admit that I am a fan of triggers. Because, with more and more logic being added in, we can use a decent trigger handler framework to keep things in order and can design that with separation of concerns.

However, when we have many workflow rules/flows/process builders, I really find it hard to search for something - which piece has updated my field, how can I find it.

So I am curious about one question. When we have introduced a number of workflow rules/flows/process builders, how can we design them and make them easy to maintain?

2 Answers 2


First of all, this is an excellent question and I am writing best as per my opinion which can vary with others.


  1. When to do what and what can be supported over other.

Process builder works good in following scenarios.

  • Create a record of any object type
  • Update any related record—not just the record or its parent
  • Use a quick action to create a record, update a record, or log a call
  • Invoke a process from another process
  • Launch a flow—you can’t schedule this action with workflow
  • Send an email
  • Post to Chatter
  • Submit a record for approval

Where as both process builder and flows do not support Outbound messaging, here workflow is advantageous.

Here, if the same type of actions lets say, create a task, field update, send a email can be perform both by process builder or workflow, then stick to either workflow or process builder, Do not mix it here.

  • Null checking logic in process builder throws error message so, here workflow is advantageous.

  • Process builder/flow debugging mechanism cumbersome, here workflow is advantageous.

  • Regarding flow, if you have simple UI then rather than using Visualforce you can use Flow. Through flow handles process logic just like apex but, apex is more optimized than flows. I usually prefer apex, though using flows, we don't need to write test classes (so less components in the org).

  1. Order of execution

Flow and Process builder's process executes after workflow action and here you need to check the sequence of logic how you want to perform either in workflow or in process.

  1. Mode of execution (System mode vs. User mode).

Workflow rule and Process builder executes in system mode, where as flow works in user mode.

Visualflow - User, but -

  • if flow is called from Process Builder - System mode
  • if flow is called from Workflow - System mode
  • if flow is called from Apex - (depends on with or w/o sharing of apex class)
  • if flow is called from Custom Button - System mode
  • if flow is embed in Visualforce - Depends on VFP context
  • if flow is called from REST API - System mode

Refer this answer Types of execution - System mode or User Mode?

  1. Versioning

Workflow always takes most recent version where as flows and process builder we can manage versioning.

  1. Transaction and Large data volume

I have faced issues when we have large number of process builders, workflow and flows then we received Apex CPU Limit exceeded errors for large amount of data processing in a transaction. So, in that situation, we have put most of the logic in apex classes rather than process builders.

  1. Data migration for Large data volume and component deactivation.

Normally, for bulk data load, we need to deactivate process builder and workflows and preprocess the data outside of Salesforce and migrate the data.

Again, think about automatic bulk data updates how those can be handled.

So, basically above points can help you what will be best suited according to your need.

  • I don't think the question is when to use PB vs triggers. The question is how to maintain multiple Processes, logging them, making them readable, etc. Commented Jan 17, 2018 at 19:39
  • I have understood the question correctly, very first place why should we create them, secondly, if it has been created then how could that be refactor them (some of the things can be redundant and better to eliminate those). Thirdly, if those to be maintained properly, it should have best possible design considering all above points. These kind of messy things only happens when there is a lack of good designer in the project. Hope it makes sense! Commented Jan 17, 2018 at 20:06
  • That was not what I was hoping for, but the answer I expected on the topic. A certain size of Org just needs someone able to at least maintain code/Triggers. Salesforce just ignores that fact and their consultants/architects keep proposing flow based solutions. Luckily they're not on the project anymore, when integrations hit the fan. Show me one admin, that talks about maintainability of flows after merging a few dozens of them.
    – Schnaps
    Commented Mar 11, 2019 at 14:51

Some additional info about Process Builder:

  1. Process Builder uses SOQL queries which can push you over the SOQL query limit as opposed to Workflows which do NOT contribute to SOQL query limit.
  2. Process Builder does not play nicely with duplicate checking. If Process Builder is inserting or updating a record that does not meet duplicate rules, it will fail. So, we avoid using Process Builder on objects that have duplicate checking implemented.

We have a mix of Business Analysts (who primarily use workflows and Process Builder) and Developers (who do coding). As a general guideline, we put logic in the simplest mechanism available, so that the most people possible can maintain it. This means we try to use workflows when possible, then step up to Process Builder if the logic requires some action that is beyond the workflow capabilities. We only use Triggers for the most complex logic.

Another consideration, we always try to keep the logic for a particular function together in one place. We avoid having logic spread out across multiple different mechanisms as this makes maintenance even harder.

  • I don't think the question is when to use PB vs triggers. The question is how to maintain multiple Processes, logging them, making them readable, etc. Commented Jan 17, 2018 at 19:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .