Persisting Workflow States
The persisting workflow states are suspended workflow, failed workflow, checkpointworkflow activity, and subprocesses.
Suspended Workflows
A workflow may suspend on account of a single activity, such as one awaiting user action before the workflow can resume. In case of such suspended workflows, the entire state of the workflow is persisted to the database and file system. This persisted information is used to show the necessary information on the UI so that you can take the required action on the work item and the workflow can resume.
Failed Workflows
If a workflow fails, it cannot proceed further and the entire workflow state is written to the database and file system. You can locate the exact reason of the workflow failure on the Event Log screen.
CheckPointWorkflow Activity
If a workflow contains the special CheckPointWorkflow activity, it forces the workflow to commit the transaction and persist (to the database and file system) the workflow state and all documents till that point in the workflow. For more details, see CheckpointWorkflow Activity.
Subprocesses
The following rules apply to subprocesses:
- If the invoking activity (InitiateSubflow, SpawnWorkflow, or InitiateWorkflow) is asynchronous, the activity prior to the asynchronous activity is persisted.
- If the invoking activity is synchronous, the subprocess must be run in-memory, and the subflow cannot contain another InitiateSubflow, SpawnWorkflow activity, or CheckPointWorkflow activity.