Four years ago, as an IT service manager working for a large healthcare organization, internal requests to convert a manual, paper-driven process to an electronic solution were common. The work effort typically followed the standard software development life cycle (SDLC):
- Project planning
- Systems design
- Integration and testing, acceptance and deployment
Since the introduction of SharePoint as a true development platform, electronic workflow projects have changed drastically. In mere hours, a SharePoint engineer, business analyst or even a customer can complete efforts that would have taken a .net developer three weeks to accomplish.
SharePoint 2007 with InfoPath 2007
SharePoint 2007, with its out-of-the-box workflows, was the tipping point. In combination with InfoPath 2007, client-based e-forms could be developed using the standard edition of SharePoint. The only drawback was that InfoPath needed to be installed on the user’s computer.
The enterprise edition of SharePoint 2007 allowed for browser-enabled forms. Thus, anyone with access to the form could complete and submit it on an internal or external website without downloading anything from the web. However, it came at a price. An Enterprise SharePoint license had to be purchased as well as the associated Client Access License (CAL) for each employee.
Back then, simple e-form development was limited to interacting with lists and libraries within SharePoint. Nevertheless, it was a powerful toolset giving SharePoint-savvy users the ability to build a form that could be submitted for approval.
SharePoint 2010 with InfoPath 2010
SharePoint 2010 with InfoPath 2010 moved away from Visual Studio and removed debugging abilities and scripting. Developers saw it as a bad move, but it simplified the development process for the rest of us. Non-technical users gained the confidence to develop their own forms when InfoPath interaction no longer required writing code and the InfoPath user-interface became friendlier.
Customer-created forms for travel requests, office supplies, and even job applications – complete with the ability to attach a resume – soon came into being at my company. The IT team only became aware of these forms when customers tried to integrate them into systems outside of SharePoint or wanted custom actions applied.
This change was both good and bad. The fact that customers could lessen the IT department workload was good. However, moving away from the SDLC process was bad. Absent documentation regarding form development, reverse engineering was necessary when troubleshooting problems or updating forms.
The proliferation of forms peaked before ultimately dropping off. Departmental InfoPath “experts” either moved on or ran out of simple processes to emulate.
SharePoint, InfoPath and Nintex®
Nintex® provided the next evolutionary step. During the SharePoint 2009 Conference, I saw Nintex® Workflow in action and was immediately sold on the product. Although Microsoft had made forms and simple workflow solutions accessible to all, complex projects still demanded a developer’s skills. Nintex® changed all that by introducing drag-and-drop onto a “canvas” as an action for building and configuring workflows.
By now, our IT team knew not to give away all of the keys to the kingdom. Plus, we recognized that the power of Nintex® lies in using the tool correctly. We limited Nintex® access to a small group of IT professionals possessing SharePoint administration skills. Thus, we could adhere to the SDLC process and maintain control over the solutions produced. Over the next three years, our team developed more than 40 applications using SharePoint, Nintex®, InfoPath and later Nintex® Forms. As an added advantage, neither a SharePoint Enterprise license nor an Enterprise CAL was required.
SharePoint 2013, InfoPath 2013 and Nintex®
Microsoft has minimized its outlay relative to the latest edition of InfoPath 2013. Conversely, SharePoint 2013 reflects a significant investment. As in the past, the difference apparently is due to the delineation between technology teams in Redmond.
The focus seems to be on growing SharePoint by adding new features and functionality rather than by improving the existing tools that make it work so well. I agree with Andrew Connell’s blog stating that users may want to reconsider using InfoPath for future e-forms. Multiple forums discuss the future of InfoPath (e.g., the MSDN forum), but Microsoft is yet to offer any official word.
So, how do we build e-forms without InfoPath? Basically there are two options: either employ developers and return to building .aspx forms or purchase a third-party e-form tool.
E-forms combined with workflow technology dramatically decrease time to market. At the same time, the combination provides a significant return on investment. At DocPoint Solutions, we focus on solving business workflow challenges quickly and simply by harnessing the out-of-the-box functionality of SharePoint 2007/2010 or SharePoint 2013. For more complex workflows with e-forms, Nintex® Workflows and Nintex® Forms are great additions to our toolkit.