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.

Example of a workflow with start event and action that updates an item

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.

Incorrect configuration of multiple Merge collections actions

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, tables, and component workflows used in your workflow in the source tenant, and identify what you need to create in the destination tenant.

  • When you import workflows into a tenant, the connections, data lookups, Xtensions, tables, and component workflows in the imported workflow are checked against what's already in the tenant, matching them by ID or name. Create any required connections, data lookups, component workflows, tables, and Xtensions in the destination tenant before importing your workflow. In order for the imported workflows to work as expected, these items must have the identical names, security settings, and permission levels as the ones in the source tenant.

For detailed instructions on moving workflows, see Move workflows across tenants.

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.