Best practices when designing workflows

This page provides a list of recommended best practices for workflow designs and configurations.

Jump to:

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.

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

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.

Incorrect configuration of multiple Merge collections actions

Moving workflows across tenants

To move workflows from one tenant to another, you can export them from the source tenant and import them to the destination tenant. Connections, data sources, and component workflows used in your workflows are not exported, so to ensure that the imported workflows are migrated as smoothly as possible, you must create the connections, data sources, and component workflows in the destination tenant.

  1. Review the connections, data sources, and component workflows used in your workflows in the source tenant and identify what you have to create in the destination tenant.

  2. Export the workflows you want from your source destination. For more information, see Export a workflow.

  3. Create the required connections, data sources, component workflows in the destination tenant.

    In order for the imported workflows to work as expected, it is important that the connections, data sources, and component workflows have identical names, security settings, and permission levels as the ones in the source tenant.

    Important: 

    • In order for the imported workflows to work as expected, it is important that the connections, data sources, and component workflows have identical names, security settings, and permission levels as the ones in the source tenant.

    • Importing custom Xtensions is not currently supported.

    For information, see the Add a connection, Create a data source, and Nintex - Component workflow help topics.

  4. Import the workflows to the destination tenant. For more information, see Import a workflow.

Note the following about the connections, data sources, and component workflows configurations in the imported workflows:

  • If there is already a connection, data source, and component workflow with the same ID in the destination tenant, the imported workflow will use them.

  • If the ID does not exist, but there is an existing connection, data source, or component workflow with the same name in the destination tenant, the imported workflow will use them.

  • If there is no matching ID or name, the connections, data sources, and component workflows will be unconfigured, and they must be reconfigured manually.