Synchronous versus asynchronous workflows

One of the key properties of a workflow is whether it is synchronous or asynchronous. If a workflow is synchronous, it means that if the workflow is launched in response to something that a user did in the user interface, the workflow will begin executing immediately; the user has to wait for the workflow to finish before doing anything else.

If a workflow is asynchronous, it means that the workflow is launched in response to an event that has occurred in the system. When it launches depends on its position in the workflow queue. For example, if the workflow is launched in response to an event that a user triggered in the user interface, the workflow may not start executing immediately; the user can do something else immediately without waiting for the workflow to finish.

Whether a workflow is synchronous or asynchronous is determined by the value of its Concurrence property (described in Start task). In addition to synchronous and asynchronous, the Concurrence property includes a value named subflow. A subflow workflow is a special type of synchronous workflow that allows required parameters. A subflow is special because the only way it can be used is from a Call Workflow task.

Although workflows marked asynchronous are run asynchronously (from the event that triggered it), workflows that are marked synchronous can be run a number of ways. Synchronous workflows are run in-line with whatever caused it to start, and the process causing it will wait until the workflow has finished before it continues. In the case of a form action causing the workflow to run, it means that control will not be returned to the user until the workflow completes.

A workflow that is marked synchronous can also be called. If it is called from an asynchronous workflow, it will be run as part of that asynchronous process. So workflows that are marked asynchronous are pretty clear, but synchronous really means run in-line with the process invoking it.