Effectively Managing Nintex Workflow History

It's common practice to exploit Nintex workflows to further extent. Sometimes due to limited technologies or limited control over SharePoint environment, most of the organisations decide to use Nintex workflow as a ETL tool. Also used for replacing C# code with  Nintex workflow. The Nintex workflow with a robust design works fine but as it's built over SharePoint workflow engine, a small issue in worker process or timer job can hamper the workflow execution.

A badly designed workflow can soon overload workflow history list which can deteriorates the performance of the workflow.

Lets assume a use case where Server Access management process is implemented using Nintex workflow. To grant access to a server the request should be approved by two users, an appropriate permission should be setup to secure the metadata and update the request metadata during request life cycle.

To achieve the above use case, the nintex workflow will have 2 request approval activities, 2 Update list item activities, 2 Set permission activities, 2 pause activities (for safe delay) and may be some error handling technique to log additional data into history list.

With the above workflow design (Consisting Request approval, Pause for and Log into history list) below number of entries will be logged in workflow history list.

Workflow Activity	Number of entries logged in history list
2 Request Approval (On Approval or Rejection)	2
2 Pause for	4
Error Log or Informative Data	2

As you can see a single instance of workflow execution logs 8 entries in Workflow History list for simple process. Assuming on a average 5 requests are processed in a day by workflow and 100 are processed in a month the entries created in history list will be 800 per month and for a year it will be 9,600 entries and 48,000 entries in 5 years which is enough to slow down the workflow. 

We are talking about only one simple workflow and in a scenario where a same workflow history list shared with other running workflows. The list entries can grow exponentially in a short span.

Nintex today does not provide any functionality to switch to a new workflow history list in case items created in workflow history list exceeds the threshold value. In my experience larger the number of items in history list slower the workflow execution, Higher the number of workflow failures.

So Do we have any solution which can be put in place by developers/designer to ensure that their workflows are running efficiently?

"Information management policy" can be used to define the retention policy. Based on the auditing requirements a retention policy can be defined on a workflow history list which can then either delete the items or archive them to a different list.

Do you need Nintex forms or MS Infopath?

With emerging web technologies targeting rich user experience and to provide a boost to SharePoint we have Nintex forms (With logic do more, Write less). It is indeed a good product that provides quick, easy and rich user experience for business process implementation.

I have been working on Nintex forms for a while and its quite powerful. Some of its capabilities are:

• Quickly create and deploy forms with no custom code
• In lines with web development trend, Allows to inject JS and CSS
• Provides rich set of controls
• Provides layout for other devices e.g. Mobiles, Tablet
• Supported in majority of the browsers
• No client software installation required, Design and deploy through web browser

While both MS Infopath and Nintex form have similar capabilities, the Nintex form provides an additional native support to javascript/jQuery and css. This additional capabilities could be leveraged to create a simple form or even a complex games.

Both Nintex forms and MS Infopath provide us with an option of creating quick visual forms with some rules (formatting or validation) and css. However both lack in providing feature to improve the maintainability of the form. 

The MS Infopath and Nintex forms both lack in terms of debugging technique or providing a clear picture or understanding of the form controls and its relation with other form controls for e.g. a control's visibility can be managed using rules or expression which is very easy to implement however over a period of time or with changes in ownership it becomes difficult to keep a track of all the little rules.

A complex form created with Nintex or MS Infopath may take considerable amount of time to understand the implemented rules, embedded hidden controls and relation between various controls.In my opinion the forms can be used for implementing those business process which does not have high demand and does not change very often.

So what should be the strategy of an enterprise? Should they be using any of the forms product in their environment to implement business process.

I think at an enterprise level Nintex forms or MS Infopath can be used by evaluating the complexity of business process, complexity of the form and maintainability of the form. In certain scenarios its even better to create an html based application using jQuery/Angular js or any other plugin as these applications can be easily troubleshooted and remediation or enhancement might be quicker as compared to forms created using Nintex or Infopath.

Summarizing my experience

• Infopath or Nintex forms can be used if a form is simple and does not have a more than 10 to 15 rules and Business process is not complex
• Custom form using jQuery/Angular or any other if form is complex and requires a fluid UI.