One Stop Shopping Plus Mail Order

imageA few weeks ago, I received an email about an old post about managing a walking contest in SharePoint. Ironically, we are preparing to kick off the 2014 version of that contest in about 2 weeks and once again, we are managing it in SharePoint. I like to use these little side projects to demonstrate what SharePoint can do out-of-the-box. Some might ask “why focus on out-of-the-box? SharePoint can be so much more.

Their question is not quite correct and I am lying just a little bit.

The problem with their question is that “SharePoint can be made to be so much more” but the making can take a lot of time.

The lie that I’ve told is a lie of omission. I didn’t tell you that my box is bigger than Microsoft’s box. My box includes things like HarePoint Workflow Extensions and Nintex Workflows. HarePoint’s extensions add some very cool features to SharePoint Designer workflows and Nintex, well Nintex Workflows are like a slice of SharePoint Heaven here on Earth.

So, truth be told, I like to show people what we can do very quickly in SharePoint with the tools that we have available to us. That’s important for a reason that most IT departments don’t consider often enough.

Sometimes, people don’t ask for things because they think those things will be hard to build or expensive or that they will take too long.

They aren’t trying to save my time or my budget; they’re just trying to avoid being told “no, you can’t have that.

In the 2014 version of our SharePoint-driven walking contest, we have added two new features. Both are aimed at improving the user experience and both came at the request of my new young colleague Stacy. Stacy is not only the architect on this project, she’s the user. She’s managing the walking contest and she’s building the site with some help from me.

For those of you who are unfamiliar with a walking contest, it’s pretty much what you would imagine:

  • Our company is divided into teams.
  • Each person tracks and records their steps each day during the contest.
  • At the end of the contest, the team with the most steps wins a team prize and the person with the overall highest number of steps wins an individual prize.

Stacy wanted to make two improvements to the accounting process for the contest. She wanted to add options for mobile entry and she wanted a dashboard of sorts for reporting progress.

Mobile entry was easy but, again, it uses a few tricks from our bigger box. You can send your entry into a SharePoint Remote Entry library by including the subject line “10-11-2014 8,996” i.e. the date and the number of steps. A SharePoint Designer workflow, aided by HarePoint’s Regular Expression actions parses the subject line and adds the steps to your step count. A second workflow adds your step count to your team’s total.

We could do all the processing in one step, but I like breaking things into small chunks. That is a carryover from my history of coding in Smalltalk, but it’s a good practice for SharePoint. Small workflows are easier to test and they are easier to “debug” since there really isn’t a “debugger” available in SharePoint.

Employees with iPhones can also easily enter their steps via a mobile view of the Steps Entry form. Actually, anybody could do this, but “iPhone” is linked with “easy” because our MaaS360 mobile device management software allows us to push that mobile form through our firewall without the need for a VPN connection (which people hate to make on their phones).

Finally, we needed to build that dashboard, but we decided to make it functional instead of just informative – that’s where the “one stop shopping” comes from. We started with a Web Part Page and we added an Announcement part and an Instructions part in those top-of-the-page whole width zones. Then we added three useful parts. On the left, we have “My Steps” which is a view of the Steps list filtered on the current user. In the center, we added a view of Team Status that shows the current ranking of teams and on the right; we added a simple entry form for steps.


I have to admit, this is the first time I have ever put an entry form on a dashboard. It works. Having the entry form on the page makes this page the only thing people actually have to look at. My Steps, My Team and, as I look at my steps and realize that I forgot to enter yesterday’s value, I can do it without leaving the page.

Stacy’s homework assignment is to add a chart to graphically display some of these statistics and to make the page a little prettier. Mine is to start walking.

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.

Blah blah InfoPath blah blah

imageWow, has anything ever attracted as much attention as Microsoft’s decision to kill a mediocre product? My inbox is full of “InfoPath is Dead” and “Microsoft is Killing InfoPath” emails. I’ve seen Tweets, Facebook posts, invitations to join discussions on LinkedIn and invitations to attend Webinars practically every single day since the announcement was made. I get it! InfoPath will die in 2023. Guess what, I will retire before then.

The fact that I will be retired before then really won’t be considered as input to our decisions regarding InfoPath usage. As it stands today, we are making limited use of InfoPath in a fairly important project. In addition, we have plans to use InfoPath in a slightly larger, more important project later this year. I don’t see us changing these plans. Here’s why:

