Planning ahead

Speed is typically a business requirement when designing a workflow; however, sometimes the appearance of speed is just as good as the real thing. Adding a 'Pause for...' action as the first action of a workflow will actually have the illusion of being much faster to end users. Additionally, starting workflow designs with a pause has the added benefit of increased durability.

Performance

Adding a pause to the start of a workflow will force the workflow instance to immediately dehydrate and persist to the SharePoint Content Database. A workflow executed by a user will show a 'Working on it...' message to the user until completion or dehydration (This has the appearance of sluggishness). The quicker you can dehydrate the workflow, the quicker the workflow will appear to users. Reference: Workflow Scalability and Performance‌

SharePoint has limits set (by default this is 15 workflows) that can make a workflow even slower depending on how often workflows are being started (excluding workflows that are running in the OWSTIMER process on a given SharePoint Content Database (Could be multiple site collections, etc)). Reference: Workflow Limits

Durability

When using event receivers (ItemAdded or ItemUpdated) to trigger your list workflows there is a possibility that SharePoint will not have fully instantiated the item and or all of its properties by the time the event receivers fire and start the workflow. The reason for this is that the initial event receivers that trigger: ItemAdding and ItemUpdating are synchronized however, the subsequent ItemAdded and ItemUpdated events are Asynchronous (meaning they complete without actually waiting for the item to be added/updated).

In order to be completely sure that the item is ready in SharePoint prior to the workflow executing, we need to add a delay prior to the workflow attempting to reference any properties of the item. Determining whether or not a workflow will run before the properties are ready is a fairly difficult if not impossible task as there are many variables to consider:

• Size of the farm
• Resource Utilization of the farm
• Size/complexity of the item or document being updated/created.

Design Considerations

• Actions that create/update new items/folders/documents may have similar issues to those discussed in the 'Durability' section.
• The quicker you can dehydrate the workflow instance and persist it to the SharePoint Content database the better (First action of the workflow ideally).

Workflow life cycle (for a workflow started manually)

1. The workflow is started in the Web Application Application Pool Process (W3wp.exe).
2. The user sees a message indicating SharePoint is 'Working on it...' until the workflow does one of the following:
   1. It completes.
   2. it is terminated/error.
   3. It is dehydrated and persisted to the SharePoint Content database.
3. If the workflow was persisted to the SharePoint Content database it is later re-hydrated by the SharePoint workflow timer job (which occurs every 5 minutes by default).
4. The SharePoint workflow timer job picks a server in the SharePoint farm that is running the 'Foundation Workflow Infrastructure Timer Service' and that server has a turn at executing workflows that were previously dehydrated and persisted to the SharePoint Content Database (Hence the importance of Defensive Workflow Design Part 2 - SharePoint Topology ).
5. The workflow will continue to run until it completes or it is time for it to be dehydrated again where steps 3 and 4 happen again.

Workflow life cycle (Event Driven)

1. A synchronized event for ItemAdding or ItemUpdating is triggered.
2. An asynchronous ItemAdded or ItemUpdated event is triggered by an event from step one.
3. The workflow is started by an event from step two.
4. The workflow runs until it completes or is dehydrated and persisted to the SharePoint Content database.
5. If the workflow was persisted to the SharePoint Content database it is later re-hydrated by the SharePoint workflow timer job (which occurs every 5 minutes by default).
6. The SharePoint workflow timer job picks a server in the SharePoint farm that is running the 'Foundation Workflow Infrastructure Timer Service' and that server has a turn at executing workflows that were previously dehydrated and persisted to the SharePoint Content Database (Hence the importance of Defensive Workflow Design Part 2 - SharePoint Topology ).
7. The workflow will continue to run until it completes or it is time for it to be dehydrated again where steps 3 and 4 happen again.

More Information

Defensive Workflow Design Part 1 - Workflow History Lists

Defensive Workflow Design Part 2 - SharePoint Topology

Defensive Workflow Design Part 3 - Separation of Concerns

Defensive Workflow Design Part 5 - Batching