Before you design a process, understand the limitations and guidelines.
Available in: both Salesforce Classic and Lightning Experience
Available in: Professional, Enterprise, Performance, Unlimited, and Developer Editions
The Process Builder is supported in Microsoft® Internet Explorer® version 11. Previous versions aren't supported.
Make sure that your processes aren’t set up to create infinite loops. For example, if an Update Records action for Process1 triggers Process2 and a Create a Record action for Process2 triggers Process1, the looping might cause your organization to exceed its hourly limits.
If you create processes to replace other setup entities, such as a workflow rule, or an Apex trigger, make sure you delete those entities when you activate the equivalent processes. Otherwise, both workflow and processes will fire and cause unexpected results, such as overwritten records or redundant email messages.
For a given object, use either workflow rules or processes—not a combination of the two. If you use both, you can’t predict the order in which they’re executed.
If you create processes to replace any Apex triggers, make sure you delete those Apex triggers when you activate the equivalent processes. Otherwise, both workflow and processes will fire and cause unexpected results, such as overwritten records or redundant email messages.
An immediate action on a record update obeys validation rules.
A scheduled action on a record update skips validation rules.
Each process is associated with a single object.
Actions are executed in the order in which they appear in the Process Builder.
If any of the actions fail, the entire transaction fails and an error message displays. For example, a Post to Chatter action fails if the Chatter group that it tries to post to is private. For details, see Troubleshoot Processes.
If a single action group includes multiple “Update Records” actions that apply different values to the same field, the last action’s value is used.
Processes that update owners don’t also transfer associated items. To ensure transfer, use one “Update Records” action for each type of child record that you want to transfer. For example, if you’re using a process to transfer an account to a new owner, use one action to update all the child contacts, one to update all the child opportunities, one to update all the child contracts, and so on.
Before you change a custom field’s type or name, make sure that it isn’t referenced in a process that would be invalidated by the change.
If you change a custom field’s label, a process that references it won’t break. But that process will still show the old label.
You can’t delete a custom field that is referenced by a process.
File type custom fields aren’t supported in Process Builder. For example, if your process creates a knowledge article record that has a custom field type of File, an error occurs when the process runs.
If you have processes on converted leads and want to update the records that result from the conversion, you must enable the lead setting Require Validation for Converted Leads.
If your organization uses multiple currencies, currency fields are updated using the record's currency code. If you choose to update a field based on a formula, any values in your formula are interpreted in the currency code of the record.
External objects and deprecated custom objects aren’t supported in the Process Builder.
If a standard formula field references a field on a related object, that field's value is always null when a process starts. For example, the RevenueShare field on Campaign Influence calculates CampaignInfluence.Opportunity.Amount * CampaignInfluence.Influence. Because the formula references a field on Opportunity (a related object), the field's value is null. This limitation isn't the case for custom formula fields that reference a field on a related object. For a custom formula field that uses the same formula, the field’s value is derived when a process starts.