Last Updated on December 5, 2020 by Rakesh Gupta
Process Builder is a like a double-edge sword – on the one hand, it is one of the most powerful tools provided by Salesforce to implement business automation declaratively; on the other hand, if one implements process builder sloppily then, it may turn into a nightmare by flashing errors like SOQL 101 error, CPU timeout, etc.
Let us first understand the role Process Builder plays in streamlining businesses processes and procedures. First and foremost, Process Builder helps businesses save time, as well as money, by enabling users to implement solutions quickly. Implementation of Process Builder is straightforward – you create a Process; test it; and then, use Change Set, to deploy it to Production. The best part is, you do not have to write test classes for your Processes or Flows.
We all desire to be on the right side of the sword! The question is, how? How can one learn to adhere to best practices to implement process automation declaratively?
Well, look no further! For, 100+ blogs, on Process Builder, are on Automation Champion alone.
To get you started, this article summarizes best practices and strategies to implement Process Builder processes.
#1 Always! Plan before you build
The key to successful project implementation is – design first and then implement. Process Builder is no different – the same logic applies here too. I have seen many cases where people start creating process(es) as soon as they get requirements. As a result, more often than not, users end-up getting some weird error messages.
I am a seasoned trainer. Time and again, I have to remind my trainees not to rush into implementing the process as soon as I give them requirements! Furthermore, I get number of requests from the community to help them identify errors in their process builder. My first question to them is, please show me your design. Almost always, their response is – Design? Huh? What? I can show you my process, why do you need to see a design? So, please, save time and sanity – Design first!
Here are my suggestions – once you get the requirements do the following:
- Create a flow diagram using draw.io of LucidChart – this will ultimately help you in implementation and testing.
- Explore your Salesforce org and see if you can incorporate the requirement in one of the existing processes.
- If you are able to find one process then, think how you can add the current requirement in one of the existing actions – Don’t add anything unnecessary until it’s required.
#2 One process per object!
Once you understand the requirement and create a flow diagram, do not rush to implement it by creating a new process. As I said earlier, try to find an existing process and see if you can incorporate current requirement(s).
In any case, do not create more than one Process on any object. This idea comes from Apex Trigger best practice and design pattern. Furthermore, to achieve flexibility and create reusable processes, you may have to use Visual Workflow. Following, one process per object, concept will allow you to manage all your processes for a given object in one place. For, when you have one process per object, it is less likely to hit limits – such as number of SOQL queries; and, it will also allow you to avoid generating infinite loops.
#3 Build in a test environment
Processes can be created or updated in a production environment – I have seen people make changes directly into production org – don’t! Without testing into development, creating or editing in production environment ‘may’ (read, certainly will!) lead to data loss or trigger some unwanted emails or end-up creating too many test records.
For example, to test whether a process is working properly, you must activate it. Build and test your processes in a sandbox environment, so that you can identify any issues without affecting your production data. As with all customizations in Salesforce, it’s important to test your work. Make sure that you test as many possibilities as you can think of before you deploy the process to your production org.
#4 Don’t create automation for everything
If it is possible to achieve a solution through Formula or a Report then, don’t create automation for it! Basically, use automation sparingly!! For example, if you want to display Account Site on Contact record then use Formula field, not automation.
At the same time, if there is something that can be better handled through Apex then, don’t try to use Process Builder. For example, when someone (manually or via any tool) deletes a record send email alerts to the record owner.
#5 Use the advanced technique to merge Nodes/Processes
Once you start thinking about one process per object – you may wonder, how can I handle process/action which needs to be fired only at the time of creation? The answer is very simple – use formula ISNEW() while defining the criteria! Similarly, if some automation applies only to cloned records then use ISCLONE() function.
Check out my previous articles:
- Getting Started with Process Builder – Part 84 (Ever Needed to Select Multiple Picklist Values in Process Builder? How About via a Single Condition?!)
- Getting Started with Process Builder – Part 85 (Leveraging Versatility of Rule Criteria – a Deeper Dive!)
- Getting Started with Process Builder – Part 86 (What? Create a Process with No Action? Really?)
- Getting Started with Process Builder – Part 87 (Untangling the Perplexing Filter Logic of ‘Updating Records Action’!)
In the aforementioned articles, I have discussed few advance concepts that will help you to optimize your process. If you didn’t get a chance to read it yet, do it now! It will significantly improve your knowledge of Process Builder. Once you master the art of leveraging process builder, you will be able to easily create an optimized process!
#6 Build reusable actions
Some process actions are always reusable – for example, email alerts, quick actions, Invocable processes, Flows, and Apex. But, how do you reuse other types of actions in multiple criteria groups or multiple processes?
- Build a quick action if you want to reuse ‘Create a Record’ action or ‘Update Records’ action. You can use quick actions in processes, flows, and many places.
- Use the Invocable process to reuse other process actions. For example, if some action is common then it is better to configure the action in an Invocable process and add a Processes action to call the Invocable process.
To learn more about the reusable process – check out the following articles.
- Getting Started with Process Builder – Part 71 (Set Your Productivity on Steroids by Creating Reusable Processes!)
- Getting Started with Process Builder – Part 72 (Execute Actions on More Than One Criteria)
#7 No hardcoding IDs!!
Yes, it is sometimes a good idea to hard-code values (for example, while learning Apex or Process Builder you may hard code value of Pie – 3.14). But there are no simple rules as to when it is a good idea to hardcode something – it all depends on a specific scenario. For instance, if you hardcode the value of earth’s gravitational constant then, that would be a good use case for hard coding. But, god forbid, if you hard code a record ID (Queue, Group or Salesforce record Id, etc.) then, you just invited trouble! Time and time again, I see Apex code, Flows or Processes that contains hard-coded Ids – whether it’s the Description field, a user ID, or a group ID. The problem with hard coding IDs is that if any changes need to be made to the Flow or Process then, you will have to test again and then deploy to production org. The record IDs can change, for example between a sandbox and a production environment; or, it may be that a queue (Dupe Management) has a different ID in a sandbox and in a Production org. So, now you know, not that hard to understand, is it? NoHardCoding!!
Instead, I suggest you use Custom label to store IDs. Checkout previous articles to learn how you can use Custom label in Process Builder.
- Getting Started with Process Builder – Part 60 (Just say no to hard-coded ID)
- Getting Started with Process Builder – Part 63 (Update whoId when shared activities are enabled)
#8 Use Custom Metadata Types to store a list of values
Custom Metadata Type is similar to a custom object – it allows application developers to create custom sets of data, as well as to create and associate custom data with an organization. All custom metadata type data is available in the application cache. As a result, it allows efficient access to the data without the cost of repeated queries (SOQL) to a database.
Custom Metadata Type is mainly used to store information that will be frequently accessed from Apex code. Custom Metadata Type performs better than a custom object because, as mentioned, it is available in the cache; and therefore, it does not have to be queried.
Check out the following article to learn how one can use Custom Metadata with Process Builder.
- Getting Started with Process Builder – Part 69 (Auto Create a Case form Keyword Word Used in Chatter)
#9 Use Debug Log to check why a process fails at runtime
Process Builder is a powerful tool for system administrators and developers to implement business processes without writing code. However, with great power comes great responsibility. If a user starts creating a new process for each requirement – or creating processes without understanding Salesforce limitations – then, a user may encounter many issues, either in future or, while testing/deployment phase.
Now once you encounter the error message don’t be panic – you are the not the only one who has ever gotten error messages; and this may be your first but, it certainly will not be the last time you encounter an error message! So, the best thing to do is to learn how to tackle it! First, take a deep breath! Then, use Debug Log to find the root cause behind the error message. Once you have the root cause – or you understand why you got such error messages – 50% of the time you can easily solve it; if more help is needed then, google it and you will get some solution for it.
Check out the following articles to see how I have used Debug log to solve a problem:
- Getting Started with Process Builder – Part 64 (How to fix MIXED_DML_OPERATION error)
- Getting Started with Process Builder – Part 65 (Resolve ALL_OR_NONE_OPERATION_ROLLED_BACK error)
- Getting Started with Process Builder – Part 66 (How to fix FIELD_INTEGRITY_EXCEPTION error)
- Getting Started with Process Builder – Part 67 (How to fix MALFORMED_ID error)
#10 Don’t deactivate – use custom permission to bypass Processes at runtime
Processes will execute as soon as they meet set criteria. There are some situations, however, when a business may want to bypass a process! For example, when mass updating accounts and opportunity records, you may want to deactivate a process so that it will not trigger any email alerts.
It is best practice to add bypass condition in your process instead of deactivating the process. By adding bypass condition into your process, you can easily toggle between users and bypass a process for selected individuals or situations. Check out the following articles to learn more about how you can add bypass logic to process builder:
Have your own process builder secret sauce? Great! Share it!
Proofreader: - Munira Majmundar