Nintex Articles

Topic

Nintex Workflow Cloud Design Best Practices
 
Workflow Design

Workflow Action Count (Size):

While there is not a “hard limit” on the number of workflow actions that can be used in a Nintex Workflow Cloud design, it is recommended that designers keep the workflow action count under 250 actions. This recommendation is based not on the workflow engine’s ability to handle the number of actions, but instead is the point beyond which managing the workflow design becomes dramatically more cumbersome. After ~250 actions it can become difficult to track down issues in the workflow design if they should arise. Additionally, should management of the workflow need to be handed off to a new owner, this process becomes exponentially more difficult if great care has not been taken in documenting the steps of the workflow.

Action Labels

All actions within the workflow designer start with a default label such as “Query list” or “Retrieve a record”. It is recommended that after actions have been configured, the label is updated to reflect what the specific action is doing. For example, “Query employee list for new requests” or “Retrieve opportunity information”. This will not only make it easier to remember what various actions are interacting with without needing to open the action configuration panel, it will also make it much easier for other workflow designers to quickly understand what the workflow is doing directly from the design canvas.

Action Sets

It is recommended that workflow designers leverage Action Sets within their workflow designer to help logically group together different parts of the workflow design. This not only helps understand logical break points in the workflow if the workflow is ever broken down into component workflows, but also helps keep the workflow design canvas less cluttered, as action sets can be collapsed to hide the nested actions.

 
For example, these are the same workflow:

 
The action sets allow for a much cleaner and more organized approach to workflow development.
 
Workflow Management

Workflow Description

When publishing workflows it is recommended that all workflows have a description that indicates what the workflow is designed to do. This description will be visible from the workflow list within the tenant and will help other workflow designers know what the workflow does without needing to open and review the workflow definition.

Workflow Versioning Comments

When working with product workflows, it is best practice to enable Version Comments for whenever a new version of the workflow is published. These comments should indicate what changes were made since the last update to the workflow, and the comments will be tied with the respective version of the workflow in the Workflow Versions history. If a previous version of the workflow ever needs to be restored, the workflow owner can review the comments to see what was changed between each publish and make sure that they are restoring to the correct version. Comments can be enforced from within Settings via the Workflow Settings page.

Workflow Tags

Tags can be applied to a workflow either at publish or from the Workflow section under Automate. Tags help group / organize workflows and can make it much easier for workflow developers to be able to find workflows once there is more than a single page of workflows published in the Nintex Workflow Cloud tenant. Tags can be used as filter criteria on the workflow list.

Workflow Error Alerting

By default, if a workflow encounters an error and fails, Nintex Workflow Cloud will automatically alert the user who published the workflow, however you can configure more customized workflow alerting from within Settings under the Alerts page. This can be configured to alert the most recent editor of the workflow, all of the workflow’s owners (defined at time of publish), or a specific set of users, such as the admin users within the tenant.

 
 
Connection Management

Connection Service Accounts

When connecting to third-party SaaS systems, such as Salesforce, Dynamics CRM, or Google Drive, it is recommended that a designated service account is used for production workflows. While connections to these services can be made with personalized credentials (as long as a user has permission within Nintex Workflow Cloud to create new connections), it is recommended that connections with personal credentials only be used in development scenarios. Connections created with personal credentials will only have the individual’s level of access to the third-party systems, and if credentials are updated outside of Nintex Workflow Cloud (such as a password change), this would cause any workflows using the personal credentials to fail until the connection has been re-established in the Nintex Workflow Cloud Connection Manager.

Connection Permissions

Similar to workflow permissions, users who create SaaS connections have the ability to manage which other users have access to use the connection within their workflow design. This can be critical when leveraging service accounts that might have access to sensitive information that you do not want all workflow designers to have access to. Even if a workflow designer has access to a workflow, but not access to the connection, they will find the SaaS actions unconfigured within the workflow designer if they open the workflow definition. You can update connection permissions within the Automate section on the Connections page. Connections can be shared with individual users or Nintex Workflow Cloud groups.

Removing Unused Connections

Because all connections to 3rd party SaaS systems are created using either personal credentials or service accounts, it is recommended that admins regularly audit the connections that have been built in tenant and remove any connections that are not actively being used by workflows.

 
 
Workflow Publishing

Workflow Versioning Comments

When working with product workflows, it is best practice to enable Version Comments for whenever a new version of the workflow is published. These comments should indicate what changes were made since the last update to the workflow, and the comments will be tied with the respective version of the workflow in the Workflow Versions history. If a previous version of the workflow ever needs to be restored, the workflow owner can review the comments to see what was changed between each publish and make sure that they are restoring to the correct version. Comments can be enforced from within Settings via the Workflow Settings page.

Update Existing Production Workflow From Development

As part of the workflow development cycle, some organizations have a dedicated “development” tenant where all changes must first be made, tested, and approved before they can be deployed into production. If the number of changes between production and development are substantial, the workflow owner may want to simply import the updated workflow from development into production. Andrea O’Hara has written a blog post on the exact steps that can be taken to complete this process.

 
 
Additional thresholds to be aware of while using Nintex Workflow Cloud

Maximum number of users in a group: 200
Maximum number of groups a user can be included in: 20
Maximum number of published / draft workflows in a tenant: 2,000
Maximum versions of a workflow: 500
Maximum number of conditions in a single form rule: 15
Maximum number of controls on a form: 2,000
Maximum number of items in a workflow collection: 250

Additional Information

Related Links