2023 – 2014 = 9 Years – Seriously, 9 years! That’s a long time. It’s not like “ding dong the witch is dead; click your shoes and go home.” The metaphorical Dorothy will be old enough to drink by the time she gets back to Kansas. We made an investment in InfoPath, and well before 2023, we will have achieved a return on that investment. That is what we are supposed to do isn’t it?

What’s on Other Roadmaps? – I realize that there are other ways to publish and process forms. Some of these alternatives are every bit as good as InfoPath, many are superior. If you made me choose a new forms platform today, I would probably start by taking a hard look at Nintex. We use Nintex’s workflow product and I imagine their form product works well too. That said, what’s Nintex’s plan for the future? Will Nintex Forms exist in 2023? Will the forms we produce with Nintex Forms today still run in 2023? Well, we really don’t know. In terms of vendors you can trust for the long haul, there really aren’t many. It’s not like they are untrustworthy, but what company can really say that they and their products will be here in 10 years? HP? Dell? BlackBerry (RIM)? Kodak? Go back 10 years and think about how those guys looked at the time and then consider how they look today. If you’ve been reading this blog, you might be surprised to see me say that I trust Microsoft, but when they say that they put something on a long, supported slide to the back door, I think we can believe them.

Now, let’s take a look at those scary emails. Here are some of the things they are warning me about and why I’m not concerned:

Support and Compatibility Questions Abound – Sure they do, but when haven’t they? Microsoft says that InfoPath 2013 will be the last version and support will end in April of 2023. As far as I know, they didn’t actually say that InfoPath 2013 and SharePoint 20nn will be compatible, but I’m not going to worry about that. Let’s assume that the next version of SharePoint is the 2016 version (I know they want to stop the “big release thing” but humor me). Chances are good that SharePoint 2016 will be compatible with InfoPath 2013. Chances are also good that we could run SharePoint 2016 until 2020 (we’re still running SharePoint 2010). Since we know that InfoPath is on a collision course with the trash bin in 2023, I’m pretty sure that my successors will have an alternative in mind before 2020. I don’t think they will be building any new InfoPath Forms in 2018-2020, but I think we can safely build them in 2014-2016 and still get that ROI.

No Certain Migration Path – In other words what if Microsoft creates a new Forms product and we can’t convert our InfoPath forms to that product. Well, that would be dumb. If Microsoft wants to play in the forms arena, they would be silly to alienate their previous forms customers. Still, since we know that Microsoft is capable of doing dumb things, I’ll accept this as a possibility. On the other hand, you have to ask: is there a way to migrate one forms product today to another forms product today? I am assuming that if we wanted to move to Nintex Forms today, we’d be recreating the functionality of our InfoPath forms on that platform. That’s OK. Also, that’s really the worst thing that can happen to us, that in 5-7 years we will have to recreate a form that probably will be due for a major update anyway.

A member of my team will be at the SharePoint Conference. We will hear about the future of InfoPath from the horse, and we will plan or adjust our plans accordingly. In the meantime, I’m not losing any sleep.

It’s Alive

iPad Screen shotWell I guess the phrase is actually “it’s now gone live” but that just doesn’t invoke the same emotional response. We have a business process that is now partially running in SharePoint. Even better, the right portion is running in SharePoint and the stuff that shouldn’t be in SharePoint is running somewhere else.

The business process is “payables” – something everybody has to do but something most people do differently than we do. See, we’re small, we don’t have a lot of vendors, we don’t have a complicated (no you can’t have that) procurement process and we don’t have a receiving dock. We buy things. We hire contractors. We incur professional fees. We refund premium on occasion and we reimburse people for things. We do this a bunch of ways. We have Concur (shudder and cue the foreboding music) which I actually kinda like. We do ACH transactions. We do wire transfers and we write checks. We also periodically reimburse people for small purchases with something called cash. I’m sure some of the younger readers are Googling that term.

