InfoPath Services, part of the enterprise edition of Microsoft Office SharePoint Server (MOSS), provides a powerful...
set of functionality that allows developers and power end users to quickly create online forms.
InfoPath is a powerful tool, and even inexperienced users can create and publish an online form in less than an hour. Like many SharePoint features, however, the most obvious path forward with this tool is not necessarily the best path. Learn how to incorporate practices into your InfoPath forms development process that will provide enduring benefits for your personal productivity and for your company.
InfoPath forms are nearly always tied to a business processes that combine rich data entry, a well defined and tightly managed business process, automated notifications for approvals /dispositions and reporting. In SharePoint terms, these map nicely to InfoPath (rich data entry), workflow (managed business process) and views on libraries and lists (for reporting). For time-sensitive processes where money or jobs are on the line, throw in some key performance indicators to round it out.
Any managed business process like that needs to answer questions like:
- What is the next step in the process?
- What needs to happen in order for the workflow to move to the next step?
- What was the last thing that happened with the form?
- When should the next step be finished? Is it overdue?
- What was the average execution time for the process? Longest time? Shortest time?
At any given time, the InfoPath form's "state" precisely answers those questions. This leads to a key best practice: represent the business process state by storing business process state data in the form itself. Consider Figure 1:
Figure 1: Form state data
As you can see, Figure 1 depicts a few typical pieces of data that collectively tell us the state of a form at any given time:
DueDate: When the next approval should be obtained. This can drive a key performance indicator or an "overdue notice" automated email.
NextApprovalRequired: This tells us who exactly is responsible to approve or deny the request. We can't proceed with any workflow processing until this approval is obtained.
LastApprovalObtained: This tells us who, exactly, most recently approved the request.
OverallStatus: A single value that tells us at a glance what's happening with this form.
Your own business process will require different specific data to be store.
Normally, this state information wouldn't appear on a view available to typical end users. InfoPath, however, doesn't care if the state information is visible to end users or not. Add your state information the form, promote those values and update them via rules on the form itself -- for example, when the user clicks a "submit for approval" button or via a workflow process. SharePoint Designer and Visual Studio style workflows can both read and set the values of InfoPath fields as long as you promote them when you publish the form to SharePoint.
Managing business process state is a powerful technique that every user should use when implementing a business process in SharePoint using InfoPath.
Create self-documenting InfoPath forms
Once we embrace the "form as database" concept, we can do some interesting things to organize the form, document the form and debug the form in the -- hopefully -- rare cases when production problems arise.
It's common for even moderately complex InfoPath forms to leverage multiple views. For instance, you may translate a multi-page paper form into an InfoPath form with one view per printed page. That can make a lot of sense. However, don't fall into the trap that a view is only for data entry by your end users. Create at least two additional views:
- Create a view to manage developer notes: If you want to hide those notes, don't provide any run-time access to this view -- rely on the InfoPath desktop client to get at the view at design time.
What better place to store notes about the form than the form itself? If you rely on a more classic approach to form documentation -- for example, a SharePoint document library -- then the documentation is far away from the form itself. The only downside with this practice is a small amount of bloat. You are actually adding an extra view that you never intend to provide your end users.
The purist in you may feel like this is a waste of good resources, but consider maintenance programmers that will be looking to expand your form far in the future, or may be in about two weeks from now. If definitive programmer notes are embedded in the form, your organization will save time and money when it wants to correct or enhance that form.
Administrative /debug view: Create a view that you intend to provide only to your developers and administrators. Show the form state data described above. If someone calls into the help desk with an issue, you can pull up the form and inspect its form state in a nicely arranged graphical format suited to your own style. Back that up with some developer notes that explain the meaning of those state fields.
Plan for growth: You'll soon find yourself with a half dozen views on a typical InfoPath form if you have developer notes, an admin view, end user instructions, "main" data entry and a few confirmation screens. And that's just for starters. It can become unmanageable. A quick and easy way to organize them is to adopt a naming convention for your form views such as that depicted in Figure 2:<</p>/li>
Figure 2: Adopt a naming convention for your views.
I use numbers to indicate views where users can enter data, early letters for confirmation type screens and later letters for administrative type views.
Proceed with care
Like many SharePoint features, InfoPath is deceptively easy to use. However, its form and function -- its very name -- pushes us into thinking "form" and "data entry." Don't fall into that trap. Think of the form as a complete self-contained database. Provide your users with a terrific forms experience, but save yourself a lot of grief. Make your business process automation and debugging tasks easier by saving process state data in the form.
If the form is a database for business process automation purposes, why not use developer notes? Create a view just for developers, and reduce your long-term maintenance costs.
Finally, think about debugging. When users report a problem, they usually say something like "it didn't work." Don't rely on their shaky memory or myth-based understanding of the form and associated business process. Create a view that lays out the facts (the state data) is a nice format suitable for debugging the form.
In combination, these practices will enhance your personal productivity with the tool and help your organization create high-quality forms and automated business processes with SharePoint and InfoPath.
ABOUT THE AUTHOR
Paul Galvin is a SharePoint MVP and co-founder of Arcovis, a SharePoint consulting organization providing services to clients in the New York metro area. Galvin has worked in the IT industry for more than 15 years in areas such as software development, consulting and SharePoint solutions design, where he works with clients to create business solutions using the SharePoint platform. He contributes to the SharePoint community through MSDN forums and his blog at http://paulgalvin.spaces.live.com.