Best practices when designing workflows
This page provides a list of recommended best practices for workflow designs and configurations.
Jump to:
Use 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.
Reduce the number of actions per workflow
If a workflow design has a lot of actions, break the workflow into smaller component workflows, and call these component workflows using the Call a workflow action. Most workflows have logical breakpoints within the design where a split can be made. Common breakpoints where a workflow can be broken down include:
-
Within a Branch by stage or Run parallel paths action: Each branch can function as a component workflow.
-
After conditional checks: Based on the outcome of the condition, the main workflow may start one component workflow or another.
Look for opportunities to create component workflows where reusable patterns or processes are repeated within multiple workflows. For more information, see Nintex - Component workflow.
Reduce the number of loops and iterations
If loop actions are being used within a workflow design, optimize the workflow by reducing the number of loops and/or iterations within the loops to the absolute minimum.
Add a pause to long workflow loops
If loop actions are being used within a workflow design, add a Pause for duration action to the workflow after approximately 20 iterations (this number can vary). Add the Pause for duration action inside of a conditional Run if true action within the loop. For example, after every 20 iterations of the loop, the workflow will pause for 1 minute.
Reduce the workflow payload size
If a workflow has a large payload size, reduce the payload size by following these best practices:
-
Reduce the output size for queries and/or web service calls. For example, in a Query a list action, you can reduce the size of the query or retrieve the minimum number of records needed instead of the full data set/object. You can reduce the size of the query by using And conditions to only retrieve the applicable records.
-
Reduce the number of query and/or web service actions that retrieve a high number of records.
-
Use fewer branches or nested branches, in addition to the two points above. Design a sequential workflow, if an available option.
-
Use loops with fewer actions that retrieve a high number of records (see the first two points).
-
If multiple unique workflows can be created, break the workflow into separate and unique workflows.
-
Refer to your third-party application's help for guidance on reducing payload size.
Use caution 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.
Best practices for moving workflows across tenants
If you need to move a workflow from one tenant to another, you can export it from the source tenant and import it into the destination tenant. The following best practices will help you import workflows smoothly.
-
Review the connections, data lookups, Xtensions,
-
When you import workflows into a tenant, the connections, data lookups, Xtensions,
For detailed instructions on moving workflows, see Move workflows across tenants.
Best practices for moving workflows across environments
You can use the Configure workflow feature to make moving workflows across environments easier. If any workflow dependencies are moved, you can easily update them using the Configure workflow feature. This feature allows you to configure changes without opening and editing the design of your workflows, thereby maintaining the integrity of the application lifecycle management (ALM) process. Configuring a workflow does not modify the workflow's design and instead only allows configuration updates, decreasing the potential issue of a designer opening a workflow and inadvertently changing the design and breaking the ALM flow.
For example, if a workflow is deployed and it has connection or table configurations that are not available or require mapping, then the Configure workflow feature can detect workflow dependencies and allow you to update them as you move the workflow across environments. For information on common environment setups, see Environments.
Reuse connector object variables
You can reuse object variables multiple times in your workflows within actions of the same connector that have the same structure, making your workflows simpler and easier to manage. This allows workflow designers to create workflows more quickly with fewer object variables. To learn more, see Reuse connector object variables.