Workflow Rules vs. Process Builder

Workflow Rule

Workflow has been an admin’s friend for a long time. Workflows can:

– Update a field
– Send an email
– Create a Task
– Send an outbound message (communication with another system)

These can be initiated when a record is created, whenever it meets a certain condition, or whenever it is first set to meet a certain condition. The actions can be performed in any combination and can even have a time delay, rather than be performed immediately.

Process Builder

Process Builder is a newer tool for admins which is even more powerful. In addition to everything a workflow can do (except for sending outbound messages), you can:

– Create a record (not just Tasks!)
– Update related records
– Launch a Quick Action
– Post to Chatter
– Launch a Flow
– Call Apex code
– Submit for approval
– Invoke another process

Process Builder also extends upon the things that workflow does. For updating related records, Process Builder can update any field on any related record, where Workflow can only update some fields on a parent record of a Master-Detail relationship. Process Builder can also update multiple related records in a situation when all of a record’s child records need the same update.

Also, Process Builder finally gives admins the ability to set the exact order of operations, whereas with Workflow we had no control. No more complex workarounds to be able to ensure things happen in a certain order!

Since Process Builder also has the ability to configure multiple if-then conditions in one Process rather than separate Workflow rules, it helps new admins and admins who inherit orgs visualize the business processes with its sleek visual interface.

Process Builder has versions, so you can retain deactivated Processes. This can be very helpful if you realize something isn’t working and want to look back to what was happening before.

Lastly, one of the biggest reasons to use Process Builder, might just be because it’s the future.

According to Salesforce:

We’re no longer enhancing Workflow. We still support your use of workflow rules, and will continue to do so. But all new functionality for the workflow use case will come through Process Builder. If you want to use the shiny new functionality, migrate your automation to Process Builder.

If you have a mature org, it no doubt has lots of Workflow rules already running. As you see from Salesforce, they aren’t discontinuing Workflow support, so there’s no imminent reason to go back and convert them to Processes. That said, take the time when you can to make replacement Processes in a sandbox, so that you can future-proof your org. Salesforce has an excellent Trailhead module to walk you through migrating Workflows to Processes.

For all new Objects it’s advisable to eschew Workflow in favor of Processes. Be careful if you need to add new automations to existing Objects that already contain Workflow, however. You probably want to stick with Workflow if you can. Per Salesforce:

Because you can’t choose which workflow rule is evaluated first, choose one tool to automate everything for a given object. If you use both Workflow and Process Builder, you can’t reliably predict the results of a record change.

Apex

Finally, there’s always Apex to help you achieve “everything else” — whatever business requirements you have that can’t be accomplished through declarative configuration. If you have access to a developer, with Apex the sky is the limit. With Apex you could do the following:

– Delete records
– Update unrelated records
– Share records with more complex criteria than Sharing Rules permits
– Add/remove users in Chatter Groups and Public Groups
– Create email templates that pulls info from multiple records and Objects (combined with Visualforce)
– And more

Apex is powerful tool, but do your best to minimize its use. Don’t be afraid to employ it, but makes sure you think it through thoroughly to determine if there is a way you can accomplish what you need declaratively. Using Apex means that you’ll need to write test coverage and the more Apex you have, the longer it will take deployments from Sandboxes because the changes need to be validated against all of the code.

By knowing the tools available, what they can do (and their limitations), and when is best to use each, you’re in a position to give your users the best experience possible while also creating an environment for your organization to have the best data possible.