◷ Reading Time: 2 minutes
When an application launches a Workflow, a new instance of the model is created and will be started. If execution reaches any of the states below, the instance will be stored in a durable storage:
When the Workflow Instance is stored in the storage (e.g., hibernated because of Suspended and Waiting states), the control returns to the application. The application can communicate back to the instance using the Resume method by having the latest execution context whenever required. The execution context can be loaded automatically by using the Workflow Instance Id.
When control is returned to the application, it can then communicate with the Workflow for multiple reasons:
- Querying about the available actions
- Resuming to continue the execution
When resuming a hibernated Workflow Instance, the application can simply pass the Workflow Instance Id for the resumption and the Workflow Engine takes care of everything.
Querying the Workflow Instance allows the application to understand the state of the Workflow Instance and decide what to provide back to the users for their input. When a Workflow Instance is hibernated, by accessing the stored context your application can query about:
- The step that put the workflow into hibernate
- The available task that workflow is waiting for (parallel and sequential tasks)
- Receive Task
- Human Task
- Acceptable Outcomes of the Tasks that the user can choose from
To query the Workflow Instance, the GetReceivers method can be used.