A Process Model is the set of processes within a model. Process is a container element for you Goal or BPMN process workflow. They are always part of a Module, with one Module containing an arbitrary number of Processes. Just like a Module, a Process represents a namespace which, on runtime, results in a local process context, a Process instance. A Process can contain other elements that represent further nested namespaces and result in further local contexts in the Process instance context, such as, Sub-Process contexts.

There are two types of Processes:

Goal-based which makes use of the Goal extension of GO-BPMN
BPMN-based defined as pure BPMN Processes.

When a process instance is to be created, the server checks if the Process is executable: if the Process is not executable, no instance is created. If it is executable, instantiation takes place:

Process instance based on the Process is created.
Process namespace instance is created.
The Process instance becomes Running.

Note: What happens when the process instance becomes running depends on whether it is a BPMN Processes and Goal Processes.
On execution finish, the Process instance becomes Finished.

When a Model is instantiated it attempts to create instances of all its processes including any processes in its Module imports: for each Process it checks first whether the process is executable as stated above and then whether it can be instantiated automatically.

Processes can be reflected as Records: this allows you to create instances of Processes by instantiating them as Record instances; for example, you can send the name of the Process as a parameter to the Execute Task and instantiate it in the Execute Task from another Process; for further information, refer to the Standard Library documentation.

Process Attributes

Executable is a Boolean attribute set by default to true so that the Process can be instantiated

If false, the process is cannot be instantiated: as a result, if a Model instance is triggering processes on start automatically or with another mechanism later (such as, signals), the process is not instantiated.
Visibility defines the access rules to the Process.
Create activity reflection type creates a Record that reflects the Process.

Goal Processes

A Goal-based Process is a Process with a Goal model.

On execution, after the parent model instance becomes Running, one process instance based on the process is created.

When instantiated, the following takes place:

Context data are created and initialized (initial values are assigned).
All top Goals are triggered (become Ready and, if their conditions are fulfilled, immediately Running) and the Process instance becomes Running.
When no Achieve Goal is Active (Ready or Running) and no Plan is running, the Goal-based Process instance becomes Finished.

BPMN Processes

A BPMN-based process encapsulates a BPMN-based process model.

It is instantiated when the parent model instance is instantiated, possibly multiple times by different start events.

Note: A BPMN-based Process may be used as a Reusable Process and be instantiated as a sub-process instances.

When a BPMN-based process is being instantiated, the following happens:

Context data are created and initialized (initial values are assigned).
The process instance becomes Running and its Start Event, and Activities without incoming Flow are triggered and produce tokens. The token is passed to their outgoing flow: the token marks the currently executed step.
When no process element is active (there is no token in the workflow), the Process instance becomes Finished.

A BPMN-based Process defines the following specific properties:

Instantiate automatically: Boolean attribute defining if the process creates its instance when requested (if false, the Process can be triggered only as a Reusable Sub-Process)
Parameters: an arbitrary number of parameters with a parameter name and type (when called as a Reusable Sub-Process, the parameter value is added)

Reusable Processes

A Reusable Process is an application of a BPMN-based Process when the Process is called by a Reusable Sub-Process activity (Reusable Sub-Processes). One Reusable Process can be called by an arbitrary number of Sub-Process activities, thus providing a convenient mechanism for reuse of workflows.

Any BPMN-based Process can be used as a Reusable Process provided it meets the following criteria:

It starts with a None Start Event, that is, no other Start Events are triggered.
It is public.

If a BPMN-based Process is used only as a Reusable Sub-Process it can define an arbitrary number parameters as the process properties. Note that the properties can be defined as required.

Note: In Living Systems® Process Design Suite, a Reusable Process must be marked as executable. Also, consider disabling the Instantiate Automatically on the Process so that it is not instantiated when the parent Module is instantiated.

Reusable Processes can have the Parameter name property.

Process Modeling