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.