In Part 1 of this series, I described the business need for workflows in SharePoint and a few of the challenges and limitations of working with the standard toolsets (SharePoint out-of-the-box, SharePoint Designer, and custom code workflows). We knew we needed a better solution to implementing and maintaining workflows that we could confidently recommend and use with our clients. As SharePoint has matured, so have many of the third party products in the market including a few that address workflow.

On reviewing products in this category including K2, Bamboo Solutions: Workflow Conductor, SharePoint Workflow Boost, Skelta, and AgilePoint, we settled on Nintex as the clear leader in this space and one to invest in completing a thorough evaluation.

While reviewing the product information and having demos and conversations with Nintex representatives painted a very compelling picture of the product, there is a lot more investigation and due diligence that we needed to do in order to confidently recommend it to clients. Our clients look to us as trusted advisors and often base architectural and purchasing decisions entirely on our recommendations. As such, we need to be really confident in what we recommend. It's not enough for us to simply go by the marketing material and product demos provided by the vendor. Although we obviously don't have any control or input into the product development and quality, if it doesn't work out or live up to a clients expectations, it reflects badly on us for the recommendation. Our clients (and us) have been burned before by third party products not living up to expectations and marketing claims. They often have great concepts and fill an important need, but have poor execution. And just because a product company is a "Microsoft Partner" does not mean the product has actually undergone any scrutiny from Microsoft. It is also a challenge sometimes to get past the claims of product sales people and get candid insight into a products strengths and weaknesses. As one CIO I was talking to recently put it: "We expect software to have limitations and implementation challenges, we just want vendors to be up front about this so we can plan for it."

So prior to having a client even commit to a pilot project with Nintex workflow, we went through a thorough evaluation. The key steps were:

Evaluating the feature set

Do the features align well with the workflow needs we commonly see with our clients? Does it address gaps in the standard toolset (SharePoint Designer, Visual Studio)?

This point was pretty easy to check off the evaluation list as we could quickly see that Nintex has done an excellent job building a Workflow product that both addresses the common pain points of working with SharePoint workflow as well as provides features that are super relevant to most organizations wanting to make use of workflow. Here are just a few of the features that stood out:

Workflow history / auditing

If you read Part 1 of this series or have been using SharePoint workflows for a while, you'll be well aware of the lack of workflow history retained by SharePoint beyond 60 days from the completion of a workflow (well the history items technically are still there, but users have no way of viewing them with the associated workflow). This is problematic for any business process that needs some level of traceability (for example to see who approved a particular task and when).

Thankfully Nintex Worfklow addresses this very common problem. Nintex uses its own SQL database that stores a complete history of Workflow Actions and Task History (among other things). This history is available (in both text and graphical form) from the "View Workflow History" link on the context menu of an item.  

Nintex Workflow History Available After 60 Days

Easy to learn and use worfklow designer interface

All Nintex workflow design is done right within the SharePoint user interface. There is no separate client application to install. The graphical interface is very intuitive as you drag and drop "workflow actions" onto nodes in your workflow diagram and then configure their properties.

The interface makes it easy to visualize the workflow and even walk through it (and tweak it) with business users. Sets of actions can be minimized (for better clarity when viewing a large complex workflow diagram) — I just wish it "remembered" your minimized view the next time you open the designer!

Nintex Workflow Designer for SharePoint

Comprehensive set of workflow actions

Nintex comes with a large number of "Workflow Actions" that can be used and configured to support a wide range of business needs. This includes workflow logic (such as loops, parallel actions, state machine), Library/List actions (such as creating/deleting/copying items, check-in/check-out, declaring records), provisioning SharePoint sites and site collections, provisioning users in AD and setting permissions, assigning tasks and sending notifications, and even calling a web service without writing any code!

In our experience so far, the workflow actions that come with Nintex will cover a large majority of the need for various business processes; however, you can also write your own workflow actions (using code in Visual Studio) and deploy them for use in your Nintex workflows if needed.

Nintex Workflow Actions for SharePoint

Handling workflow versioning

Supporting changes to a workflow that is already running in production without negatively impacting existing In Progress workflows can be a challenge (See this post "Approach to upgrading custom SharePoint workflows" for some tips if you are working with custom code workflows and need to upgrade.) Nintex Workflow handles this very well through versioning. Draft changes can be saved and then a new version published when ready. New instances will use the currently published version while existing In Progress workflows will continue to use the prior version they are associated with.

Analyzing the cost to implement and maintain

