The following is a cheat sheet which is ever evolving as I continue to use Nintex products with various business scenarios and cases. Some quick links for reference and lesson learnt from the fields which I need to remember and which you may fine useful.
A lot of these points and link apply to both SharePoint Server and SharePoint Online environment, though they have progressively parted in functionality over time, with the Nintex cloud environment being completely different.
- Nintex Service Status
- Nintex Product Releases Notes
- Nintex Product Roadmap
- Nintex Customer Portal (Product Downloads)
- Nintex Help Documentation
- Nintex Partner Portal
- Nintex User Voice / Feature Requests
Notes from the Field
Workflow Architecture – State Machines
General a SM workflow is the way to go, its simpler to follow and can allow restarting workflow where they left off if you save the state back to the list and have the workflow read that on start.
Workflow History List
This is a hidden list on the site (which can be made visible via SPD), this list stores all the logs and task actions you see on the workflow history page. This list can get very large which is why the workflow cleanup timer job removes the workflow association to this list. Best practice would be to create a workflow history list for each workflow, and only write log entries when needed, remove debugging actions when not needed.
Workflow Auto Cleanup Timer Job
Doesn’t apply to SP2013 workflow manager workflow but needs to be considered for SP2010 workflows. Simple option is to turn off, though you may risk system issues, or you can plan for it to get and outcome to best meeting auditing needs. Applies to workflows 60 days after the workflow is completed or cancelled.
MSDN:SharePoint Workflow Auto Cleanup
DocuSign integration using the Nintex Action is very limited, and don’t expect any enhancement not Nintex have partnered with Adobe Sign, which may be worth considered as an alternate. Action only support single signature for automate envelopes, and you can’t download the combined final document. Only option is to create a custom web service which you can call via a web request action which then calls the DocuSign API performing actions such as attachment uploads and combined final document download.
Not a bad service option, though has its limitations, namely Rich Text column support. It will support rich text such as OL and UL but not much else, and you’ll need a bunch of regex actions to clean up list data to remove class=””, <p>, <br>, style=”” e.t.c. or the service will error out.
Multiple Instances of a Workflow Running
When a new version of a workflow is published it sets the old to “No New Instances” and when triggered the new will start… even if an old version instance is running, which can cause great confusion and issues. I generally get around this via having a custom “workflowrunning” column which is default no and i’ll set to yes and no via a running workflow, with a condition on the start of the workflow to only run is that column is equal to no.
Best Practices from the Community
I don’t believe in “best practices” in general as you need to match what is best for each given situation or requirement, but linked below are some reference points.
- Nintex Workflow Best Practices
- 5 Best Practices for Stellar Workflow Design
- Nintex Workflow Office 365 Best Practices
- Best Practices for Using Nintex Workflows
– Not responsive design, but can design a form for each device type (lots of work/maintenance)
– useful for very basic form to make then not look like SharePoint
Notes from the Field
Form Save Conflicts
When a Nintex form opens a item, it takes note of which version it opens, but doesn’t lock the record for others to edit. If the item is edited via another user/workflow it will modify the version number, and subsequently when Nintex goes to save it will conflict and the user will loose all form edits.
Beware of “Save and Continue” button as a workflow may run on modify and update record, and also manually updating list items causing a conflict.
Publishing a New Form Causes Save Conflicts
If a user has a form open, avoid publishing a new form until it is saved as it will cause a save conflict and all form edits will be lost
Nintex University – Basic Video instructions from Nintex