—Plato

How do you manage all the content that is not a document or a simple web page? Organizations contain all types of content, from unstructured content such as documents and web pages, to more structured content. One significant category of more structured content in most organizations is forms and their related processes. In this chapter, I provide guidance on analyzing form requirements and form processes, particularly for your existing paper forms. I also share techniques for designing electronic forms in InfoPath with approval workflows you can deploy for SharePoint to host.

After reading this chapter, you will know how to

• Describe the types of forms and form use within organizations.
• Consider the difference between paper-based forms and electronic forms.
• Model paper forms and form processes to transition to electronic forms.
• Analyze and design electronic forms and workflows.
• Build electronic forms in InfoPath.
• Build an electronic form approval workflow in SharePoint Designer.

Types of Forms in Organizations

I would be hard pressed to name an organization that does not rely on forms of some sort in their business processes. Most business processes seem to rely on some type of data entry, whether the process is for collecting data or for tracking the status of a particular transaction.

For example, one process for onboarding a new employee may include a form to collect the employee’s contact information to enter into the payroll system; another process may include a form with a checklist for things such as account creation, merely to track that these activities take place. In the first type, the process exists primarily to collect specific data for entry into an enterprise system. Whereas in the second process, the data entry exists to track and support the process.

You can also have a hybrid of these two: some form fields explicitly collect data while other fields manage conditions for what data the form collects or what processes the form spurs. I find this blended type of form is the most common, but there is a place for the two distinct options as well.

Forms support all sorts of operational processes. This can include manufacturing checklists on a production line; product pick sheets in a distribution warehouse; employee vacation requests or expense reports; customer order sheets; and even job candidate applications. Forms exist in some way whenever there is a transaction or data exchange between two groups—whether between two internal departments or externally with customers or partners.

With forms connected to so many interactions, it should be clear that they represent a major portion of data within an organization, and therefore the reason why they warrant coverage and consideration in your enterprise content management solution. Indeed, these forms are a catalyst to some crucial business decisions and transactions, and as such, you need to consider their entire life cycle as you would for any other piece of enterprise content. Forms are just a different kind of unit of information, and as such they still needs to be managed, retained, and then ultimately disposed.

One of the greatest opportunities I find in most enterprise content management initiatives that I get involved in is with optimizing and automating the forms and any of their related processes. Typically, this involves transitioning from paper forms to digital forms. You can either replace the form itself with a digital form for the users to fill out, managing the form as a digital artifact throughout its entire life cycle. Alternatively, you can continue with the paper form but then scan it to transform it into a digital version after a user has manually filled it out and submitted it.

Paper Forms vs. Electronic Forms

Paper forms have been around for a very long time. They have been the standard agent for capturing data or processing a transaction. Electronic forms are relatively new in comparison and they essentially serve the same purpose as paper forms, only they are digital. Because the two are so similar, even near perfect substitutes I dare to say, it is no surprise that a general trend to digitize forms has been ongoing for several years now. Yet despite this trend and its popularity, I am often somewhat surprised to discover just how prevalent paper forms can still be in an organization. The reason for this, however, is that paper forms are still useful—they still serve a purpose.

Imagine using forms in places where it is just not practical to use a computing device, or even where digitizing the form would not add any benefits. I mention this because not everything needs to be transformed into a digital state. Some things are fine to continue as a hard copy, maybe for a given duration until it becomes advantageous to digitize it, or maybe indefinitely. The deciding factors are typically things such as identifying and measuring value that outweighs the costs involved with the transformation. These costs can be implementation costs directly, or the impact costs for the users using the form.

I remember when I was a teen in high school working for a pizza restaurant. Part of my job, in addition to washing dishes and making pizzas, was to answer phones and take orders. Now, we had a computer point-of-sale system to enter the orders in an electronic form, but while we were on the phone with customers taking their order we used a pad of paper order forms.

Using paper forms was to simplify the process, allowing for easy changes with the swipe of a pen. It kept order taking quick and easy, and most importantly, focused on the customer rather than a computer, or so my manager believed. After the call, we would then enter the order in the computer. The user experience with their computer system may have improved dramatically since then, making the paper order forms no longer necessary or as helpful, but at the time, they had a legitimate reason to continue using paper-based forms despite the availability of electronic forms.

Some paper-based forms you might dispose of after their use, while others you might scan and capture as digital copies for archival purposes. Still other forms you might use to initiate and feed into an electronic form’s process, much like the ordering process at the pizza restaurant I worked at.

I feel that paper forms are already so established and there is already so much written about them that I do not need to go into detail about their advantages and disadvantages. I just wanted to point out that there are any number of valid reasons to continue using paper forms even though I do not go into detail and instead now shift to focus on electronic forms.

