On runtime, models can become model instances: The model, an executable module with all its imports, serves as a blueprint for the creation of its runtime version: a model instance.

The model instance holds data about its status and the module instances for each module: the parent executable module and any imported modules. Each module instance stores its runtime data, that is, the data about execution status, such as, whether the module instance is running, which processes are running, which task is being executed, values of variables, etc.

A model instance can define initialization properties, key-value pairs with information about the model instance. By default, each instance is created with the author property, which is set to the person who created it. If the model instance has been initialized by another model instance, then the Triggered by property set with the model instance id that created the model instance is set instead. The properties can include the process entity with an ID of a shared record which the instance works with. Such instances are typically created with the createModelInstance() function from a document or a process with the process entity passed in the processEntity parameter.

A model instance can be primarily in the following states:

Created: the model-instance context is created and the contexts of individual module instances are created.
Running: the context data are initialized, initial values are assigned, and all BPMN-based and Goal-based Processes in all module instances are instantiated. The execution takes place in transactions as described in Transactions in Model Instances. This happens in a bottom-up manner: First the modules that are "lowest" in the hierarchy are initialized; if module A imports module B and module B imports module C, then C is initialized first, then B and only then A. Consequently, you use the data of C and B in A but not vice versa.

A Running Model instance can be suspended: all its Process instances and their elements are suspended and no execution is taking place.

Note: If a Model instance attempts to perform an invalid action immediately when it becomes Running and an error occurs, the initialization is rolled back and the Model instance goes back to the Created status.
Finished: Model instance becomes Finished, when all its Process instances are Finished.

While a model instance is Running, you can suspend or finish it:

When you suspend a model instance, the execution is halted. To marked this state, the model instance and all running elements become Suspended. You can then resume the execution whenever required.
When you finish a model instance, the execution of the model instance is halted and it instance becomes Finished immediately.

Suspend and Resume

A Running model instance can be suspended: on suspend, its execution is paused immediately so that no changes on runtime data can take place. Execution of all running elements is interrupted and all elements become Suspended. A suspended model instance is read-only.

Suspended model instances can be resumed: when resumed the execution of the model instance continues from the point when it was suspended. The model instance becomes Running and all asynchronous inputs received by the model instance while suspended (Signals, elapsing of time periods of Timer Events) are received and processed.

It is not possible to resume a model instance that is being updated.

Note: If a Timer Event, either a Timer Start Event or a Timer Intermediate Event with a duration is suspended while Running, the duration is checked with regards to the time, when the Model instance was suspended. For example, a Timer Event with a duration of 60 minutes was triggered at 1 p.m.: if the Model instance is resumed at 1.30 p.m., the Timer Event continues running until 2 p.m.; if the Model instance is resumed at 3.00 p.m., the Timer Event is finished and the outgoing Flow is taken immediately. For cyclic events, only the last occurrence of the event is processed: For example, if a BPMN-based Process is to be instantiated every day at 12 p.m. and the model instance is resumed after three days at 1 p.m., only one process instance is triggered.

Finish

When a model instance receives a request to finish, the following happens:

Active activities (Tasks and Sub-Processes) fail and become terminated immediately.
Processes become finished:
- In Goal Processes, all Achieve Goals become deactivated immediately while Maintain Goals finish their current cycle and then become deactivated.
- In BPMN Processes, all active Activities its BPMN-based Process instances are terminated (fail).
All alive to-dos become interrupted so they cannot be submitted.
As a result, the model becomes finished since all process instances are finished.