Tim Lockie
In a world led by technology, automation is key to saving time and creating user-friendly processes.
#LevelUp with Process Builder
Process Builder is a powerful tool that delivers automation in Salesforce and was specifically created to help you overcome the anxiety of and processes of automation.
Technology recognized best practices ensure you are maximizing opportunities with Process Builder, thus eliminating error messages and emails. The five best practices noted below will help ensure you make the most out of automating with Process Builder.
Tips & Tricks
- If you’re referencing related objects, make sure they exist.
When using information from fields in a related object to populate a new record, update an existing record, or set a variable in a flow. It’s important to ensure the relationship exists before pulling information from the related record.
For example, if you want to update an Opportunity/Donation’s Close Date to match the End Date of the Campaign it’s related to, you need to build and activate a Process Builder. If an Opportunity gets created without a Campaign, however, then a “Flow Trigger” error will occur. To avoid the error, ensure the Opportunity is related to a Campaign (see example below):
When evaluating formula versus using criteria simply add the following criteria in the formula:
NOT(ISNULL([fusion_builder_container hundred_percent="yes" overflow="visible"][fusion_builder_row][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"][Opportunity].CampaignId ) )
Including this additional criteria will prevent the Process Builder from looking for information that is not available.
- Use Set Conditions instead of formula criteria.
The old Salesforce adage of “clicks over code” applies here as well. The Set Conditions in Process Builder can do a lot more than what you may be used to with Workflow rules. For example, not only are the Set Conditions easier to read, but the validity is more stable than the formula builder.
Formulas are used for analyzing criteria that aren’t available in Set Conditions; the prior value of a field, for example. As a precaution, the formula editor in Process Builder does not have the same level of syntax/error checking as it does in Workflow and Validation rules. Therefore, formulas must be tested to ensure accuracy.
- Test and Deploy Process Builder to a Partial or Full Copy Sandbox first.
Some want to rush the “go live” process; by activating a Process Builder in Production. It’s easy to do, but not efficient as it can creates errors and bad data that are difficult to reverse. Therefore, it’s important to build first in the Sandbox. Finally, test, test, and test again before deploying to Production.
Note: When deploying Process Builder and using a change set the latest version of the Process will be saved as an “inactive” version. As a result, it is necessary to open the Process, activate it and then it will go live.
- Whenever possible, use the RecordType.Name instead of the ID in your criteria.
There is some debate around this issue, some say it’s best practice to use the 18-character Record Type ID instead of a name. Names can be changed, but ID’s remain the same.
Now, if following best practice #3 to create a Process Builder in a Sandbox, the Record Type ID will change when you deploy it to production. The Record Type Name, in contrast, will stay the same. Minimizing the number of changes made in Production is preferable, but you will need to remember to update Processes if Record Type Names are changed.
- Keep track of your Processes and Workflow Rules.
There is a lot of overlap between what Workflow Rules and Processes can create overlap, so it’s a good idea to create a plan to help keep track of them and ensure a Workflow Rule and a Process are running in parallel.
The best way to ensure there is no duplication is to give priority to one rule/process over the other. For example, make it a priority to use Process Builder for all process automation unless it can only be done by a Workflow Rule (for example, sending outbound messages). Doing so will ensure the automated process is easy to locate. Or, keep track of the automated processes on a separate list or spreadsheet (which notes the object and identifies it as a Process or Workflow Rule).
[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]