Digital forms offer you the options and capabilities to provide richer user experiences, such as with incorporating sophisticated validation logic for any data-entry. Their digital state means that you can control access over a network, allowing you to store and manage the forms within a central location, and this enables you to track the status of forms and any related workflows. They also offer the possibilities to optimize their storage and retrieval, much like any digital document’s storage and retrieval strengths over a physical document, as I discussed in Chapter 4.

Modeling Paper Form Processes

A large proportion of the forms and business process workflow engagements that I get involved with focus on replacing a paper-based form with a digital one. I think this is such a common scenario these days that I want to spend some time sharing how I approach these requirements.

I begin with the paper form itself. On the form, I analyze the data it collects and I begin to consider these types of questions:

• What is the form’s main purpose or goal?
• Who can initiate a form’s process or submit a form?
• Are all the fields still necessary?
• Does the data already exist for any field that the form can query or infer to prepopulate?
• Do different users fill out different parts of the form? Who else is involved?
• Where will the form data be stored?
• What systems or processes rely on the data?
• What type of validation rules apply to a form and its fields?
• Does the form require any special security or auditing?
• How is the form stored and for how long?
• Does the form require any formal approval?
• Are there any requirements around how to capture signatures or the types of signatures?

The form requirements analysis questions I noted help prod different requirements for an electronic form because they build a complete picture of the form by considering it from different perspectives. With a solid understanding of a form and its purpose, I find that I am in a good position to visualize and model a digital solution.

I start with the forms, and in most cases, a lot of thought has already gone into which questions to ask—or more specifically, which fields to include on the form. I drop any questions that are no longer necessary and I look for ways to prepopulate any fields that can query or infer their data values. For the rest of the form, I generally just copy from the paper form, including details such as the question order and the form layout. Not only are these design decisions already thought through and proven, but they are also what the users are already used to in their experience with the form, making the digital form feel familiar and consistent. Thus, users perceive the electronic forms as a less drastic change from what they are used to using.

Before I finalize the form design, I look at the form from the perspective of the new technology (the digital technology) to consider whether the technology offers any options to improve the user experience with filling out and interacting with the form. Is there anything extra that digital offers over paper to improve the experience for a particular form? This can be things such as showing and hiding sections of a form based on field values that users enter, or even automatically capturing location information from a user’s computing device. Digital technology offers a wealth of possibilities like these that paper just cannot offer. I let the desired user experience drive these types of form design improvements.

With a digital rendition of the paper-based form, I then model the business process that the form progresses through. Essentially, this involves tracking all of the different people (roles) who interact with the form to identify what each adds to the form’s value-chain and who they hand the form to next.

One thing I watch out for is that with a paper-based form, the form only exists in one physical place at one time (unless, of course, if you photocopy it), so this can make a business process appear to be sequential. Certain tasks may be sequential, but other seemingly sequential tasks may actually be fine to process in parallel—a subtle change that can often dramatically optimize a workflow’s productivity since tasks will not have to wait on other tasks unnecessarily.

Let’s imagine a simple form and business process to model for an example by taking a simple expense report. The expense report itself contains identifying information for the submitter as well as lines for each expense item. Once submitted, a supervisor approves (or rejects) an expense report, and then someone in payroll issues a reimbursement. Figure 8-1 illustrates this simple expense report example.

I take these process models to build the actual approver workflow in SharePoint. Using the modeled form, I build an InfoPath form template to also deploy to SharePoint and associate with the workflow. Later in the chapter, I return to discuss how to build electronic forms and approval workflows, but first I want to consider how to analyze and model form processes when you are beginning from scratch, without any existing paper-based forms to analyze and build a model from.

Overview of InfoPath 2013

Microsoft InfoPath 2013 is a tool for designing sophisticated electronic forms to gather and process information from users. Its entire purpose centers on electronic forms—either providing a tool to design a form template or to fill out and submit a form.

I love InfoPath because it is so focused and specialized on managing forms well. I also love it because of the richness in its form editing user experience and the extensiveness of its form processing functionality. Specifically, I am thinking of these key features built into InfoPath:

• Tight integration with SharePoint, including sharing data fields as SharePoint columns and interacting with SharePoint workflows
• Simplified conditional formatting rules that support complex form designs
• Built in data-entry validation rules and warnings
• Capabilities to include code-behind for custom developed form logic and processing in Microsoft .NET

On this last point, you can programmatically interact with a form, workflow, or external data sources and web services. Although I do not go into detail on this topic in this book, I still felt it was worth mentioning because it opens up a variety of possibilities for custom solutions.

