How Workflows are executed in SharePoint

The following summarizes how workflows are executed from start to finish:

1. A person or process initiates some action that causes the workflow to begin. In SharePoint, workflows can be:
   • Started on demand by a user by using the SharePoint user interface.
   • Started or resumed in response to the On Item Created event for an item in a list or document library.
   • Started or resumed in response to the On Item Changed event for an item in a list or document library.
   • Started or resumed programmatically through the SharePoint object model.
   • Started programmatically through the Workflow Web service.
2. Once the workflow begins a process is created to execute tasks or actions in the workflow code. Not all workflows use the same hosting process.
   • Workflows started from the SharePoint user interface use the W3wp.exe process that is specific to the IIS Web application the workflow was initiate from.
   • If the workflow uses DelayActivity code or has a noncatastrophic error when the workflow instance begins then the Owstimer.exe server process is the host process. The Owstimer.exe is the SharePoint timer service process and is used in this context to start workflows when DelayActivity code is used or to try executing a failing workflow again at a later time.
   • When an external application (such as a console application, Web service, or Windows Communication Foundation service) creates items programmatically through the SharePoint object model, the process running the code becomes the workflow host.
3. The workflow determines what action needs to perform next and executes the code.
4. If the workflow needs to wait for a response before it can continue, then the SharePoint event handlers tell the Windows Workflow Foundation Runtime Engine to put the workflow to sleep using the SQL workflow persistence service.
   1. When a workflow becomes idle the Windows Workflow Foundation Runtime Engine calls the SQL workflow persistence service to save the workflow state into the content database of your SharePoint website.
   2. The SQL workflow persistence service assigns correlation tokens for the workflow and to each task as that the workflow engine can use unique identifiers to map events and actions to the correct workflow object. Next, the SQL workflow persistence serializes the workflow object turning into a binary string, and then saves it with a unique Workflow Instance ID to the SharePoint content database. This process is called dehydration.
   3. Once the workflow object is safely stored within the database the memory used to run the workflow is released and the workflow is considered to be put to sleep.
5. When SharePoint receives a response to carry out the next action from ones of its event handlers, the Windows Workflow Foundation Runtime Engine wakes up the sleeping workflow using the SQL workflow persistence service. When the new response data and the data from the store workflow object the workflow can run the code to perform the remaining actions.
   1. When a user or system respond to a workflow action, the unique Workflow Instance ID is passed to the Windows Workflow Foundation Runtime Engine and SQL workflow persistence service finds the workflow object in the SharePoint web application’s content database.
   2. When the Windows Workflow Foundation Runtime Engine retrieves and deserializes the workflow object from the database, it performs many checks to ensure that the workflow object is mapped to the correct response. The checks ensure the workflow DLL has the correct namespaces, entities, and correlation tokens. The process of retrieving the workflow object is called hydration.
   3. Once the workflow object is successfully retrieved and passed all its checks the workflow is awake and is able to execute the rest of the action code.
6. Steps 3 to 5 are repeated for each action as necessary until the workflow is complete. Once the workflow is complete, the workflow status is updated and the workflow memory and hosting process are released.