Build in a test environment.
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.
For each object, use one automation tool.
If an object has one process, one Apex trigger, and three workflow rules, you can’t reliably predict the results of a record change.
Have only one record-change process per object.
Each time a record is created or updated, all record-change processes for its object are evaluated. We recommend restricting your org to one record-change process per object. Here’s why.
- Get a consolidated view of your org’s automation for an object
With one consolidated record-change process for an object, you can see all the criteria that are evaluated each time that object’s records are updated, as well as the actions that are performed when the criteria are met.
- Avoid hitting limits
When you consolidate your processes for one object into one master process, you also consolidate the actions in those processes. With fewer actions, your org is less likely to hit limits, such as number of SOQL queries.
- Determine the order of operations
If you create multiple record-change processes for an object, Salesforce can’t guarantee the order in which those processes are evaluated. When you automate everything in a single process, you explicitly set the order. The first criteria node is evaluated first, the second criteria node is evaluated second, and so on.
Here are a couple features that can ease your path to one master process.
- ISNEW()
- Some automation applies only to created records. The rest applies to created and edited records. How could you possibly combine all of them into one process? Meet the formula function that detects whether the record being evaluated was just created:
ISNEW().To add a create-only automation to a process that starts when a record is created or edited, convert the associated criterion’s conditions to a formula. Then add && ISNEW() to your formula.
- Invocable processes
- Just like a process can call flows, a process can call other processes. Invocable processes are modular processes that start only when another process tells them to.
For example, several criteria nodes in your “Account” process each evaluate some conditions, including whether the account is high value. Move those criteria nodes, without the high-value condition that they have in common, into a “Top Account” invocable process. Then configure your ”Account” process to invoke the “Top Account” process if the account is high value.
Combine actions when possible.
The more actions that a process executes, the more likely your org is to reach limits, such as the number of DML statements or total CPU usage. Avoid creating multiple actions when a single action would do.
For example, a process updates an account’s address. Instead of creating a different action to update each individual field, create one action to update all the address fields.
Build reusable actions.
Some process actions are always reusable: email alerts, quick actions, processes, flows, and Apex. But how do you reuse other types of actions in multiple criteria groups or multiple processes?
- To reuse a Create a Record action or an Update Records action, build a quick action. Quick actions can be used in processes, flows, and on record pages.
- To reuse other process actions, configure the actions in an invocable process. In the relevant criteria groups, add a Processes action to call the invocable process. Invocable processes can be used only in processes.
Watch out for actions that overwrite previous changes.
Avoid having or be careful when multiple action groups update the same field.
Avoid generating infinite loops.
For example, an Update Records action in Process1 triggers Process2, and a Create a Record action in Process2 triggers Process1. The looping causes your org to exceed its limits.
Make sure that immediate actions don’t cancel scheduled actions.
Pending scheduled actions are canceled when the associated criteria are no longer true. Make sure that the later immediate actions in your process don’t unintentionally cancel pending scheduled actions.
Test as many permutations of your process as you possibly can.
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.
To access external data after changing Salesforce data, use scheduled actions.
If Salesforce creates, updates, or deletes data in your org and then accesses external data in the same transaction, an error occurs. In your processes, we recommend using a separate transaction to access data in an external system. To do so, end the prior transaction by adding a scheduled action. For a record-change process, don't use a field-based schedule.
For example, an event process starts when it receives a platform event message from the custom platform event, Order Status. If the order status is new, the process creates a contact and schedules an action to update the order status in the external system. The event process doesn’t fail because the scheduled action creates a separate transaction to access the external system.
Source : Trailblazer Community
.png)
0 Comments