Mistakes to Avoid When Building Process Automations in Salesforce
7 min
Salesforce provides various automation tools that help increase process efficiency and productivity. Some of the process automation ways are Workflow Rules, Process Builder, Flows, or Apex Triggers.
Before you start…
Before creating any process automation, you need to make sure that you have a proper understanding of the requirements you’ll face. Also, being familiar with the automation tools and with the relevant Salesforce limitations- otherwise, there will be issues during the testing or deployment phase. In case you need to double-check, here are 5 Basic Principles to Creating Stable Process Automations in Salesforce.
While building process automation, we should keep some key points in our mind and should avoid the following mistakes:
1. DML Statements In Loop
We should never write a DML statement inside a loop. That means: never perform an update, create, get or delete operations inside a loop. This practice has the risk of hitting governor limits.
2. Not Checking For Null and Empty Results
Whenever we use decision elements in process automation, we should check for null and empty results before acting on a set of records. We should think about all the scenarios for better automation.
3. Not Creating Fault Paths
One of the common mistakes that may come up while building process automations is not creating fault paths. Fault paths are designed to handle an error you get during the execution of flow. It is like exception handling that tells the flow what it should do.
5. Using More Than One Tool On a Single Object
We should choose one automation tool per object. Mixing Apex, Process Builders, Flows, or Workflows together can lead to endless issues like poor performance and inability to control the order of execution, leading to unexpected results or hitting limits such as the number of SOQL queries.
6. Hard Coding
Hardcoding means writing a fixed solution or embedding output directly into a program's source code. It should be avoided as much as possible, because it destroys the portability of the code. If you hard-code the LDS in process automation, they will change when you move the code from one environment to another.
7. Looping a Huge Amount Of Data
When you loop a large amount of data, it can hit governor limits for number of records retrieved through SOQL. We cannot retrieve more than 50,000 records in a single call, so a good thing to remember is you can use the logic of batch class instead.
8. Not Using Proper Documentation And Description
You should use proper naming conventions while creating variables or elements during process automation, include variable descriptions, and make a habit of documenting the process automation. This will help understand the process better if you or anybody else from the team is working on it in the future.
9. Using Production Environment for changes
You should never use the company’s production org to make changes in your process, nor code directly into a production org of Salesforce. These changes are better be made in a sandbox environment to prevent the loss of your important data. Sandbox is a risk-free environment where you can execute and test unsafe software code, and any changes or mistakes you make in Sandbox will not affect any live business process.
10. Not Saving Early And Often
Salesforce does not save your changes automatically; rather you have to do it yourself. Sometimes you may face unexpecteded problems while building a process automation, like losing internet access or facing a sudden power outage. This is why it is advisable to save your work as often as possible, that way you don’t lose the hours you’ve invested doing this.
.png)
.jpg)
.jpg)
