If a persistence service is loaded, the state of the workflow is persisted in the following situations:

  1. When a workflow becomes idle. For example, when a workflow is waiting for an external event or executes a DelayActivity. To persist and unload a workflow when it becomes idle, the service must return true from the UnloadOnIdle method. With the standard, SqlWorkflowPersistenceService, you can affect this behavior by setting an UnloadOnIdle parameter during the construction of the service.
  2. When a workflow completes or terminates.
  3. When a TransactionScopeActivity (or CompensatableTransactionScopeActivity) completes. A TransactionScopeScopeActivity identifies a logical unit of work that is ended when the activity completes.
  4. When a CompenstableSequneceActivity completes. A CompensatableSequenceActivity identifies a set of child activities that a compensatable. Compensation is the ability to undo the actions of a completed activity.
  5. When a custom activity that is decorated with the PersistOnCloseAttribute completes.
  6. When you manually invoke one of the methods on a WorkflowInstance that cause a persistence operation. Examples are Unload and TryUnload. The Load method results in a previously unloaded and persisted workflow being retrieved and loaded back into memory.

It is important to make a distinction between saving a workflow and saving the state of a workflow. Not all persistence operations result in a new serialized copy of a workflow being saved. For instance, when a workflow completes or terminates, the standard SQL Server persistence service (SqlWorkflowPersistenceService) actually removes the persisted copy of the workflow. It persisted the workflow in the sense that it updated the durable store with the state of the workflow. If you implement your own persistence service, you may choose to do something else when a workflow completes.