Due to their nature, workflows do not process the way "typical" applications do. Instead, they have both a synchronous and an asynchronous nature to them. When they initially begin running, whether started manually by a user or programmatically by another process, they run synchronously. In other words, the initiating user or process waits until the initial steps of the workflow finish processing before continuing on. In the user interface, this is seen as the infamous "spinning gears" page.

This synchronous processing continues until the first "commit point" is reached in the workflow. While a full discussion of the SharePoint operations batching and commit points is beyond the scope of this little write up, suffice it to say that any of the following activities in a workflow will signal a commit point:

• Any of the Delay activities
• Any of the Onxxx activities - OnTaskCreated, OnTaskChanged, OnWorkflowItemChanged, etc.

Once that commit point has been reached, the rest of the workflow is processed in background jobs. In other words, all remaining work completed by the workflow is handled as discrete tasks run as SPTimer jobs. These jobs run independently of other processes running in the SharePoint environment.