When we last left this subject, we decided that the ability to embed forms in SharePoint Web Parts and to connect forms with line-of-business information and REST Web Services were two of InfoPath’s hidden gems. Here now is the logic chain behind this sentiment – and indeed, the very reason for pursuing an e-forms strategy in the first place.
1. Whether they are on paper or on screen, forms are critical information capture mechanisms – not for capture’s own sake, but as part of a broader business process.
2. Functionally, therefore, forms (paper or electronic) are front ends to databases and triggers of organizational workflow. Key cogs in virtually all business processes, they smoothly feed data to and from back-end repositories, enabling field pre-population and indexing, retrieval, and routing.
3. Within SharePoint and beyond, therefore, e-forms enable staggering new heights in efficiency and effectiveness by allowing otherwise too-often disparate back-end systems to talk to each other – a capability that is especially valuable in forms-fed operations areas like A/P, ERP, and HR.
Intrigued? Good. Excited? Excellent. But don’t be fooled by even the preceding paragraphs: connecting forms to databases usually requires a whole lot more than meets the eye.
Whether you use InfoPath or some other tools, the list of challenges starts with the requirement to possess a deep knowledge of all the external fields you want to populate, and the system securities needed to gain access to those fields in the first place. Neither of these endeavors is for the faint of heart, so be sure you enlist the experts you need for help if you aren’t already conversant in the details.
More specific to InfoPath are issues related to providing the same experience to users working via browsers vs. the InfoPath client, and to mimic the look and layout of existing paper forms in the InfoPath environment. It also can be challenging to ensure that the soft and hard copies of an InfoPath form look the same as each other – and since InfoPath uses a table-based construction that positions objects relative to one another, forms design and maintenance can be complicated because when one object moves, they all move!
So what’s new: InfoPath isn’t perfect. But neither is any product out there, and at least InfoPath has close ties to SharePoint, which itself has flaws and gaps and other characteristics to work around.
The point, however is that regardless of your means, the time is long past to embark upon the e-forms trail. The need to physically handle paper slows processes, increases costs, and introduces opportunity for error – BFMA, for one, estimates that the clerical cost of processing a form is thirty to fifty times the cost of printing it, so even if you don’t buy the arguments touting improved processes and greater efficiencies, you may like knowing that there are real dollars to be saved.
Especially if your organization is already deep into the SharePoint pool.
Where are you on the e-forms trail? Leave a comment or drop a line and let me know!
Good post. We’ve done a few InfoPath 2007 forms projects where the forms were run in SharePoint InfoPath Forms services and had logic implemented via code-behind assemblies written in Visual Studio 2008.
Even with the integration, I can say the process was a lot more painful than it needed to be. To my horror, the developer experience will be even worse in Visual Studio 2010. Microsoft took out the little InfoPath support there was out of Visual Studio in the 2010 release.
Check out the demo video of Microsoft guys working with InfoPath. They are flipping between three applications to make a code-enabled form and store it in TFS.
Insane! I’m seriously looking for another RAD forms solution.