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

Every workday, Monday through Friday, Bjørn Furuknap, our resident user experience expert, will release a new article in the Customizing SharePoint User Experience series. These articles are based on his book, “Building the SharePoint User Experience”, due for release this April. SharePoint Magazine has secured the exclusive rights to publish previews of the content from this book.

The “Customizing the SharePoint User Experience” series has only four articles left. Since there are five days in Bjørn has written a final bonus article, the title and topic of which will be revealed on Thursday’s article.

Stay tuned and you will find out the topic of the bonus article.

Bjorn, first tell me a bit about yourself? Who are you and why should people listen to what you say?

My name is Bjørn, and I’m a SharePointholic. I’ve been in IT since I can remember, but started my professional career in 1993. Since then I have worked on both the admin and developer side of the fence.

I set up my first SharePoint installation for my own company in 2001 and have since installed countless SharePoints, ranging from small fire-and-forget team sites to completely customized massive portals.

However, I didn’t really get into the SharePoint developer thing until WSS3 came out. I started writing webparts and stuff for WSS2 but never liked the development experience.

As to why people should listen, I have no idea. Perhaps because I am passionate about what I do and in addition passionate about writing about what I do. That passion means I put a lot of time and energy into continualy improving and learning.

People seem to appreciate what I write based on feedback and blog readership, and if they can learn something from it, thats even better.

What will the topic of the book?

The book will be focused on understanding the architecture of SharePoint from a user experience perspective. It will be a book for architects, developers, and designers who want to truly understand the architecture of SharePoint and how they can apply that to create great user experiences.

Will this be another CSS/master pages book then?

Ah, no, by all means, no. I make a clear distinction between experience and interface here. The user interface is just a small part of the experience. Other factors such as functionality of pages, content types, working with email on lists, and modifying the authoring experience are all part of the user experience. At the time of this writing I have written about one third of the content for the book and I have written less than two full paragraphs relating to design, css and master pages.

I make no attempt to teach people css or html, and there is no need to know any of that stuff to learn everything that is in the book.

Who will be the primary audience?

Everyone! Buy one for each of your friends, and two for yourself!

Jokes aside, the book is primarily for SharePoint developers who are familiar with the basics but want to learn more and go deeper into SharePoint architecture. You should know your master page theory, but you don’t need to know the CAML required to create a list from scratch. You will after you have read the book, though.

The secondary audience will be architects, developers, and designers who seek to better understand the options for enhancing the user experience and thus be a better resource for others who may not know all the nitti-gritty details of what is possible.

Ok, so tell me a bit more about the actual contents.

The book will be divided into three sections or parts. The first part will focus on getting the bare minimum of SharePoint knowledge down, such as basic feature design and CAML/XML basics. The second part is a deep dive into the core of SharePoint, going from the site itself down to inner workings of custom fields. Then, in the third section, we put all that knowledge into creating a new solution from bottom up.

I am also trying to focus on unique knowledge and stay away from what has already been written in other books. Of course, there will always be overlaps, but much of what I write I have yet to find described anywhere else.

Can you give some examples of unique content?

Sure! For example I have yet to find any books that explains the steps, or actually step singular, required to email enable a custom list. Anyone can click the ‘Email enable this list’ for a document library or several other list template types, but that does not work for custom list, or a number of other lists. In the book I explain how email enabling works down to reading the reflected source code of SharePoint, and then explain how to email enable custom lists using only a single line of code.

I also take the time to test every attribute and feature of definitions to verify the official documentation. Sadly there are many examples where the documentation is either lacking or even plain wrong. I make a note in the text every time I find something like this and document the findings by showing reflected source code as well examples.

How does the article series “Customizing the user experience” fit into all this?

The article series actually came first, I only started thinking about the book after I saw that I would never be able to fit everything I wanted into an online series.

The online series stands on its own, and you can learn plenty from just reading that and never read the book. If you do get the book, however, you fill find tons of more information on each topic. I have had to prioritize and cut content from the online series in order to remain sanely short.

If you compare the first part, which is the longest article I have written online, the book chapter for the same topic is about three times as long. The “Lists and list templates” part is almost ten times as long in the book because I can go deeper and cover more ground.

Why would this book be any different than other books on SharePoint?

I focus highly on also creating a great reading experience by trying to tell a story while explaining the technical details. When I start a new chapter I first create the story, which often has absolutely nothing to do with the contents of the chapter itself. For instance, chapter 7, which details lists, list forms, and views, the story revolves around a journey through a forest searching for a hidden monster that lives in a cave.

A monster?

Hehe, yeah, I’ve spoken to many a SharePoint developer who are trying to create views from scratch. It is quite often painful and many have ‘fallen’ to the beast, running out of the room while cursing SharePoint and the day Bill Gates was born.

Sounds more like a fairy tale than a SharePoint book

Perhaps, but there is very little direct story telling here. I use humor and other literary tools to hopefully make the reading a bit more enjoyable. I write the story first to set the mood and pace for different sections of the chapter. I realize that people will buy Tolkien books if they want to read stories, so 99% of the content is still pure technical skill building. The story is just as much a tool for me in writing a chapter as it will be for the reader. If it’s not fun for me to write it sure as heck won’t be any fun to read.

The message in chapter 7 is: “Don’t go into the cave unless you are prepared, and the weapons you choose are the knowledge you gain. ”

I was also thinking of having the chapter on fields and columns take the reader into the role of a private investigator in a murder mystery, complete with femme fatales and gunfights, trying to find out what killed the text field type. I figured a lot of the readers like RPGs so they might appreciate being part of the book rather than just observing. I still have to get that past my editor, though, he might not see the fun that I do.

Why do you write so much?

Heh, I love to write, but more importantly I want to participate in the community, be part of the experience in a manner of speaking. There’s a certain mentality in Norway called Jante that frowns upon anyone who stands out. I hate that mentality and hopefully by contributing to the community and showing what can be done if one participates I can inspire others to be more active as well. In the long run this means more people on the scene and by random chance alone at least some of them will be good and teach me something new

So you are not making any money off this?

Not directly, no. I do get royalties from the book, but not nearly the same as I would have made had I put the same amount of work into customer projects. However, demonstrating skill and being visible is a great way of getting attention, and I have noticed a rise in requests for my time.

Why did you choose to write for SharePoint Magazine?

It was just a stroke of luck I guess. I had an idea for my first article on runtime modification of components and had begun writing for my own blow when I happened to stumble across the then unlaunched SharePoint Magazine web site. I shot off an email to you and you accepted. It’s a lot easier to reach a wider audience when writing for a magazine than just in my own blog.

Now that the magazine has been up for a few months I see that the value to the community is much higher than I expected. The quality of the articles, the topics available, and the update frequency is spot on. I am really happy to be part of a great team of authors here.

Thank you Bjorn for taking the time to answer these questions. Do you have any final thoughts?

Yes, absolutely. If you are planning on participating in the community, do so. Take the first step, get a blog up, start writing. The SharePoint knowledge pool is growing worldwide but demand is growing even faster. Share your knowledge so everyone can benefit.

Oh, and I love my wife very much. I promised her I’d say that

If you want more information about the articles, the book or Bjorn, here’s how you will get that:
Bjorn’s articles on SharePoint Magazine
“Building the SharePoint User Experience”, book blog
Furuknap’s SharePoint Corner, Bjorn’s blog