Workflow versus Process Builder. How to choose which to use?

Question

Is there ever a reason (aside from Outbound Messages) to use Workflow instead of Process Builder? Specifically a side-by-side comparison of how well each performs for single-condition field updates, for email alerts or for task creation.

This is not a question about differences (that's well documented) but whether there is any advantage to using Workflow at all.

Are there known obstacles that only exist in one but not the other that would help people decide when to use one or the other? Could be aspects like:

• Resource Consumption
• Time-based Behavior
• Edge case options (e.g.selection of recipients for email)
• Deployment considerations

Answer 1

Last I checked, Workflow performs significantly better on CPU Time. That on its own is a compelling argument to reverse your assumption. Instead ask yourself why you would use Process Builder when you can instead use Workflow.

Setup:

• Custom Object: Object_With_Workflow__c
  • Set up a Workflow Rule
    • Evaluate the rule when a record is created, and every time it's edited
    • Set the criteria to a formula: True
    • Add a field update to set the Name field to "Woo Profiling!"
• Custom Object: Object_With_PB__c
  • Set up a Process Builder flow
    • Start the process when a record is created or edited
    • Add a criteria node also evaluated on a True formula
    • Add an action to Update Records. Select the record that started the process. Set the Name field to Woo Profiling!

When I profiled each object with the field updates inactive, it took 180ms and 161ms respectively to insert 100 records. Then, with the field updates activated, the same exact save took 382ms and 1,861ms respectively.

Let us assume the average save takes 170 ms and there is a bit of noise in the measurements. That would mean the Workflow Field Update adds ~180ms to the save, while the Process Builder Flow adds ~1,700ms.

Answer 2

I'll add:

1. When working with e-mail alerts, the setup UI knows which workflow rules use any given alert and will show you this in a very simple way. The setup UI has no idea which Process Builders use any given alert and the only way to conclusively "reverse search" this is to retrieve the metadata. So whenever we need to fire an e-mail alert I lean towards WF rules first.
2. The behaviour of timed Workflow actions is easier to work with than the behaviour of timed Process Builder actions.
3. Workflow rules handle nulls as gracefully as formula fields do (e.g. Contact.Account.Parent.Parent.Name returns null if anything along the chain is null). Process Builders scream bloody murder so you have to add more conditions to guard against null exceptions.

Process Builder is in general more powerful but for simple cases Workflow works well.

Answer 3

Once a process in Process Builder has been activated, it cannot be modified, only cloned. Conversely, a workflow can mostly be modified while it is active. For orgs that might need to update their workflows regularly, just modifying the workflow rather than having to clone and reassign is much simpler.

Creating a process requires Manage Force.com Flow and View All Data permissions, while creating a workflow requires Customize Application. Depending on your organization's security posture, this may be a significant difference.

Answer 4

I'm not sure I prefer one over the other, but one thing that keeps pulling me back to workflow rules is that I can easily see all the field updates and where they are used. Process builder hides the actions in the process and it is hard to find the process that does "x".

Answer 5

My rationale for preferring Workflow to Process Builder was that I believe Workflow to be more reliable and stable. But I can't prove that. Workflow for me always operates as expected. Process Builder fails, but usually because of some edge condition we missed. I cannot think of a case in which Process Builder failed due to a bug.

Answer 6

An unconfirmed advantage for Workflow (from a parallel conversation):

This may have changed but last time I looked into this Process Builder snapshotted the record. So if for example you queue up a send email action and data is changed from the time the action is queued to the time the record is sent, the email would send with data as it existed at the time the action was queued.

Anyone know about this behavior?

Answer 7

Adding a second answer to this because I'm hearing a lot of chatter about it from Admins at my office lately. The Salesforce Optimizer now includes the text "Eventually, the Lightning Process Builder will replace workflow rules, so we recommend replacing workflow rules as soon as possible." Coupled with this Trailhead https://trailhead.salesforce.com/modules/workflow_migration many admins at my company do believe Salesforce is deprecating Workflow Rules (although it has not appeared in any official announcements). They have started encouraging everyone not only to choose Process Builder over Workflow, but actively start migrating as many of their customer's Workflow Rules to Process Builder as possible.

For the same reasons stated on this page I object. I believe that if Salesforce is really going to throw out WFRs one of these days, they will have to make major improvements to bring Process Builder up to parity with WFRs with respect to all the gaps identified here. So my advice has been - be aware but do not touch WFRs that work already and work well. Wait for an official SFDC announcement with a date for deprecation, if it ever comes.

I do see one interesting Critical Update in my Summer 18 preview org that may indicate Salesforce is indeed trying to patch up Process Builder shortcomings. I didn't even know this was an issue with PB but makes sense. Enable Partial Save for Flow and Process Bulk DML Operations This update prevents a failed process or flow interview from causing the rest of the transaction to fail. Instead, Salesforce rolls back only the records that fail to save.

Answer 8

To Add to the already discussed points, I would prefer a workflow over Process builder If I want to skip the custom validation rules re-evaluation on updating the field of the record.

To elaborate: If I have a validation rule that field F1 can only have date greater than Today(), and I have a requirement that if record is being added as closed than the date should be auto populated to today() -1 ,

then to fulfill this requirement I will just add the workflow rule. Workflow field update does not re-evaluate the custom validation rule, thus my record will save successfully.

If I use process builder, then, validation rule will be re-evaluated and process will not save the record.