Starting in Summer ’23, Salesforce is blocking the creation of processes. We recommend transitioning to Flow for your Salesforce automation needs.
What is Process Builder?
Process Builder is a point-and-click Salesforce tool that lets you easily automate if/then business processes and see a graphical representation of your process as you build. Every process consists of a trigger, at least one criteria node, and at least one action.
Why Process Builder?
Many of the tasks you assign, the emails you send, and other record updates are vital parts of your standard processes. Instead of doing this repetitive work manually, you can configure processes to do it automatically. Process Builder helps you automate your business processes and gives you a graphical representation as you build it.
Process Builder Capabilities
What does Process Builder do?
Without writing code, Process Builder can be made to:
- Update the current record
- Update a related record in a lookup or master-detail relationship
- Create new records automatically
- Send email alerts
- Post to Chatter
- Submit a record for approval
- Launch a flow
- And More!
To learn more, check out the following resources:
- Documentation – Lightning Process Builder
Note: Process Builder’s capabilities continue to evolve so always check Salesforce Documentation.
Process Builder vs Workflow
Process Builder lets you automate more things, it includes more flexible actions compared with the corresponding workflow actions. The Create a Record process action, for example, lets you create any record instead of just tasks. The ‘Update Records’ process action (which corresponds with the field update workflow action) also lets you update any related record, while the field update workflow action lets you update only the record or its parent.
Process Builder includes brand new actions that aren’t available in Workflow—such as Post to Chatter and Submit for Approval.
Process Builder is the future
Salesforce is no longer enhancing Workflow. They 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 newest and enhanced functionality, migrate your automation to Process Builder.
To learn more, check out the following resources:
- Trailhead – Workflow Rule Migration.
Considerations and Limits
Considerations:
- Process execution cycle
- Processes attempt to execute blind to other processes and procedures
- Apex, validation rules, workflow, and others can all cause problems
To learn more, check out the following resources:
Governor Limits
- Governor limit on Salesforce are not just for developers
- Process Builder is subject to the limits
- Always check Salesforce documentation for the current limitations
To learn more, check out the following resources:
Best Practices
Good design:
- Plot your business logic on paper or on chart
- Revise existing components if needed, something that worked last week may not work with new requirements you just received, and it may need to be brought into the scope of what you are working on.
- Strive for simplification
- Always avoid unnecessary recursion and infinite loops within logic
TIP: When you replace a workflow rule with a process, deactivate the workflow rule before you activate the process. Otherwise, you can get unexpected results, such as overwritten records or redundant email messages. This best practice also applies when you replace an Apex trigger with a process.
To learn lore, check out the following resources:
Control Who Receives Flow and Process Error Emails
When a process or flow interview fails, a detailed error email is sent to the admin who last modified the process or flow. But perhaps that admin isn’t the best person to read and act on the details of what was executed and what went wrong. Instead, you can choose to send error emails to the Apex exception email recipients, which you specify and control in Setup.
To Learn More, Check out the following article:
Control Who Receives Flow and Process Error Emails
Managing Many Processes
As a system’s dependencies grow, its complexity becomes harder to manage. It is often recommended using some percentage of time (usually 10% – 20%), reworking or refactoring existing processes.
Tips:
- Naming convention – Avoid unclear names
- Combine, collapse – Try to group conditions when possible to have one process instead of many
- Consistent design – Keep your design principles consistent
- Collaborate – Find effective ways to communicate with your team
Troubleshooting Processes
Use the error messages that appear in the Process Builder and the emails you receive when a process fails to help solve problems that arise when you’re working with processes. When all else fails, look at the Apex debug logs for your processes.
The following is a common design problem that causes processes to fail:
- The process references a field that hasn’t been set. For example, you reference [ChargentOrders__Transaction__c].Order.Opportunity in your process. If the Opportunity lookup field isn’t set on the Chargent Order, the process fails because it doesn’t know which Opportunity to reference.
The workaround for this issue depends on where the reference exists in the process.
- If you reference it in filter conditions, add another filter condition that checks whether the lookup field is set. You can do the same workaround if it’s referenced in a formula, for example, [ChargentOrders__Transaction__c].ChargentOrders__Order__r.Opportunity__c Is null False.
- Otherwise, consider making the field required.
To learn more, check out the following resources: Troubleshoot Processes