When you open InfoPath 2013, you have several options for the type of form you want to create, as shown in Figure 8-2.

InfoPath itself is a simple interface, as shown in Figure 8-3 with a form created using the SharePoint List template. Underneath this interface is an XML editing engine that merges the XSL in a form template with the XML data collected in the form itself, presenting a merged instance with the form structure and data. As you work with InfoPath, remember that it stores data in an XML format and the form template in XSL format, both independent of each other.

The client versions of InfoPath include the form designer and the form filler; the pair separates the design tasks from those related to filling out the form. This separation helps to reduce accidental changes to the form template while providing users with a rich client to use for interacting with forms. There is also a server version of InfoPath called InfoPath Forms Services that renders InfoPath forms as web pages. This allows users who do not have the InfoPath form filler client installed to also fill out SharePoint-hosted forms using their web browser.

I encourage you to explore the tool and all of its possibilities for your electronic forms. Although it sports a simplified interface and the ability to rapidly create electronic forms, it has a lot of functionality and complex processing capabilities. To get you started, I will walk through an example of creating a simple electronic form using InfoPath 2013.

Building Electronic Forms in InfoPath

InfoPath makes the process of building forms easy and seamless. Begin by opening InfoPath 2013 Designer and selecting a template to create a form based on. In this example, I created a form based on the SharePoint List template. You can configure and publish a form by following the steps in this section.

1. Add the relevant fields to the form and rename them to a meaningful name in the field properties window. In this example, I started using the SharePoint List template and added fields related to an expense report, as shown in Figure 8-4.

   

   Figure 8-4. The expense report form template

2. Add a button.
3. Select the Button Properties menu option form the button’s context menu.
4. In the Button Properties window, set the Action to Submit and give the button a label, as shown in Figure 8-5.

   

   Figure 8-5. The Button Properties window

5. Click Submit Options to open the Submit options window, as shown in Figure 8-6.

   

   Figure 8-6. The Submit Options window

6. Configure the form submit options by selecting to send the form data to a SharePoint document library.
7. For the Choose a data connection for submit option, Click the Add button to open the Data Connection Wizard.
8. Enter a document library URL to submit the form to and enter a formula for the file name that ensures forms are submitted to the SharePoint library with unique names, as shown in Figure 8-7.

   

   Figure 8-7. The Data Connection Wizard

9. Click Next and give the submit connection a name.
10. Click Finish to dismiss the Data Connection Wizard.
11. Click OK to dismiss the Submit Options window.
12. Click OK to dismiss the Button Properties window.

At this point, the form is ready for you to publish it to the SharePoint site. If you desire, you can adjust the submit options and the form options from the InfoPath form Info page, as shown in Figure 8-8.

When you are ready to publish, click the Publish your form button and select to publish to a SharePoint library. Enter the URL for the site you wish to publish the form to and click Next. Continue through the wizard setting the appropriate options and finally click Publish.

Once you publish your form successfully, open a browser and navigate to the form library where you published it. Click to create a new form and verify the form opens in the browser. In this example, I clicked to create a new expense report and it opened in the browser as shown in Figure 8-9.

Confirm that you can fill out and submit the form as expected. Once you are satisfied with the form and how SharePoint processes it, you can release the form for regular users to use in their processes. If you want to associate a workflow to the form to process it after users submit it, then you can also do that at this stage. One tool I use for creating these types of workflows is SharePoint Designer 2013, which I introduce next.

Overview of SharePoint Designer 2013

SharePoint Designer was first introduced as SharePoint Designer 2007. It is the evolution of Microsoft FrontPage 2003, a former web design editor that Microsoft redeveloped and rebranded for the advanced administration and design of a SharePoint site.

You can download and use SharePoint Designer from the Microsoft download site without any licensing costs. Any site administrator or site designer can install the tool to manage advanced aspects of the site, including the site’s visual design, forms, and workflows.

Microsoft developed SharePoint Designer to enable advanced users to rapidly create SharePoint solutions to meet business needs without requiring an extensive custom development effort or specialized web programming skills. The tool enables users to compose no-code solutions for a variety of common scenarios in an easy to use environment.

To open a site in SharePoint Designer, open SharePoint Designer 2013 on your desktop and click the Open Site tile on the Sites tab, as shown in Figure 8-10.

Alternatively, you can open a site by navigating to the site in a browser and clicking the Edit in SharePoint Designer button on the ribbon, as showing in Figure 8-11.

