Sharepoint 2013 workflow throttling and performance in sharepoint online and project online

Introduction

This article contains information about throttling scenarios and limitations for workflows that use the SharePoint 2013 workflow platform type in SharePoint and Project in Microsoft 365.

Note: SharePoint 2010 workflows have been retired since August 1, 2020 for new tenants and removed from existing tenants on November 1, 2020.  If you're using SharePoint 2010 workflows, we recommend migrating to Power Automate or other supported solutions. For more info, see SharePoint 2010 workflow retirement.

More Information

To learn more about throttling in SharePoint, go to How to: Avoid getting throttled or blocked in SharePoint.

To learn more about email message limits for SharePoint workflows, go to "Daily email limit has exceeded and your workflow has been suspended" error in SharePoint.

SharePoint 2013 workflow activity can be regulated by two levels of throttling:

• SharePoint throttling

• Workflow service throttling

Workflow service throttling

Throttling is performed to allow for fair resource usage. It also protects the environment from harmful workflows and workflows that don't follow best practices. Workflow service throttling isn't controlled by SharePoint. The workflow service and SharePoint are two independent services, and each service throttles requests in the interest of overall service health. In the workflow service, throttling is performed at the workflow scope level that aligns with SharePoint sites. Throttling isn't globally accounted for. Instead, each workflow back-end service tracks a workflow scope's usage independently. There may be one or more workflows in a workflow scope. Workflow throttling is dynamic and will be reevaluated periodically by workflow scope and by workflow service back end. 

The Workflow service also limits the number of outbound requests that a single workflow instance can generate. In a 24-hour period, a single workflow instance can generate up to 5,000 outbound requests. After 5,000 outbound requests are generated in a 24-hour period, the workflow is suspended by the Workflow service.

The Workflow Status page for the workflow will contain information about the suspended workflow. In this scenario, the information balloon for the Internal Status will display the following message:

• The instance has exceeded the outbound http request quota for a 1.00:00:00 time period. The 5000 request limit was reached in <time>.
  
  NOTE: The <time> placeholder represents the time that it took to reach the 5,000 request limit for your workflow.

You can resume the suspended workflow instance by clicking Resume for the workflow or by using the SharePoint Workflow Client Object Model after 24 hours have passed. This must occur before the workflow is terminated.

If the workflow exceeds the CPU usage limit, the Workflow Status page for the workflow will contain information about the suspended workflow. In this scenario, the information balloon for the Internal Status will display the following message: 

• The workflow instance exceeded the CPU usage limit of throttle of 00:00:01.2000000 and could not be unloaded because it was not persistable.

Suspended workflow instances will be terminated after 10 days. The information balloon for the Internal Status will display the following message if the workflow is terminated:

• System.Activities.Statements.WorkflowTerminatedException: The instance has been moved from the Suspended state to the Terminated state because it has expired.

A terminated workflow will eventually be cleaned up. After a terminated workflow is cleaned up, it will display the following message:

• Sorry, something went wrong.
  We can't find that workflow. Completed instances are automatically cleaned up

Workflow scopes

A workflow scope is defined as a site in a site collection. For example, the following URL is for a root site collection and is considered a workflow scope:

    https://contoso.sharepoint.com/sites/rootsite

An example of another workflow scope that's in the same site collection is as follows. However, this workflow scope is in a subsite.

    https://contoso.sharepoint.com/sites/rootsite/subsite

What's a request?

SharePoint 2013 workflows are built upon the add-ins model for SharePoint, and they use REST APIs to interact with SharePoint data. To learn more, go to Get to know the SharePoint 2013 REST service.

A request is a network call from the workflow service to a SharePoint or Project REST API endpoint. There's no difference between the kind of request or the response for a given request. An action and its composing activities don't contribute to the request count unless the request involves a SharePoint 2013 REST API. For example, the Log to History List action may generate five or more requests for a healthy operation. Also, retry logic is built into workflows in case something goes wrong. This can generate additional requests.

Many actions produce requests, and requests can be minimized by using best practices. For example, you can use a single Update List Item action instead of multiple Set Field in Current Item action to reduce the number of requests being made by a workflow scope, and yet achieve the same results. 

Workflow design recommendations

There are many ways to generate lots of requests in a workflow that can result in throttling. Some general examples are as follows:

• A single aggressively looping workflow or multiple aggressively looping workflows

• A workflow that is associated with a list or library while content is being migrated into SharePoint.

• Previous problematic workflow versions that were corrected and that continue to run workflow instances that have the problematic configuration until the workflow is terminated.

The workflow scope throttling that is enforced by the workflow service should allow for typical workflow use case scenarios. However, as a workflow's logic grows more sophisticated, the workflow can exceed safe limits.

The following specific workflow scenarios will also result in throttling.

Scenario 1: A workflow that loops to monitor for changes

For example, you could check an item for updates instead of waiting for an item to be updated.

Scenario 2: Using a workflow to execute complex algorithms

Workflows are intended to manage document-driven, human processes and not to dispatch significant computational tasks.

Scenario 3: Having multiple workflows running that use the Wait for Event in List Item" activity

In this scenario, each workflow will listen for changes in the target list. If there are many workflows running, each workflow will have to react to the raised event and possibly call back into SharePoint to perform some work. 

NOTE: This can also occur if there are many changes to a list for which a workflow is configured to start when an item is created or changed.

Alternatives to scenario 1: A workflow that loops to monitor for changes

Option 1: Use SharePoint add-ins and external event receivers

The workflow design should be reevaluated, and a different design approach should be used. SharePoint add-ins or external event receivers are more appropriate for this task.

Option 2: Add a pause action

You can improve the design of the workflow somewhat by adding a delay (that is, a pause action). This should reduce the traffic that is generated. However, it doesn't change the overall shortcomings of this design.

Option 3: Use the "Wait for Field Change in Current Item" activity

Instead of looking for changes by using a loop, it's better to use the default event receivers. A workflow can be started when an item is created or changed. Executing multiple workflow instances instead of having one workflow in an aggressive loop is a better approach. The conditions in the workflow can be configured to perform work only when it's needed.

Only one workflow instance of a workflow can be running at a given time. 

Another approach is to use the Wait for Field to Change in Current Item activity. 

The workflow design can use a choice column that has multiple values to drive the workflow execution. Only when an appropriate option is picked by an end-user will the workflow resume. This can prevent aggressive looping and unnecessary workflow instances from being started. The workflow executes when the item is ready instead of executing or starting multiple instances.

You can monitor for multiple values from multiple fields by using multiple parallel blocks. The workflow can wait for a specific state and then continue to execute down a given path, as in the following example:

1. Create a Boolean type variable.
   
   

2. Set the value to No.

3. Insert a parallel block, right-click the block, and then click Advanced Properties.
   
   

4. In the drop-down, select the variable that you created in step 1.

5. Insert two parallel blocks in the inserted parallel block that has the CompletionCondition property.
    

6. In the first of the two parallel blocks that you inserted in step 5, insert the Wait for Field Change in Current Item activity. Change the activity so that it's monitoring a choice column. Do not monitor the default choice.

7. Set the workflow variable that is used to stop the other parallel blocks to Yes.

8. Repeat steps 1-7 for the other choice column values.

9. Move the other parts of the original workflow to a position after the parallel blocks.

When one of nested parallel blocks has all its activities executed, the parent parallel block will end the other activities in the other parallel blocks. This enables the workflow to continue. The nested parallel blocks are monitored by the parent parallel block by using a variable.

Option 4: Start a SharePoint 2010 workflow from the SharePoint 2013 workflow

You can use the SharePoint 2010 workflow platform type to perform some of the work that the SharePoint 2013 Workflow Platform type is performing. This can reduce the number of requests.

Specifically, a SharePoint 2010 workflow can be started to monitor field changes by using the Wait for Field Change in Current Item activity or to perform many other basic operations.

Alternative to scenario 2: Using a workflow to execute complex algorithms

If your solution demands significant computational tasks, you should consider developing an add-in for SharePoint. For more information, go to SharePoint add-ins.

Still need help? Go to the Microsoft Community.