December 4, 2020

The article below concerns Nintex Workflow Cloud. Nintex Workflow Cloud is a cloud-based platform where you can design workflows to automate simple to complex processes using drag-and-drop interactions without writing any code. You can build digital forms, integrate web services, and connect to third-party applications to create a seamless experience for your end users throughout the workflow.


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:


butlerj_0-1605889883787.png

 


butlerj_1-1605889895400.png

 


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




 


 


You May Also Like…

Remove The Account To Configure Azure Active Directory Identity Federation After Completed The Setup

Topic

Can we remove the Admin account that is used to configure the Azure Active Directory identity federation after the setup has been completed? 
 

Additional Information

Yes, you can remove this Admin account after successfully finishing the setup and it will still work even after the account has been removed. 
 

Related Links

https://help.nintex.com/en-US/nwc/Content/Settings/ConfigureAzureAD.htm
 

Nintex Workflow Cloud Forms – Data Source Variable FAQ

Topic

Frequently asked questions about Data Source Variables in Nintex Workflow Cloud Forms.
 

What are Data Source Variables?

Data Source Variables are a new capability that is available within Nintex Workflow Cloud Forms that enables designers to source data from external systems into their forms design and use that data across various different controls and rules. Like the Data Lookup control, Data Source Variables leverage existing data sources within Nintex Workflow Cloud to connect to external systems but aim to provide more flexibility with the data than the drop-down styling of the Data Lookup control.

 

Can anyone create a Data Source Variable?

Designers that have been given permissions to a data source within Nintex Workflow Cloud can create new Data Source Variables.

 

Can Data Source Variables be used with any control type in Nintex Workflow Cloud?

Currently Data Source Variable values can be used with Label controls and can be set as the value of Text – Short, Text – Long, Email, Currency, Number, or Geolocation control via rules. Support for additional controls such as Choice – Single and Choice – Multiple will be available in the future.

 

Can any data source be used to create a Data Source Variable?

Currently Data Source Variables only support SharePoint Online and Azure Active Directory data sources, however additional data sources will be made available in subsequent releases.

 

Can a custom Xtensions based data source with Data Source Variables?

Not yet, but this functionality should be available soon.

 

Can I use my Data Source Variables within my workflow?

While any values that are used in a control will be passed to the workflow as a start event variable, the Data Source Variable itself is only available within Forms at this time. If a workflow designer would like to access the same information, they can use a ‘Query’ action as this will return the same object/data as the Data Source Variable.

 

Additional Information

 
 

Related Links