Once you have a site opened in SharePoint Designer, you can manage its different aspects through the tool. For some tasks, the tool will open a browser window and navigate to the relevant site settings page, such as for administering site security. For other tasks, you can accomplish them directly in the tool. To change the design of a page, open the page in SharePoint Designer and then edit its design. Figure 8-12 shows the SharePoint Designer 2013 interface.

The tool exposes several options in its user interface, including managing:

• Lists and libraries
• Workflows
• Site pages and page designs, site assets, and master pages
• Content types and site columns

I will leave the details behind the majority of the features in SharePoint Designer for you to explore and experiment with on your own. However, there is one particularly useful SharePoint Designer feature I want to focus on next: creating and configuring advanced workflows using the tool’s built in workflow actions.

Building Approval Workflows in SharePoint Designer

SharePoint Designer 2013 makes it easy to create and configure a workflow in SharePoint. I find it is not all that different from creating an e-mail rule in Microsoft Outlook 2013, at least conceptually. In this example, I will create an approval workflow to process the expense reports I created with InfoPath in an earlier section. The steps in this section will walk you through how to create a workflow using SharePoint Designer.

1. Open SharePoint Designer and open a site where you want to create a workflow. Click the Workflows option in the Navigation pane.
2. On the ribbon, open the List Workflow context menu and select the desired list or library. For this example, I selected the expense report library.
3. In the Create List Workflow window, give the new workflow a name and select the platform type.
4. Add the relevant actions and steps that you wish to include in the workflow based on the information you captured in the business process model that I described earlier in this chapter. For this example, I added a few approval-related actions that assign a task for a site owner to approve the expense report, and once approved, declare the expense report as a record. Figure 8-14 shows these actions added to my example workflow.

   

   Figure 8-14. Actions added to a new workflow step

5. In the workflow ribbon, click Publish to save and publish the workflow to the SharePoint site.
6. Navigate to the SharePoint site and click the item context menu for one of the expense reports. On the item context menu, select Workflows to navigate to the item Workflows page, as shown in Figure 8-15.

Start an instance of the workflow to test the workflow. Then verify the workflow details for the item by clicking the Completed link next to the item in the library to view the workflow details. Confirm that the workflow processed correctly and ended with the desired results.

Inside Story: Notes from the Field

My timing with writing this chapter is perfect, because I just engaged with a client to advise them on electronic forms and workflow while I was in the processes of writing. They are a nonprofit organization that runs fundraising campaigns, and all of their processes currently revolve around paper-based forms. Their customers, donors, fill out paper-based forms to submit along with their donation. Fundraising groups also fill out forms with organization and fundraising campaign information. Other forms exist to feed into the process for setting up payroll deductions or coordinating how to allocate funds. The process is very form heavy and involves a lot of repetitive data entry.

Data such as contact or campaign information repeats across the forms, causing repetitive data entry during the same process. Furthermore, in subsequent years when an individual or organization launches a new campaign, the data remains largely consistent, yet with the paper-based forms, the users have to repeatedly fill in the repetitive data. This experience of repetitive data-entry left users feeling as if their time was being wasted and some users expressed some discontent with the process.

What made this worse was that the users whose time was being consumed with repetitive data-entry were volunteer fundraisers. These volunteers were having time consumed with those administrative tasks, time where they could better spend doing fundraising activities.

Here we had our business case and the ultimate vision for the project: minimize any administrative burden for any fundraisers or donors so that their energies could be better spent fundraising—in short, to make their lives easier.

By replacing the paper forms with InfoPath forms and connecting those to a database, we were able to eliminate all the duplicate data-entry. We also achieved secondary benefits, such as exposing the real-time status of a fundraising campaign, providing rich reporting of which forms were still outstanding for a campaign, and increasing the overall collaboration and responsiveness between donors, fundraisers, and campaign organizers.

Wrapping Up

You manage your form content in the same fashion as any other unit of information in your enterprise content management solution. SharePoint 2013 offers a rich set of features to manage electronic forms, and specifically InfoPath forms, allowing you to incorporate them as simply another content type. In this chapter, I provided an overview of forms in organizations and I discussed the differences and similarities between paper-based forms and electronic forms. From there, I shared some guidance for modeling and designing your forms and form processes. Finally, I provided you with an overview of InfoPath 2013 and SharePoint Designer 2013, two tools available to help you build your electronic forms and their related processes.

With your transitory content organized along with areas for your users to collaborate on different pieces of transitory content, your next challenge is to help your users discover relevant content, either to collaborate, to reference, or simply to stay current. In the next part, I shift to focus on content discovery and how you can plan your enterprise content management solution around facilitating the discovery of relevant content, beginning with the next chapter where I discuss enterprise search and how a your enterprise search strategy provides the basis for key content discovery scenarios.