You are here:
Nest Processes in the Process Builder
Invocable processes let you modularize sections of your processes and add more logic to them. An invocable process is a process that starts when another process invokes it. The process starts when in the process’s properties controls whether a process is invocable.
Required Editions
| Available in: both Salesforce Classic (not available in all orgs) and Lightning Experience |
| Available in: Essentials, Professional, Enterprise, Performance, Unlimited, and Developer Editions |
After December 31, 2025, existing processes continue to run, and you can activate, deactivate, and edit them; however, we recommend using Flow Builder. To migrate existing processes, plan your switch to Flow Builder and use the Migrate to Flow tool. For new automations, create flows in Flow Builder.
To invoke a process from another process, you configure a Processes action. That configuration includes passing a record to the invocable process, which is how the process knows which record to start with. Because the record is passed from one process to another, the invocable process receives a certain version of that record. That version differs depending on when the Processes action is executed.
Immediate Action
When you invoke a process through an immediate action, the process receives the values that the record contained when the top-level process starts.
Example: Process 1 updates an account and then invokes Process 2 based on that account. Process 2 receives the version of the account when Process 1 started.
Scheduled Action
When you invoke a process through a scheduled action, the process receives the latest values for the record.
Example: Process 1 updates an account and, 15 minutes later, invokes Process 2 based on that account. Process 2 receives the latest version of the account from the database.
When Should I Build an Invocable Process?
Do you find yourself building the exact same actions for multiple action groups? Configure those actions one time in an invocable process, and then invoke that process from all the relevant action groups. Later, to update those actions, update the one invocable process. Then all the other processes use the updated actions.
Another cool scenario for invocable processes: nesting simple logic. Processes handle simple “if/then” statements. But what if you must nest some of those statements? Rather than having to build a flow or write code, build the second level of logic into another process. Invoke the second process from the first, and voila!
Let’s say you handle all of your case management in a single process. But you must treat escalated cases for high-revenue accounts differently from escalated cases for regular accounts. If an account whose renewal date is less than a month away escalates the case, notify the account owner, the regional manager, and the VP of that region. If an account whose renewal date is more than a month away escalates the case, notify only the account owner and the regional manager.
To do so, you build an invocable process. Let’s call it “Escalated Cases.” The process operates on the Case object and has two criteria nodes.
- The first criteria node evaluates whether the associated account’s renewal date is less than a month away. When a case meets that criteria, the process posts to the account’s feed with a link to the case and mentions the account owner, regional manager, and regional VP.
- The second criteria node has no criteria. If a case doesn’t meet the first node’s criteria, the process performs the same action, except that it doesn’t mention the regional VP.
Now back to the process that automates your case management. You already have a criteria node that checks whether the case is escalated. Add a Processes action to that criteria’s action group, and configure the action to invoke the “Escalated Cases” process.
