Working with InfoPath

The first question that someone might ask is, “Why use InfoPath when the .NET platform allows us to create real projects with web interfaces?”

It’s a valid question, so I have to give a little history here. 

I work for a hospice that covers 33 counties in Indiana and Kentucky.  Our mission is to provide end of life care for terminally ill patients.

We have clinicians (nurses, doctors, chaplains and social workers) that cover areas that do not often include MiFi service in Indiana and Kentucky that allow them to connect to our network, so I had to develop something that was easily distributed, allowed them to save their input easily and later submit their information once network connectivity had been established.

InfoPath also offered easy integration with SharePoint and when I arrived here, we already had a functioning interface for one of our key projects between InfoPath and SharePoint.  It is also important to consider that the CIO likes a very Vanilla solution to solve our problems.  The more Vanilla a solution is, the easier it is to upgrade a product down the road. 

Developing a solution in the .NET platform would always be available if the benefit was great enough to move away from the Vanilla solution to something a little more like Butter Pecan, but InfoPath, allowing the ease to build the forms and the connectivity to SQL, was his flavor of Vanilla.

I had a couple of small obstacles I encountered along the way and in some cases, I searched far and wide for answers and that search took a couple days. 

This blog is simply to document some of the lessons learned and some of the best practices I learned along the way for InfoPath and other technologies.