The payables process, in addition to resulting in many financial outcomes, begins with a variety of financial transactions. Eventually, we will lasso all of these transactions and pull them into the same ring, but we decided to start with Check-Requests and checks. The process is pretty simple. We buy something from a vendor. They send us an invoice. We send them a check. In between step 2 and 3, someone studies the invoice, makes sure it’s legitimate, prepares a check request and then somebody else approves that request. That whole process, the stuff between step 2 and 3, is now done in SharePoint. Below are some of the cool things we (remember ‘we’ now means ‘they’ and stands for the shy people on my team) were able to include:

  • Maintaining a list of vendors that are automatically checked to make sure they aren’t on the US Treasury’s list of bad guys, and then approved by someone in authority in accounting.
  • Create a check request for an invoice(s) from an approved vendor.
  • Attach the image(s) of the receipt(s) to that check request.
  • Allocate the amount of that/those invoice(s) across multiple departments or multiple accounts within a department. For example, I buy a server, but some portion of the invoice is for the warranty.
  • Route the check request to one or more people for approval.
  • Do all the little checks and balances like making sure that the total of the allocations equal the total of the request.
  • Approve individual check requests for payment.
  • Allow the approvers to send the request back to the previous person to correct an error.

The tools used to make this happen include:

  • SharePoint external lists and the ability to impersonate users when working with them
  • InfoPath forms
  • Custom lists and views
  • Data View Web Parts to put the forms, lists and view on a single interactive page.
  • SharePoint Designer workflows to respond to the various activities a user did and to validate the transaction while it is in process
  • HarePoint’s Workflow Extensions to do some of the tricky stuff that SharePoint Designer doesn’t seem to do, like execute SQL Statements or use Regular Expressions to evaluate a sting.
  • Nintex Workflow’s “for each” capability to cycle through each Paid request in an external list to update our detailed custom list with the payment details.
  • All the various widget to widget connections you can establish in SharePoint Designer to get web parts to respond to other web parts.

We decided to use InfoPath instead of other techniques because we wanted a more functional form with less code buried behind it. I’m not sure that we saved on the coding effort, but I like the mix we are left with. We are trying to stay very close to the level where we can establish the action we want by “configuring” parts instead of writing code. It’s a fine-line kind of balancing act, but it works for us.

This just in, yes I know that Microsoft has put InfoPath on the short-line track to obscurity, but it will be around for a while and I feel that we risk very little by using it the way we do.

The reason I said that the right stuff is and isn’t running in SharePoint is central to our use case for having SharePoint and it is something that I think people often overlook – SharePoint runs in a browser. By building the front-end of this application in SharePoint, I can let people who are traveling submit invoices to be paid, approve payment requests and manage their budgets without having to write any web stuff. Also, since we have that Mass360 browser I talked about, I can approve payments on my iPad without a VPN connection.

The stuff that’s not running in SharePoint are those back-room accounting processes that nobody sees and everyone is content just knowing that they get done. Nothing to see here, move along.

Is My SharePoint Done?

imageWe have all talked about, read about and many have written and presented about the fact that every SharePoint question can be answered with “it depends.” Well, I’m adding another question to the heap, the one in the title. As I look around the pile of SharePoint notes on my desk, I find references to several systems that are done. They are done, or they were done, or they are never going to be done, I’m not really sure, but I’m also not adding a sad-smiley here. There are several reasons that SharePoint is kinda-sorta never done, and they’re all some of them are good ones.

SharePoint Changed – We have features in SharePoint 2010 that we didn’t have before, and this made us want to change some sites. A good example is Document Sets. We waited until we had SP2010 to build one site, because we knew Document Sets were coming. After building that, we found a few other places where Document Sets would work well, some have been changed; some are on that list on my desk. Managed Metadata is something else that is spreading like Kudzu. As we look ahead to SP2013, we’re happy to hear that loops are allowed in workflows, but we’re also thinking about bigger changes, like moving some sites to the cloud.

The fact that SharePoint has changed, is changing and hopefully will continue to change is a good thing. As long as Microsoft doesn’t forget that people are using the features they baked into the earlier versions, there should be all kinds of happiness in the future of SharePoint.

Content Changed – Considering that we are a business that does one thing and that we’ve been doing it for almost 60 years, you wouldn’t think that much changes in the world of our content. Well, change is relative. Our content might be changing at a glacial pace, but some things are different. I mean we are no longer filing onion-skin copies of endorsements (you young kids go Google that). More important are the changes in the way we look at content. Some of these changes are driven by new people who are more comfortable with information. Some are driven by new priorities that make us want to ask harder questions. Some are driven by the connect-the-dot effect of SharePoint. As we put more content into SharePoint and add metadata that lets us find it easily, we start to see connections between what we first imagined to be disparate silos, and we start to see value in making more connections.

