InfoPath and SharePoint = sophisticated automation without code
Today I want to talk about how InfoPath and SharePoint allow non-developers to develop some very sophisticated systems.
Someone I know was just stepping into a new job, a startup-like organization currently in the process of defining many of their internal business processes. In particular, the process the new person was in charge of was taking purchase order requests from team members, routing them to the right person for approval and then executing on them. The challenges were largely around keeping track of who asked for what, what state each order was in (waiting for approval, waiting for revisions before resubmitting, being executed, etc), and tracking all the bits and pieces of associated information.
Sidebar note here: you know how we'll usually show data sets with three to six or seven fields in samples? Well, this form had about 30-50 fields to be filled out, all with non-redundant information. The real world is clearly a lot more complex than samples make it to be. Back to my story.
It turns out that the organization had a SharePoint site at its disposal, and all the team members had InfoPath available to them. This is what we came up with, in less than an hour, without writing a single line of code. Try writing something similar without all the supporting infrastructure Office gives you :)
- Through the browser, created a SharePoint document library for forms (turns out we could have done this from the InfoPath Designer directly, ah well).
- Designed and published the InfoPath form template over two or three iterations, adding fields we missed. There were all sorts of things on the form: instructions on how to fill things, specific data types for the fields, hard-coded lookups, "real-lookup" lookups, file attachments, field hints, etc.
- Added an Approval workflow for the forms, so they could be routed appropriately and kept track of.
The developer in me of course wants to 'geek out' on the fact that we can pull fields into list columns and export them to Excel for analysis, or we can do additional programming on the docs, or through the SharePoint object model or even the OData endpoint, but the need for that hasn't come up yet. But no developer was needed to get all of this up and running, and what they now have is a perfect fit for what they needed.
Overall, this "power to the user" theme resonates very well with me. Seeing where computing was a decade ago, where the height of non-developer sophistication used to be complex Excel spreadsheets and the very rare file share with Word form documents, I am heartened by how much more we have to offer for them.