Nintex is becoming ubiquitous in the global IT landscape as adoption increases in their cloud offerings building on top of their highly successful on-premises solutions. Because of this, knowledge of good workflow design and development practices specific to Nintex is paramount.

Here below is a short list of key tips to help optimize performance and maintainability of your solutions. 

Tip #1 - Use Workflow Constants

One of the best features with Nintex on-premises is their ability to store credentials for a service account as a workflow constant. When a credential has been created, you can use those credentials without having to know the name and password of the account. The credentials are stored in the Nintex Workflow configuration database and are encrypted with DES encryption. Workflow constants can be created at the Site, Site Collection, or Farm level. You can see how it gets setup in the image below.

Tip #2 - Processing and Load

Only affecting on-premises, a consideration that is often overlooked is the effect on performance of different actions within the workflow which can slow down its execution affecting performance. 'Execute SQL' or 'Query LDAP', for example, require more processing while 'Log to history list' and 'Build dynamic string' require much less. Nintex recommends breaking actions with a heavier load out to their own separate sub workflows.  

Any updates to the list, start/stop workflows, or update XML actions do not get processed immediately and are not necessarily executed in the order of the workflow. These actions will be batched up and executed according to what type of actions they are – Nintex or Microsoft. For example, this:

will actually execute as this:

This is happening due to the Nintex actions getting batched together and executing before the Microsoft "Update List Item" action. Another wrench in this puzzle is that although the Nintex batch may start first, it may not complete execution prior to the Microsoft action. You might think to put a 'Commit pending changes' action after the Microsoft action but that is still not a guarantee. The permissions action, for example, takes longer to complete and can possibly end after the 'Update List Item' action. It is better to use 'Pause for Duration' and set it to at least 30 seconds to make sure all the actions have completed before continuing. Alternatively, you can also use 'Wait for Field Change in Current Item' if that works for you. If you are on Office 365, Nintex for Office 365 does not have 'Commit pending changes' so you should replace it with a 'Pause for Duration' or 'Wait for Field Change in Current Item' action.

Tip #3 - Build Your Content

When designing your workflow, in O365 or on-premises, it is ideal to have a workflow that has the smallest number of actions. The benefits are in reduced server load, speed of execution, and reduced complexity. One of the recommended techniques used in developing workflows is building your content by adding relevant information to a variable as it becomes available.

For example, email body content often has to be formatted using basic HTML to display tables and other formatting. This can be built in a variable as the data is collected. Using a "Set Workflow Variable" action, you can set the variable to itself plus the additional formatting and data. So a var_EmailBody variable would have a value of "{Variable:var_EmailBody}<TR><TD>my new data</TD></TR>" when adding new data.

 The results of this method are very apparent. Workflows that previously looked like this:

Can now start to resemble this:

Resulting in less actions, faster execution, and a better workflow overall.

Tip #4 - Avoid Getting Throttled in SharePoint Online

One of the most frustrating things that can happen when running a workflow is for it to get throttled or even completely blocked. This happens when the number of user calls is too high and it exceeds a threshold. A scenario where this might occur would be updating properties or lists in SharePoint Online in a batch to keep it in sync with another line-of-business application. The result is being redirected to the throttling page with failing requests, REST calls returning a 429 "Too many requests" error, or worse getting completely blocked with a 503 "Service unavailable" error.

While SharePoint Online can handle a high volume of calls, good workflow design practices should still be followed so this can be prevented. Keep an eye on the number of looping iterations to make sure they are not causing hundreds of updates and requests at a time. In the case where a high number of immediate updates are required, consider including pauses in your loops to alleviate the load and decrease the chance of getting throttled. 

Tip #5 - Workflow Version Control in Office 365

A great feature of Nintex on-premises is how versions are maintained when a workflow is saved or published. This allows you to access prior versions of your workflow, export it, and more. It is something that protects your workflows and their development.

Unfortunately, the current version of Nintex on Office 365 does not support this feature but it can still be emulated with the use of versioning in document libraries. First, create a document library with versioning turned on called "Nintex Workflow Backups". Then whenever you would like to back up the current version of your workflow, export the workflow and add the file to the document library. Be sure to include comments of the changes made since the prior version. This best practice helps you and others that wish to review the developmental progression of the workflow.

For those that are looking for full versioning, please review the request on Nintex User Voice:  Version Control and be sure to up-vote it!

Tip #6 - Set Error Notifications

Another feature within Nintex on-premises is setting up error notifications. Whenever a Nintex workflow errors, it will send an email notification letting you know of the error and the workflow it occurred in. Setup is in Central Administration and applies for all workflows. While this feature is not available in SharePoint Online, there is a simple workaround. Go to your workflow history list and create a workflow that runs on new items. Set the workflow to do a "contains" on the description field. Whenever the word "error" is found, send an email notification. This method also has the advantage of being workflow-specific allowing you to send notifications to different users.

There is also a user voice topic for Nintex User Voice:  Workflow Errors. 

Tip #7 - Use Child Workflows

When a business process is very complex or when multiple different processes use the same sub-process, child workflows can be created to reduce the complexity by separating or sharing functionality across different workflows. They reduce complexity by having multiple instantiations from separate workflows point to a focused process for execution. Child workflows are an act of process recycling that leads to easier testing and better performance.

One example of the use of child workflows would be purchasing requests. Imagine a company with several departments – Information Technology, Human Resources, and Marketing – each having their own separate requisition workflows. The requisitions first have to pass departmental approval and then get sent to Accounting where the actual requisition is processed. Rather than copy that Accounting process in each workflow, a child workflow would be created and called from each original workflow. Another advantage to this method is that when the Accounting process changes, only one workflow requires updating.  

Tip #8 - Consider Office 365 When Developing Your On-Premises Workflows

With companies moving more and more to the cloud every day, it is important to consider the ramifications of decisions made when designing an on-premises Nintex workflow. While Nintex is improving its online products every day, all actions are not currently supported by SharePoint Online or migration tools. With products like Sharegate, unsupported actions will be replaced with a placeholder action that has the name of the original unsupported action. This lets you maintain the structure of your workflow and easily replace them with supported actions.

Another consideration to remember is that the Nintex workflow history will not migrate. Custom workflow actions or user-defined actions will also not migrate so try to use the out-of-the-box actions as much as possible. And remember that the last saved version of the workflow will migrate, not the last published version, so be sure to keep good habits on your version control.