Skip to main content
Nintex Community Menu Bar

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

Hi Tao,

I am not sure I follow you. Are you saying that when you start a workflow that particular instance stops and a new one is started?

Aaron - my understanding here is that the benefit of adding a Pause for the first action applies to site or list workflows that are started manually.  There is no benefit for using an initial Pause action on list workflows that are always started on Item Created or Modified.  Is that correct?

Hi Tom,

Actually, all workflows should have a pause as the first action. The main benefit to doing this is that when you pause a workflow you are causing the workflow to be persisted to SQL and rehydrated in the Workflow Timer Service instead of in the IIS Application Pool process.

Microsoft recommends that the workflow be persisted and moved to the Timer Service as quickly as possible.

couldn't this be done internally by nintex workflow by design?

we need not to bother then whether to add an pause to the workflow or not...

I don't think that it's a good idea to automatically add it because it adds up to five minutes in the workflow execution time and in some business cases it can be a problem if the execution of the workflow takes so much time...

I would see it as benefit just in the case of very simple workflows that do not require user input, external interaction (query list, web service call..), that do not update items,do not use loop, do not use state machine, do not process huge set of data and several other preconditions.

in all these cases you can not rely on workflow execution time, and I wonder whether it's possible at all to build a real business case workflow without all of these.

but ok, if there are cases when not doing a pause is needed, I would still see it better to have some checkbox in workflow settings or on workflow start screen.

maybe it could even be evaluated automatically in background by looking at what action are used in workflow, and if there are not any "critical" action then do not do pause.

I like your idea to have a checkbox in the settings of the workflow. I think that you can add your idea in Nintex user voice and post the link to your idea there and I will vote for it :

Customer Feedback for Nintex

Aaron - Regarding your comment above, ("change state action does cause the workflow to dehydrate") I just did a test of this with a state machine and there was no delay after each change state or when it initially entered the state machine.  Can you clarify this further?

Aaron Labiosa‌, what does it mean if I add a "Pause For" at the beginning of a workflow and I see no noticeable difference in how long it takes for the "Waiting for workflow to start..." screen to go away?  Is there a generally accepted amount of time it should take using this method?

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings