To learn more about email message limits for SharePoint Online workflows, go to the following Microsoft website:
SharePoint 2013 workflow activity can be regulated by two levels of throttling:
- SharePoint Online throttling
- Workflow service throttling
Workflow service throttlingThrottling 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 Online. The workflow service and SharePoint Online 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 Online 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:
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:
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:
We can't find that workflow. Completed instances are automatically cleaned up
Workflow scopesA 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:
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 the following Microsoft website:request is a network call from the workflow service to a SharePoint Online or Project Online 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 during 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 recommendationsThere 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 Online.
- 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 following specific workflow scenarios will also result in throttling.
Scenario 1: A workflow that loops to monitor for changesFor 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 algorithmsWorkflows 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" activityIn 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 Online 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 receiversThe 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 actionYou 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" activityInstead 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. (The steps to implement this option are included.)
- Create a Boolean type variable.
- Set the value to No.
- Insert a parallel block, right-click the block, and then click Advanced Properties.
- In the drop-down, select the variable that you created in step 1.
- Insert two parallel blocks in the inserted parallel block that has the CompletionCondition property.
- 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.
- Set the workflow variable that is used to stop the other parallel blocks to Yes.
- Repeat steps 1-7 for the other choice column values.
- Move the other parts of the original workflow to a position after the parallel blocks.
Option 4: Start a SharePoint 2010 workflow from the SharePoint 2013 workflowYou 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 algorithmsIf your solution demands significant computational tasks, you should consider developing an add-in for SharePoint. For more information, go to the following Microsoft website:
Article ID: 3076399 - Last Review: 29 Dec 2016 - Revision: 1