Avoid workflow throttling

Throttling is one of the biggest issues caused by poor design of workflows. Throttling is done by SharePoint Online to manage fair use of resources and in the context of Nintex for Office 365, throttling can impact the app or single workflow instances. Some of the main causes of workflow throttling are given below:

Best practices to follow to avoid throttling

Jump to:

Reduce the number of operations per request

  • When multiple workflows are running at the same time, if workflows are waiting for a wake-up event, make sure that this event will only affect the workflow running on the current item. For example, when using the Wait for Event in List Item action; if any item on the list is interacted with, workflows waiting on this action will wake up, resulting in a high number of calls being made to the SharePoint environment.

    The preferred alternative would be using an action like Wait for Field Change in Current Item. This action will only wake up the workflow instance if the item it is running on is interacted with instead of any item on the list.

  • Break the workflow definition into smaller parts, and calling these child workflows through the Start Workflow action. This helps reduce the number of requests per workflow instance.

Reduce the frequency of calls

  • If loops are being used within workflow designs, add a try/catch that will pause the workflow after a specified number of loops. This can be accomplished by adding a Pause action inside of a conditional Run If action within the loop that will pause the workflow every X number of loops (for example after every 20 iterations of the loop, the workflow will pause for 1 minute).

  • If a workflow contains any loop logic (loop/for-each/state machines) consider leaving out actions such as Log to History List as they can quickly fill a workflow history list if left unchecked, and result in a large number of calls being made to the SharePoint environment.

  • Identify and remove workflows that are designed to do any of the following:
    • Retrieve information from hundreds of SharePoint items.
    • Update hundreds of SharePoint items.

Split large workflows

Split large workflows into smaller sub workflows with fewer actions. This reduces the number of requests from a workflow instance. For more information about splitting workflows, see Splitting large workflows.

While the final design of how to break down individual business processes will be up to your design team and business owners; most workflows have logical breakpoints within the design where a split could be made. Here are some examples of when a workflow can be split:

  • Within State Machine: Each branch can function as an independent workflow.

  • Within Parallel Blocks: Similar to State Machines, each branch of the Parallel Block can sometimes be broken into its own process.

  • After conditional checks: Based on the outcome of the condition the parent workflow may start one child workflow vs. another.

Considerations when using Nintex Live actions

In order to bring additional functionality to the SharePoint Online workflow platform, Nintex has leveraged our Nintex Live service to help extend the available actions within our workflows that are running within SharePoint Online.

Actions that utilize Nintex Live

  • Assign a Task (with LazyApproval enabled)

  • Adobe Sign

  • Document Generation

  • Execute SQL

  • Office 365 workflow actions

  • Pause for Duration (when 'with business hours' is enabled)

  • Query XML

  • Send an Email

  • Start a Task Process (with LazyApproval enabled)

  • Start Workflow

  • Start Workflow in Nintex Workflow Cloud

  • Terminate Current Workflow

  • Translate Document

  • Update XML

  • Web Request

The actions below also use Nintex Live, but are acquired through the Nintex Store inside of the designer:

  • Amazon workflow actions

  • Bing workflow actions

  • Bitly URL shortener

  • Box workflow actions

  • DocuSign workflow actions

  • Dropbox workflow actions

  • Exchange Online workflow actions

  • Facebook wall post

  • Google workflow actions

  • LinkedIn workflow actions

  • MailChimp workflow actions

  • Microsoft Azure workflow actions

  • Microsoft Dynamics CRM workflow actions

  • OneDrive workflow actions

  • Rackspace workflow actions

  • Salesforce workflow actions

  • StrikeIron workflow actions

  • Twitter workflow actions

  • WordPress new blog post

  • Wunderground weather

  • Yammer workflow actions

Live Action Considerations

The actions that work with Nintex Live bring incredible extensibility to the workflows that can be designed within Office 365. Here are a couple points to remember when using the Live actions:

  • Action execution time: Due to the actions making authentication calls, and the web service calls to various parts of SharePoint Online, Live actions may take slightly longer than a native workflow action to execute. This can vary from one minute to five minutes depending on the particular Live action.

  • User authentication:

    • As the actions are making calls out to Live and then returning data back into SharePoint, the actions each have part of their configuration that calls for user's credentials.

    • The user specified within the configuration will need permissions to perform the respective workflow action (if using the Office 365 Create List Item action, the user specified within the configuration must be able to create a list item).

  • Security between Office 365 and Nintex Live when an action is executed:

    • All communication is through Transport Layer Security (TLS)

    • Below is an outline of how communications take place:

      • At Design Time:

        • The workflow designer configures the relevant Live actions from within the Nintex workflow designer.

        • When the workflow is published, any sensitive configuration options are encrypted from within the Nintex for Office 365 application. Nintex for Office 365 is built to automatically treat credential passwords as sensitive information and encrypted.

        • All encryption is in memory. There is no storage of unencrypted credentials as part of the workflow publishing process.

        • The published workflow definition contains the encrypted item, not plain text.

    • At Run Time:

      • When the workflow executes, the workflow sends the action configuration, including the encrypted information, to Nintex over secure TLS.

      • The credentials are then decrypted in memory before sending it to the Nintex Live routing engine also within the Nintex Live/Windows Azure infrastructure.