Nintex workflow scores very well on this point. As I noted in Part 1, the cost of implementing and maintaining SharePoint workflow can be quite expensive relative to the value achieved. Using Nintex workflow significantly cuts down on the effort required on the initial implementation and even more dramatically on the costs of maintaining and changing a workflow. The licensing costs of the product pay for themselves very quickly through:

  • A much shorter ramp-up time for individuals building out new workflows
  • A visual and easy to use interface for building out even complex workflows without needing to write any code
  • Configurable "workflow actions" that drastically speed up the process of building workflows
  • Features that address common SharePoint OOTB limitations and save a lot of customization time (e.g., dealing with workflow history beyond 60 days)
  • The ability copy and paste workflow actions or groups of actions as well as create custom actions for re-use
  • Reduced debugging and troubleshooting effort through explicit log messages and the ability to easily disable specific workflow actions / branches

As one point of comparison, a moderately complex leave request workflow (using lookup lists, various approval and notification steps depending on the leave type requested, etc.) that one of our clients has been using extensively in production took approximately five times less effort to re-implement using Nintex workflow compared with the original implementation using Visual Studio and custom code.

The savings in support, maintenance, and enhancement effort is even more dramatic. In the past, whenever the client wanted to make a change to the workflow — even a relatively minor one such as adding an approval step — it required a SharePoint developer experienced with workflow and a lot of overhead time for creating, deploying, and testing a new version of the workflow while not impacting In Progress workflows. Nintex workflow makes it much easier for a SharePoint Analyst to make these types of changes quite quickly using the visual user interface and configuring the appropriate workflow actions.

Testing in a sandbox environment

Part of our evaluation of course was to get the product installed and really dive into using it. We installed it in a SharePoint 2010 environment and put it through it's paces. Trying out the the various features and workflow actions, writing code to create custom actions, and building out some prototypes similar to custom workflows we'd done in the past as a point of comparison.

The product performed very well and we were very impressed with the outcomes.

Technical review

We completed a technical review of the product to better understand how it interacts with SharePoint, what its limitations are, and identify any potential areas for concern. This also gave us an opportunity to interact with the Nintex support and technical resources. We found them to be very responsive and knowledgeable on the product. Overall we were satisfied with our findings and didn't identify any concerns that would prevent us from continuing on with our evaluation of Nintex Workflow.

It's important to note that Nintex Workflow is architected to use the SharePoint Workflow engine (unlike K2 for example that uses it's own separate workflow engine). This has many benefits as the product works so seamlessly with SharePoint; however, it does mean one needs to be mindful of the SharePoint limitations when designing and implementing workflows.

Here are a few notable points to be aware of:

  • SharePoint workflow relies on timer job execution. This can make it unsuitable for processes that require true real-time execution. Though, for the vast majority of business process that we come across at our clients this isn't an issue and the SharePoint workflow engine is perfectly suitable.
  • While the ability to troubleshoot workflow issues is excellent (visual representation of current state, previously executed actions, and detailed logging), there is no way to manipulate a running workflow. As with all other SharePoint workflows, the only option with a Running workflow is to allow it to complete or to "Terminate" it completely.

Since Nintex uses the SharePoint workflow engine, the standard performance and capacity planning applies. See the article "Estimate performance and capacity planning for workflow in SharePoint Server 2010" on TechNet for more detail.

Working with Nintex

Aside from the details of the product itself, whenever we are looking at third-party products for our clients it's also important for us to review the company itself. Will they still be in business a few years from now? How are they to work with? Is it easy to get support from knowledgeable experts? Are they continuing to invest in the product? Do they have strong partnerships?

Nintex scores really well on all of these questions.

Nintex first launched their workflow product for SharePoint in 2007 and have been continuing to evolve it ever since with regular updates and enhancements. Nintex is very prominent in the SharePoint community and has been identified by Forrester as the most used third-party vendor for SharePoint ("SharePoint 2010 Adoption Trends and Third Party Software").

During our evaluation of Nintex, we had the opportunity to speak with another SharePoint consulting firm that has been a Nintex partner for a few years. We were able to get some very candid feedback on their experience with the workflow product and on working with Nintex. This really helped confirmed what we'd been learning on our own and added to our confidence level in our findings.

Nintex has also established partnerships with other software vendors that extend the Workflow product capabilities. This includes companies ERP-Link (for SAP integration), AvePoint and Axceler (for migration), and several others.


After evaluating Nintex on product features, costs, performance, and quality of support we can say that "It passed!".

So does that mean we're ready to go out and recommend all of our customers buy it? Not quite. At this stage, we're really confident in the product — but until we've been through a real scenario implementing it and using it in a production environment we still don't know exactly what challenges we may face with it. As such, the next step for us was to embark on a Production Pilot with one client. Read Part 3 of this series for the details and outcomes of the Production Pilot.