Liking Nintex

imageSummer is a funny time in most small shops. Projects start and stop as people take time off and attentions get diverted to the periodic crisis or to fill-in for an absent coworker. The downside for someone trying to craft a blog entry at the end of each week is that there isn’t much to work with. Those of you that come here don’t come to hear about the meetings I attended or the fires I put out. The upside is that this post will be short.

One of the interesting things I did this week was to build a SharePoint Workflow using Nintex Workflow. I’ve used Nintex before, but this time, I was teaching someone else how to build a “proper” workflow. The workflow is another part of our Payables process and it allows our accountants to delete a payable that has been submitted and approved for payment. Yeah, sometimes people make mistakes. To prevent someone from making those mistakes worse, this workflow needs to verify that a series of conditions are true. The payable hasimage to be at a specific status. The person running the workflow has to be a member of accounting. A bunch of people have to be notified, the activity has to be logged and we also have to let people know if any of those conditions aren’t met and the workflow has to be stopped.

All of those things can be done using a SharePoint Designer workflow. So, why does the title point out that I like Nintex Workflows? Well, that’s the point of this post. Here is my list of the things I like about Nintex Workflows:

I can add multiple logical conditions into the kick-off point of a single “Run if” block. You can see that illustrated in the image at the top.

I can act against multiple list items in one step. For example, I can say “go find all the allocations that have the same payment_request_ID as this imageitem and delete them.” You can’t do that in SharePoint Designer in SharePoint 2010

I can give an intelligent name to each workflow step. So, the above example step can be called “Delete Allocations” – I like that.

I can copy steps. We need to create a log entry regardless of the imageend-state of the process. Since some of those states cause the workflow to stop, I need to have the “Create Log Entry” step in multiple places which is very easy to do. Copy. Paste. Configure. Done.

I can drag and drop steps in and out of Condition blocks and Impersonation blocks which is very helpful when you realize that you have the right action but that it’s happening in the wrong place.

I can export and import entire workflows. In fairness, I think I can do this in SharePoint Designer, but I have had problems with that process and this worked like magic. I built the basic structure of this workflow from an earlier workflow that lets the person who submitted the payable to delete it before it’s approved.

And, my favorite thing – you work in a browser as opposed to a somewhat finicky, somewhat unpredictable and somewhat predictably bad stand-alone product.

That’s it for today. Not much of a product review, but I think you can understand why I like Nintex. And, I said it in fewer than 600 words.

Delete is a Form of Edit

imageIt’s summer, and despite the serious pile of work to be done and serious blog posts to be written, I’m finding more evenings filled with old movies, old songs, and old episodes of favorite shows. Unfortunately, due to that serious pile of work, the various threads get crossed. So, when I found myself in a meeting making the statement expressed in the title, I knew I was having an Office Space moment.

“I must have put a decimal point in the wrong place or something. I always do that. I always mess up some mundane detail.”

Oh! Well, this is not a mundane detail, Michael!”

If you say something like that, you’re either trying to avoid doing something that is difficult or you’re trying to avoid admitting having done something stupid. In my case, as of Friday afternoon, I was trying to avoid a difficult thing that might result in my doing something stupid.

I spent some time last week working on a series of workflows to delete entries in a payables process that we wired up in SharePoint. The problem with payables is that they have to be allocated and any one payable entry (invoice) can be allocated across several accounts. All of the allocations have to be deleted before the payable item can be deleted The inability to iterate over a list in SharePoint 2010 makes that impossible without a Rube Goldberg-type solution involving multiple shadow lists that allow you to work around the “a workflow can’t do anything that would cause itself to start” limitation. Fortunately, Nintex workflows can handle this limitation quite well.

In the case of ‘delete’ I have a simple workflow that checks to see that a payable item can be deleted (has been submitted but hasn’t been approved) and can delete payable items and the related allocation items. “Can” being the operative word – for now, the workflow is simply updating a text field with the string “this item would be deleted.” That’s a safe way to start, because I don’t have the luxury of a test environment with Nintex workflows running in it. I’m changing breakers with the power on, as it were. If I make a mistake, I could do some damage.

After I deploy the delete workflow, I have to modify it to create a delete workflow that the accountants can run even after a payable has been approved. After that, we need one final version that can delete an item even after the accountants have approved it. We are serious about not accidentally paying someone. Still, all forms of delete are just variations on a theme. The only differences are that some stop in the presence of a specific status flag and some don’t. After I get all the delete options working, I have to create an ‘edit payable’ option.

Deleting a payable is easy compared to preparing a payable for edit.

Preparing for editing requires making a payable entry, and its associated allocation entries look like they are at the point before they were submitted, or perhaps the point before they were approved or perhaps the point before they were cleared for payment. Since the approval process can involve multiple people, the items involved get quite messy. There are several workflows involved and they all set some value(s) and they all read some value(s) and they all work or don’t work based on those values. Get one value wrong and, if you’re lucky, something isn’t going to work. If you’re not lucky, you end up singing along with Jerry Lee Lewis “…she rolls but she don’t roll right.”

Michael Bolton (in Office Space, not the singer) and Jerry Lee hint at those mundane details causing problems, but John-Luc Picard encounters them directly. One of my favorite Star Trek Next Generation episodes is “Clues” and it’s based on the complexity of undoing the past to a point where you could start over. The episode involves a chance encounter with an alien race – a powerful alien race who would rather destroy the Enterprise than have the universe know that they exist.

As I crawl through the various workflows, looking for all the status indicators, I realize that resetting the status to a prior point is way harder than deleting it. I can see why those aliens would have been happy just deleting the Enterprise.

I decided to wait until Monday to wire up the delete option. In the meantime, I’ve been studying how to reset the items for editing and I think I’ll watch “Clues” this weekend.

