For the last couple of months, I have been working with Nintex Workflow 2007 while researching a new issue of the Understanding SharePoint Journal. That research lead to the recently released special issue of USP Journal, titled Using Nintex Workflow 2007. You can get that issue for free now, and I’ll tell you how at the end of this article.

In this article, I’m am going to introduce you to some of the features of Nintex Workflow 2007 (NW), and show you why I think this is a really cool product. I’ll also tell you about some of the annoyances I found.

Full Disclosure: Now, I’m trying to be as unbiased as I can and give you my honest opinion, but you should know that I was paid by Nintex for creating the USP Journal issue. No, they didn’t get any editorial control, but I was still paid. As such, feel free to hold a salt shaker ready and take what I say with an appropriate grain of salt.

Nintex Workflow in a Nutshell

Basically, Nintex is an easy to use workflow add-on to SharePoint. If you have worked with workflow in SharePoint before, chances are you have either worked with SharePoint Designer or Visual Studio. Both of these options are well suited for their intended use, but there is a big gap between SPD and VS that NW fills really well.

On one side, SharePoint Designer offers an incredibly easy and free way of adding simple workflows to a SharePoint site. Using a bit of creativity you can even create fairly complex solutions, using only the built-in actions and features. However, SharePoint Designer lacks scalability and flexibility, and re-use is at best very cumbersome.

On the other side is Visual Studio, which is like having your own thermo nuclear device. It’s incredibly powerful and you can more or less control at least parts of the world, but you had better know exactly what you are doing, or you risk your solution blowing up in your face. Where Visual Studio offers immense power, its learning curve is so steep, it can scare the most die-hard mountaineer.

Nintex Workflow bridges the gap between these two solutions, by giving end users some of the power of a Visual Studio solution while maintaining the ease of use and gentle learning curve of SharePoint Designer. In addition, NW includes some truly unique features, such as the ability to combine sequential and state-machine workflows and user interaction with tasks through email in a feature that deserves mention for its name alone: LazyApproval.

Authoring Workflows in Nintex

What initially sparked my interest for NW was the interface for designing workflows. The interface resembles the workflow designer in Visual Studio in that you get a visual overview of the ‘flow’ part of your workflow. Branching, loops, and state machines are presented in what I think is a really intuitive interface that makes it easy for end users to understand what is going on.

What makes this workflow designer especially friendly to end users is that it resides inside SharePoint itself. Using scripting and more fancy scripting than I’d dare to undertake, you are actually designing your entire workflow right inside SharePoint with no client software to install or learn at all. You simply drag-and-drop actions from the action menu onto the designer surface and configure each action using dialog boxes.

True, the interface of the Visual Studio workflow designer offers more options and allows for a greater degree of flexibility, but Visual Studio is still an all-or-nothing package; if you want the added flexibility, you also need to deal with the added complexity. That complexity is probably far more than any end users are prepared to handle.

Templates and Snippets

Another nice feature is the ability to easily create templates of existing workflows. You can create the generic templates for common tasks such as approval or customer follow-up and then re-use the templates when creating new workflows. This saves a lot of time if you are creating similar workflows or have common tasks used by several units in an organization.

Another option for workflow re-use is snippets. A snippet is basically a set of workflow actions stored as a single action. You create these snippets in the workflow designer, and they become part of your available actions for use in any workflow. For example, you might create a snippet to notify an item or document owner about changes to that item or document. Whenever you want to include that functionality in your workflow, you simply drag the entire snippet onto the workflow designer, and you get that functionality added without having to re-create all the individual actions.

Go with the Flow

If there is one thing I really miss, especially in SharePoint Designer workflows, it is better debugging and tracking of what is going on. A common approach is to add a lot of history logging to track what the workflow is doing. In Visual Studio, you can attach the debugger and step through the entire workflow, which is really nice and gives developers extreme control.

While NW lacks the stepping option, it does offer a very nice workflow information page far superior to the default workflow status page of SharePoint. On that workflow information page, you get a visual representation of your workflow, including which actions and branches are currently executing.

This workflow information page can also give you a detailed view where you can get a whole boatload of more information about the workflow execution, including how long each action takes, the outcome of conditions, who approves or disapproves which actions, and a range of other information.

The workflow information provided by NW goes a long way towards providing the debugging information you need to figure out workflow bottlenecks, logical errors, and other problems you may encounter.

State of the Machine

The final thing I want to point out as truly unique in NW is the support for state machines. You may wonder what is so special about supporting state machines, after all, most workflow products support state machines in some fashion.

What is really nice in NW, though, is that a state machine is simply an action, just like any other multi-branch action. This means you can combine state machines with sequential workflows inside the same workflow. For example, you may have a long running customer follow-up process, in which one part of the workflow consists of contract negotiations. That contract negotiation may move back and forth between different states, but is still only part of a longer workflow in which the ultimate goal is to make the customer happy.

In NW, you can simply add a state machine action and configure that action as you would if you had developed a stand-alone state machine workflow. Then, after that part of the workflow completes, you can continue in a sequential workflow, or even transition into a new state machine inside the same workflow.

OK, So What’s the Catch?

Alright, I’ve said enough about the cool things, so it makes sense to point out some of the weaknesses as well. Note that most of these issues are annoyances at worst.

First, the interface for controlling configuration scopes leave a lot to be desired. Basically, you can configure settings for sites and site collections, and the scopes control inheritance and all that, but the way that Nintex has solved the interface is not good. You need to pay attention to small pieces of texts on the page to know whether you are configuring for a site or for the entire site collection.

Second, NW supports setting up holidays to avoid workflow activities while no one is available to respond to tasks or interact with the workflow. However, the way the holidays are configured could have been done so much better. You can only add one day at a time, so if you are closing the office for two weeks during summer you need to add each day of those weeks individually. Really sad for schools with months of vacation at a time.

Third, the workflow designer can become cluttered when you are creating complex workflows, especially when using multiple branches. The branches keep expanding horizontally and will eventually fill any screen size if you have enough branches. And frankly, ‘enough’ branches is too low a number for example in state machines with many states. The same applies to the workflow information; to get an overview, you need to do a lot of scrolling. A “zoom out” function would be useful.

None of these issues are deal-breakers, though. It feels to me like they have gone 95% of the way towards making a perfect workflow solution, but with a product like this, the last 5% can be annoying.

And still, their 95% are still light-years ahead of anything else I have seen in this niche.

Want to Learn More?

The state machine image above is an example from the USP Journal I mentioned in the beginning of this article. In that issue, you’ll learn how to develop workflows in Nintex Workflow. The image shows part of a “get well card” that you’ll develop during the exercises in the issue. I’ll show you how to install and configure NW, familiarize you with the Workflow Designer, teach you at least some of the actions available, as well as explain the logic of how various tasks are done, such as the above example of inline state machines.

You can get the 128-page issue from the issue download page, and as I said, it’s free, as in beer.

.b