Best practices when designing workflows
This page provides a list of recommended best practices for workflow designs and configurations.
Consider using different connections for start events and actions
A workflow can have only one instance running for an item, at any one time. This is achieved through instance locking, which prevents new instances of a workflow from starting for an item until the current instance is completed. If a workflow instance is active for a list item, then the same workflow will not initiate an instance for another event on the same list item.For example, if a workflow is configured to start when an item is updated and includes an action that updates the same item, instance locking prevents new instances from starting when the action updates the current item.
In some situations, the instance lock may not catch workflow instances due to timing issues. To avoid problems with the instance lock, we recommend using different accounts for connections used for start events and for actions. In addition to that, you must configure the start event to ignore events created from or updated by the account that is used for the connection assigned to the workflow action.
For example, a workflow starts only when a user updates an item in a SharePoint list; that workflow also has a SharePoint Online - Update items action that updates the same item. You must configure the start event to use Connection 1 that is an account owned by User 1 and configure the SharePoint Online - Update items action to use Connection 2, which is an account owned by User 2. Then, add a condition to the start event to specify that the workflow will not start if an update is made from Connection 2.
Considerations when configuring Merge collections actions
The Merge collections action dynamically generates the output schema of the action based on the inputs. At design time, infinite loops are created when a Merge collections action uses its own output as its input, or when two Merge collections actions use each other's outputs, causing data to cycle between the two actions. The resulting constant schema updates cause a degradation impact to the overall workflow design experience.
Avoid these configurations:
-
Configuring a Merge collections action to merge its own output
Do not configure a Merge collections action's input field to use the same variable as its output.
For example, instead of merging A and B into C, you merge A and C into C, an infinite loop is created because C is both an input collection and output of the same action.
-
Configuring two Merge collections actions to use each other's output
If a workflow has two Merge collections actions where the second Merge collections action is using the output of the first Merge collections action as its input, do not use the output of the second Merge collections action as the input of the first Merge collections action.
For example, if the first action (Merge document collections) is merging A and B into C, and the second action (Merge document and email collections) is merging C and D into A, an infinite loop is created because the outputs C and A are used as input collections in each action.