I hope your summer is going well.

Short and Sweet

imageAs I indicated earlier in the year, I am doing less of the heavy lifting around our SharePoint space lately. I think I mentioned that this would have an impact on this blog, and well, I think that starts today. I’m not planning to stop or to go to a less frequent editorial schedule but I do have less to say.

I’ll wait for the applause to stop.

Seriously, I can wait.

OK, here’s the first short and sweet SharePoint Story.

One of the things I’ve been doing lately is helping a young woman build a site to store, track and display the results of our upcoming Wellness Contest. I say helping her build, because she is doing all the work. I’m looking over her virtual shoulder (via Lync) but she is navigating the browser, creating the lists and libraries and she is constructing the SharePoint Designer workflows. My contribution is a lot of:

oh, I see why that didn’t work” and “ok, now go back into the browser and try that workflow again…

So far, the most memorable moment for me is when she was terminating a workflow gone haywire and, looking at the workflow results page, said:

These error messages don’t really tell you much do they?

No, no they don’t – Welcome to SharePoint.

This post is about two bits of my personal style that I felt were important enough to pass onto her, and I’m going to refer to one that I’ve already mentioned. Let’s get the reuse out of the way first.

As I said a few weeks ago, I like building multiple small workflows instead of single large ugly workflows. Yes, adding the word “ugly” is a literary technique to skew your opinion toward agreement with mine. I don’t want you to think I’m trying to subtly manipulate you – the manipulation attempt is blatant.

I had a new reason for sharing this technique today though. Having short, single-purpose workflows helps a person build their reference library. Everybody forgets how to do some of the wonderful things they did in an earlier moment of greatness. It’s nice to be able to say “oh, I remember doing that when we did the Wellness contest back in 2014” and to be able to open that workflow and study it. If you open a workflow that scrolls on for several pages, you’ll likely be too confused to gain much benefit.

By the way, in addition to reusing the old thing, that counts as one of my two new things, so I’m almost done.

The second new thing has to do with clarity. Simply put, use more variables. For instance, in the workflow we were working with today, we are processing a step count that arrives by email. If there is an error, we are going to send an email back to the person who sent in the steps. That bit of information is in the Current Item From field, and we could reference it from there. However, I’d rather store it to a variable called “vFrom” and then send the error message to ‘vFrom’ if / when we have to. When we look at that workflow, the variables are visible, readable and the workflow makes a certain amount of sense.

When she finishes this project, I’ll provide a full description here; maybe I’ll even be able to coax her into writing that post. Until then, maybe I’ll actually do some work of my own, or I’ll offer up another short and sweet observation.

Divide and Conquer

imageWhen I was making the coffee table that sits in my office, I learned a lot about bending steel. Specifically, I learned that bending square steel tubing isn’t easy and often doesn’t end well. Some bends were wide enough that I could negotiate the turn and repair the damage, but others were just a bend too far. For those, I took it in steps: cut, bend a little, cut again and then weld back together. I thought about that process this week, as I struggled with a workflow issue. I’m not sure if this is a common issue, but it seems to come up for us quite often:

“Is it better to build one big, ugly, complicated workflow or is it better to create a few additional lists and spread the work across them?”

We almost always tend to spread the complexity around. In the solution I’m working on today. I need to accomplish three major steps in order to reduce a 12-15 page Word document into a series of entries in a custom list:

  • Parse all of the recommendations out of the Word document
  • Determine if the recommendations are New, Open, Pending or Closed as of the date of this report, and
  • Create entries into either a custom list of recommendations or in a custom list of updates to existing recommendations.

All of this can be done by a workflow, but it’s a complicated task. A single big ugly workflow would need to keep track of individual recommendations, whether they are new or some other status and look up the details about the inspection report metadata and copy it into the other lists. I opted for a process that involves two additional custom lists:

One is a list of what I call “splits.” Splits are the big chunks of parsed text. All the new recommendations are in a split. Likewise, all the pending recommendations are in a split, and so on. A workflow that runs when the splits are created doesn’t have to determine what kind of recommendation it’s dealing with, they are all new, or pending, or some other status.

That workflow parses all the recommendations into individual entries in the second list. That list is then built up of individual recommendations which have a status (new, pending, etc.) and all the metadata that they need to be transformed into an item in the ultimate destination list. A final workflow that runs as these items are created takes care of dispatching those items.

The cost of this solution is the creation of a couple additional custom lists and a bit of duplication of data (although the items in these intermediate lists can safely be deleted). The benefits include:

Easier to plan – The overall process is easier to plan and stage. The process becomes a fairly simple routing exercise. Big boxes of the same thing arrive at one list where they are opened, separated and distributed to a second list. It’s like a wholesale-to-retail operation.

Easier to build the workflows – Rather than a complicated workflow with lots of variables and lots of steps, I have three single-purpose workflows that are each of a manageable size. I built the process in discreet steps, only moving forward once things are working at each level.

Easier to control new vs. update action – By the time I need to know whether to create a new recommendation or an update to an existing recommendation, the list item I am working with includes that information as well as everything I need to create those items.

Easier to debug – This is a big deal for the developer (me). As I am configuring these workflows, there’s really only one way any of them can fail. That is so much easier to deal with than a workflow that can fail any of three or more ways, especially given the current state of SharePoint Designer’s debugging tools.

Easier to rerun – Some of the workflows trigger alerts, some set metadata in other lists and change the status of other processes. Working in smaller segments means there are fewer things to fix if something ultimately goes off the rails.

It might be tempting to just keep on grinding out steps in a single workflow. However, dividing the steps into logical groups and taking advantage of storing partially processed items in interim lists is a very powerful concept. This approach makes design and development easier. By the way, it worked for that coffee table too. If you want to read more about that project, take a look over here.