{{< loadmermaid >}}

Define any simple or complex process withouth the need to code the orchestration. This process can be made up from multiple steps and follow different paths depending on the process conditions.

With the Orchestrator you can:

• Orchestrate background, user driven or mixed processes.
• Manage parallel branches.
• Automatically request user intervention.
• Define processes that depends on asynchronous / external inputs.

---

title: Process Temmplate ER

---

erDiagram
    ProcessDefinition ||--}| ProcessInstance : ""
    ProcessInstance ||--}| ProcessStepInstance : ""
    ProcessStepInstance ||--}| ProcessStepInstance: Source

Each Process definition is stored in a Process Definition record, which contains a JSON with different objects:

• Process Step Definition: They represent each of the different process steps. Apart from different properties, it specifies the different Predecessors and Actions involved in this step.
• Connection Definition: It could also be considered as Entry Criterias for the step. They define the conditions that must be met in order to enter that step.
• Process Action Definition: They define which actions to be executed once the process enters a specific step.

With these objects it’s possible to define a wide range of process types which can execute almost any kind of process.

Architecture

The Orchestrator process is based basically in four different pieces:

• Process Definition: The process definition.
• Process Instance: A specific instance for a Process Template.
• Orchestrator Manager: The engine which is in charge of processing the processes instances.
• Process Triggers: Different mechanism to trigger the proces evaluation as: Apex, Apex Trigger, Flow or Button.

When a project is instantiated, the different process steps that must be executed will be created related to the Process Instance. The steps in the process instance will be updated as long as they are required. This process will allow the Orchestrator to know in which step of the Process Definition the instance is.

It’s important to note, that in order to make the Orchestrator evaluate if it must execute any new step, wait, etc it must be invoke by any of the methods available: Apex, Apex Trigger, Flow or Button. This means, that this evaluation can be trigger in many different ways depending on the needs. But what it’s important to remark, is that the Engine must be explicitely invoke in order to make the process progress. This will be detailed later in this documentation.

The Process Flow

Simplifying, the Orchestration Process flow will follow the following steps:

1. A Process Instance is created for a record and a Process Template through Flows, Apex, Triggers or any other way.
2. The Engine will create and evaulate the first step of the process in order to know if any action must be executed at the beginning.
3. Initially, the Start Step will be in status WAITING. The rest of Connections, Steps and Actions will be in status PENDING.
4. When the Process is instantiated or a evaluation request is received the engine will:
   1. Check if any Pending step with the beacon set to true has a next connector meets the criteria. If it meets the criterias (rule and/or command) it will set the target Step to PENDING and set the beacon to true.
   2. For each connector that meets criteria:
      1. It executes each Step action that is in status PENDING.
      2. If all the step actions are set to COMPLETE, the STEP is set to complete and the process.

Process Actions

A Step can have zero or more actions related to it. The defined actions will be executed once the Step is entered.

The actions allow the orchestrator to perform a wide variety of actions as CRUD operations on records, Apex or flow Executions & User Navigations between others.

Action Outputs

The outputs returned by any action will be stored at Step level in the Procss Instance context JSON. This way, from the Step it will be possible to access all the details about the executed actions. It’s also possible to reference action outputs from other steps.

This output can be later accessed and used for the others actions logic by using a path notation:
stepname.action.output.propertyname

Action Inputs

In most cases, an Action will need specific inputs, for this, the orchestrator offers three different kind of inputs.

Execution Mode

An action can be executed in two ways: Synchronous or Asynchronous.

You cannot execute Screen Flows in Asynchronous Mode.