We Bought Something – We haven’t upgraded to SP2013 yet, but we did purchase Nintex Workflows, and that product gives us the ability to loop through a list. Initially, I didn’t think we would go back and tear down any of those three-part bank shot multiple lists and workflow combination solutions that force SharePoint to iterate over a list, but maybe we will. Earlier, we bought HarePoint, which made it easier to connect to our workflows to data in SQL Server (among other things). This means we can expose more data on a SharePoint site, including some sites that are were done.

Something Broke – Yeah, this is the one I added that caused the strike-out in the first paragraph. I know Microsoft hates it when people talk about problems, but things do go wrong in SharePoint. One of the biggest things that went wrong for us is a site that thinks 90% of its metadata is defined twice. We aren’t sure what caused this, but all indications (as well as all Googling) tell us that the only solution is going to require us to rebuild this site from scratch. Microsoft isn’t the only source of  things going wrong, we have a couple of utility add-on products that no longer seem to want to play well with others. For now, we have had to deactivate these solutions while the vendor scratches their head – hopefully this won’t lead to changes in our solutions.

SharePoint solutions evolve, improve, get extended and sometimes SharePoint solutions break. It’s not all good, but it certainly seems to be something we have to get used to. Is my SharePoint thing done? “It depends on what the meaning of done is”– apologies to Bill Clinton.

Maybe, Just Maybe

clip_image002I’ve been on vacation this past week, trying to put great distance between my thoughts and thoughts of SharePoint. I have spent most of the week doing what I love to do – woodworking and construction. Both hobbies give me the opportunity to build things and to use some pretty cool tools. Ironically, the opportunity to use some pretty cool tools brought my thoughts back to SharePoint. The manager of our small group has installed a trial of Nintex Workflow and due to some budget magic we might actually be able to afford this product this year. Our tasks are to determine two things: 1) can we get by without the Enterprise Edition (if you’re new to Microsoft or SharePoint, ‘enterprise’ is the word they use in Seattle when they mean ‘expensive’) and 2) is there enough utility in this product to justify the expense.

We have been drooling over this product for a long time, but our desire rose dramatically after listening to Marcel Meth talk about it at an AIIM New England event last November. We like products like this because we like adding functionality to SharePoint but we don’t like writing a lot of code. I have only started poking around (I am on vacation) but I’ve seen ‘Calculate Date’ and ‘Regular Expression’ categories and I have wanted those for quite some time. I also noticed ‘For Each’ and ‘Loop’ and that makes me think I can stop writing those three-cushion bank shots to force SharePoint to iterate over a list by updating an unrelated ‘index list’. I know that Microsoft has added looping to SharePoint Designer 2013 but we’re still using 2010, and I’m guessing Nintex’s implementation will shine a little brighter than Microsoft’s.

In addition to looking ahead to SharePoint 2013, we are also looking at the possibility that we will one day want to move SharePoint to the cloud. As we invest in tools, we want to be careful to work with vendors who are also looking to the future. Nintex seems to have that same view, so I think we are safe in that regard.

The main reason we look at solutions like this is because we want to be able to move activity into SharePoint. Content management is more than storing documents. Documents often get created through a collaborative process. Once created, documents sometimes cause other processes to start. The notion of content-centric applications is one that we are very keen on seeing come to fruition, and we want that to happen within SharePoint. We have had some success building solutions that let documents get created, be processed through a basic life-cycle and move to become company records, but we want to be able to handle complex processes as well.

I’m not sure if we’re going to pull the trigger on this purchase, the price is high. Being in the insurance industry, we are grounded in the concept of necessary volume or critical mass – a.k.a. there has to be enough premium income to cover the potential risk. Similarly with this product, we have to see enough utility to justify the cost. In making that determination, we will consider:

How much time will this product save? Let’s face it; we could probably do most of this in client-side code so this product has to make accomplishing our goals easier.

How often will we use it? This is really the volume question. Even if owning Nintex will reduce our development effort by 75%, if we only use it twice a year it won’t be worth the investment.

Is Nintex critical to anything? Some products are justifiable simply because, when you need to do “X” it’s the only way to get it done. I doubt we are going to find anywhere where Nintex is the silver bullet, but we should look.

If the evaluation is positive, I’m sure that I will write about our experience with the product.

Have a great Labor Day weekend; I’m going back on vacation now.