This section describes everything that relates to the order of process execution. In general, process execution represents a constant transition of a process from the Idled status to the Running status and vice versa. When a process is Idled, it waits for a command or a timer to trigger it. The process spends most of its lifetime in this status and does not consume resources in your application. The process state is stored in the persistence store. When a process is in the Running state, it successively executes the Actions attributed to an Activity, calculates conditions and changes its state. Besides, a process has two more statuses: Initialized, which is attributed to a process immediately upon creation, and Finalized, which marks its completion. For more details on how a process is executed, how its states and statuses change, and what events are called in it, refer to the respective section.

Workflow engine supports parallel branches. Each branch is set up by creating a regular transition with the IsFork = true attribute, which leads to the appearance of the subprocess. A subprocess is quite similar to a regular process: it may change its state regardless of the parent process and may be interacted with just like an independent process or via a parent process. A regular process and a subprocess are created and finalized in different ways. A subprocess may merge with the parent process and change the state of the latter. For more details on subprocesses, refer to the respective section.

During a regular execution, a process changes its state; however, Workflow Engine has a special mode of process execution simulation, where a process does not change its state, but its Activities are executed. This mode is called PreExecution, and it may be successfully used in a number of business cases. For more details, refer to the Pre-Execution section.

When working with workflow systems, the issue of updating the scheme for processes which are in the run will inevitably arise. Workflow Engine supports two major strategies for process scheme update. It means that old processes may be (automatically) updated to a new scheme, or old processes may keep using the old scheme. For more details on how to use both strategies, refer to the respective section.

Besides, this section describes how you can modify one of the Workflow Engine's components - scheme generator - to implement various cases, for instance, how you can add Actions, which should be executed in each Activity, to the main scheme.