Every business and government entity needs forms that enable its users to input and share information. SharePoint 2013 presents a platform that allows for these forms to be hosted and integrated with many other useful technologies, such as workflows and search. Learn how to create forms using InfoPath, Access, and custom solutions in SharePoint 2013.

Creating InfoPath forms

Creating Access forms

Creating custom forms

Summary

MICROSOFT SharePoint has a long history of being a capable platform for hosting and managing business forms of all types. In the past, these forms fell largely into two categories: declarative (no code) and custom code. Depending on the specific requirements (or skills of the forms designer), SharePoint forms were generally created with Microsoft InfoPath, Microsoft SharePoint Designer, or Microsoft Visual Studio.

These options all still exist in SharePoint 2013, although SharePoint Designer is being deemphasized as a forms tool. InfoPath XML-based forms and Visual Studio 2012 custom forms are still fully supported as form design tools, and the integration they have had with SharePoint in the past is still available. For code-based solutions, your new form projects can piggyback on the support of HTML5 and .NET offered by SharePoint. Visual Studio 2012 is still the flagship tool for creating custom code forms, although with support for HTML5 and JavaScript, several new possibilities exist for responsive design, including TypeScript, jQuery libraries, and so on.

In addition to the aforementioned tools, SharePoint 2013 introduces one compelling, new option for no-code forms: Microsoft Access 2013 form apps. (We’ll discuss this more later in this chapter.)

Many factors go into the decision of which tool is best to create your forms with. Some of the factors are technical, some are business-oriented, and some are just pragmatic decisions based on what is possible.

Some of the strengths of InfoPath 2013 forms are:

Support for offline form-filling scenarios, where users are disconnected from the network

Deep integration with SharePoint libraries

Ability to customize SharePoint list forms

Options for rich-client or browser-based forms

Support for code-behind solutions using Visual Studio 2012

Some of the strengths of Access 2013 forms are:

Full support of the new app model

Integrated with the SharePoint app catalog

Form data is stored in Microsoft SQL Server

Inherits SharePoint site permissions and branding

Cross-browser and mobile support

Some of the advantages of custom code forms are:

Total control over the UI elements

Full support of the SharePoint app model

Ability to connect the form to all the various SharePoint application programming interfaces (APIs) and Web Services

Allows developers to publish their form to the public SharePoint store for customers to purchase it

Option to use a variety of industry-standard web-development tools

This chapter primarily focuses on the no-code solutions: InfoPath 2013 and Access 2013. A downloadable custom code example of the sample form written using HTML5 and JavaScript is available for download at www. .

For more information on building custom code solutions, see Chapter 23. “Introduction to custom development.”

Creating InfoPath forms

InfoPath 2013 is a forms-creation and data-gathering tool that can help you streamline your business processes. It is a flexible, powerful, easy-to-use XML forms editor that’s part of the Microsoft Office Professional suite. InfoPath 2013 is well suited for almost anyone that needs to design and deploy form solutions—including information workers, IT pros, and developers. You can use InfoPath 2013 to design sophisticated forms that can quickly and accurately gather information that meet your organizational needs. Moreover, its deep integration with the SharePoint platform opens up a new world of possibilities for your electronic form requirements.

Introduction to InfoPath

InfoPath empowers you to design and fill out electronic forms that are hosted on SharePoint, such as expense reports, event registrations, and other common business forms. When entering data in an InfoPath 2013 form, users are presented with familiar, document-like features. For example, they can change fonts, check spelling, or insert images into certain fields.

If you create your forms as browser-enabled form templates, users who do not have InfoPath installed on their computers can still work with the form in a browser. This lets you share business forms with a variety of users, including employees, customers, and vendors.

The forms that you design can range from simple forms for collecting data from a small group to complex forms that are integral components of a much larger business process. If you use SharePoint Server 2013 and SharePoint Designer, InfoPath 2013 forms can be used as part of a fully automated business process. This can include workflows, such as routing and notification based on information within the form. In addition, the data that users enter in your InfoPath forms does not have to remain sealed inside that form forever; it can be reused in a variety of ways within SharePoint.

InfoPath provides forms design capabilities that include sophisticated logic rules, conditional formatting, and data validation to information workers who may not be programmers. To benefit from these capabilities previously would have required a great deal of technical expertise. A large factor in the power of InfoPath is that the file format of the forms is XML, which provides many inherent benefits in terms of flexibility, power, and standardization. Fortunately, InfoPath forms designers are not required to know much about XML, XML schema definition (XSD) extensible stylesheet language transformations (XSLT), XSLT, and all the other technical details behind the scenes. The UI of InfoPath is essentially the same as the other Office 2013 products. If you are familiar with Microsoft Word, Microsoft Excel, or Access, you probably will feel right at home in InfoPath 2013.

INSIDE OUT

XML 101

XML is perhaps the single most powerful method of storing and sharing structured data to come along since the advent of digital computing. InfoPath uses XML as its primary file/output format. Behind the scenes, when users create an InfoPath form, what they are actually doing is creating an XML document and an associated XML schema. The fact that the file format that InfoPath uses to store and manage data is XML provides you with an amazing amount of power in an easy-to-use tool. InfoPath does an admirable job of allowing everyday business users of Office to take advantage of the plentiful benefits of XML while hiding much of the complexity. We do not need to become experts in XML to create powerful forms, but having a very basic understanding of what XML is and how it works seems a reasonable goal for someone planning to fully employ InfoPath’s power. For more information on XML, see the MSDN article “Understanding XML,” at http://msdn.microsoft.com/en-us/library/aa468558.aspx.

Form design basics

Most InfoPath forms that you create will have several basic design concepts in common. The form design process typically begins with the following two tasks:

Building the visual aspects of the form by using tables, themes, and page designs

Adding the necessary controls to provide the functionality and data fields that your form requires

Depending on the complexity of the form, you might need to do much more than this, but typically, the creation of most InfoPath forms starts with layout and controls.

As previously mentioned, InfoPath uses XML for storing data and managing the schema of the form for you. Most of the tools that you will use to build the form have a direct correlation to the underlying XML. However, InfoPath removes the need for you to interact with all of the XML “plumbing” behind the scenes. For example, when you add a simple text control, InfoPath automatically generates an XML leaf node (the XML equivalent of an InfoPath field) in the underlying XML schema.

When you open InfoPath on your desktop, the design time visual layout tools that you will use most often can be found on the ribbon, as shown in Figure 21-1.

Figure 21-1 The InfoPath ribbon includes the visual layout tools that you will use most often.

The following tabs on the ribbon are relevant to form layout:

Home. This is where you can find the basic text editing tools that you would find in a word processor. The functionality available on the Home tab is for controlling fonts—size, color, and so forth. These tools are fairly standard and work just as in the other Office products.

Insert. This is where you can find the prebuilt table styles. These tables can give your forms a consistent and professional layout.

Page Design. This is where you can find InfoPath’s predefined page layouts and color themes to quickly give your form a professional look and feel. The color themes are the same ones that are in SharePoint, so it’s easy to make your forms blend in nicely on a SharePoint site. Also, on the Page Design tab, you can work with Views and add headers/footers if necessary.

Layout. The tools on this tab (also known as the Table Tools tab) are used for modifying properties of the tables in your forms. Tables are the primary structural tool for organizing controls, labels, and images in your forms. This is also the location where you can use the Table Drawing tool if you don’t want to use any of the provided table styles.

There are multiple approaches to building InfoPath forms. The one that is most common is to simply begin with one of the built-in page layouts on the Page Design tab of the ribbon, add some tables and a color theme, and then begin adding data controls in order to complete the form’s functional requirements.

Along the way of the InfoPath form design process, there are many best practices. A few of the key ones will be highlighted in the next section as we dissect a completed form. If you require a comprehensive tutorial on InfoPath design, Microsoft Press and other publishers have entire books dedicated solely to InfoPath.

Walkthrough of the sample Site Request form

To illustrate the process of designing an InfoPath form, we will walk through the steps to create a sample Records Management Site Request form. This form uses several common InfoPath capabilities that are used when designing enterprise forms that are hosted on SharePoint. The purpose of this form is for employees of the Blue Yonder Airlines company to be able to submit a form to request that a SharePoint Records Management site be provisioned for them.

The form itself is not complex; it really is just gathering some basic information via a series of questions. However, the way in which the form is designed takes advantage of InfoPath’s ability to provide business logic, rules, and conditional formatting—all without writing any code. The form is built in a wizard-like approach that walks the user through a series of screens. The functionality in InfoPath that allows this to happen is provided by views. After gathering the information from the user, the final screen of the form gives the user a summary of his or her answers.

INSIDE OUT

Views

Your forms often will have too many controls to fit cleanly on a single page. One of the worst mistakes novice forms designers can make is putting everything on one page and forcing the user to scroll through an unnecessarily long and complex form—or even worse, creating multiple forms for users to fill out when having one consolidated form is far more efficient and manageable. InfoPath views can help alleviate these problems and solve a few other challenges as well.

A view in InfoPath is simply another view to display data from the same data source, but in a different way. It is perhaps easiest to think of a view simply as another page in the same form. If you create a second view, additional or different fields may be displayed, or even a completely different visual layout; however, underneath the covers, all the views in a form use the same data source(s) and XML schema.

What follows are some common situations where using InfoPath Views make a lot of sense:

Taking a lengthy or unwieldy form and breaking it into more manageable pieces.

Building a wizard-like or survey-like interface. Because you can use buttons with rules to switch views, views provide an easy way to build a form with multiple pages that a user clicks through.

Presenting different views to different users based on role. InfoPath Roles allow you to define which views a user can see depending on which security groups they are in. For example, your form might need to have an extra page of data that only members of the “Managers in Finance” group can see. (Note that Roles are an InfoPath client-only feature.)

Adding a view that is read-only for the purpose of confirmation when the user is finished with input. An entire view can be set to read-only, which makes it useful for a confirmation when a user is done filling out the form.

Providing a summary or roll-up view. Some forms need a dashboard that consolidates data from multiple other views into one place. Also, some forms might need a very different visual layout than the input views of the form.

Providing a print view. Similar to the summary view, a print view can be useful when you want to give users a page to print out data from your form, consolidated in one special view just for printing.

Opening the Site Request form in InfoPath

When you download the Site Request form, you’ll notice that the file extension is .xsn. This indicates that the file is an InfoPath template. When you have the form downloaded to your system, you will need to find the file in Windows Explorer, then right-click the file and choose Design, as shown in Figure 21-2. This will open the form in InfoPath 2013 in Design mode. If you were to just double-click the file, the file would open in InfoPath in Filler mode, as if you wanted to submit a new form. However, our goal for now is to take a high-level look at how the form is put together.

Figure 21-2 The steps to open the Site Request Design form in InfoPath Design mode.

INSIDE OUT

InfoPath templates

When you design a new form, you are actually creating an InfoPath template. The template is saved with an .xsn file extension. After you publish your template to a location that is accessible by your users, that they can create forms that are based on your template, but each instance that they create and save will be saved with an .xml file extension. So to recap, you use InfoPath in Design mode to create .xsn templates, which are published to SharePoint, where your users can go to generate new form instances (.xml files) based on your template.

Understanding the design of the InfoPath Site Request form

In this section, you will learn about the design techniques used to build the Site Request form. The approach we will use is to look at the form’s views one at a time and point out the most important design considerations within each view.

View 1 (Home)

When you open the form in Design mode, you should be taken to the first view of the form. To confirm this, you can select the Page Design tab on the ribbon. Once there, you will see a drop-down menu, as shown in Figure 21-3, that lets you navigate quickly between views while in Design mode.

Figure 21-3 The View drop-down menu on the Page Design tab lets you navigate quickly between views in Design mode.

Once you have confirmed that you are seeing the Home view, notice that this initial page of the form is actually quite simple. We are simply asking users to select what type of records they expect to keep in the new site they are requesting. If you look at the properties for the drop-down menu, as shown in Figure 21-4, you will see that they have six options to choose from.

In addition to a drop-down menu for the record type, the consumer of the form is given a text box in which they can type in some comments about the specifics of their request. After the user has performed these two tasks on the form, the only other item that’s of interest is the arrow graphic on the lower-right part of the Home view. This arrow is provided as a way to allow the user to navigate easily to the next screen (view) of the form. This is the first example in the form of using Rules to provide functionality in the form.

Figure 21-4 The Records Type drop-down has six properties to choose from.

NOTE

The arrow graphic is a special type of control in InfoPath called a Picture button. Picture buttons allow the designer to associate logic and formatting rules with graphics and icons.

Click the arrow graphic so that it is the active selection on the design surface. Once you have done that, ensure that you choose the Home tab of the ribbon and select the Manage Rules button. As shown in Figure 21-5, this will open the Rules pane on the right side of the InfoPath Designer.

Figure 21-5 Select the Manage Rules button from the Home tab to open the Rules pane on the right side of the InfoPath Designer.

This particular rule is an Action rule —simple, but useful. The rule simply dictates that when the form user clicks the arrow, InfoPath should take the action of moving them to the next view they will be working with. In this case, clicking the arrow will take the form user to the Formats view.

To see this in action, press the F5 key while inside InfoPath Designer. This will put the form into Preview mode so that you can easily see what the user experience will be at run time. When you have the form opened in Preview mode, click the arrow and notice that you are taken forward to the next view in the form.

View 2 (Formats)

If you are not already back in the Designer, close out of Preview mode and, using the Page Design tab on the ribbon, navigate to the Formats view. One of the first things you’ll notice on the Formats view is that we now have two arrow graphics on the form. Each of these Picture buttons has an Action rule associated with it that allows the user to navigate to either the previous view or the next one.

The primary purpose of the Formats view is to have the user choose whether their records are digital, physical, or both. Each of the icons in the middle of the view is associated (via a rule) with a record format. As with the arrow graphic, if you make one of the graphics the active selection in the Designer and then look at the Rules pane, you will see the details of the rule.

As shown in Figure 21-6, you will be able to see the logic assigned to any particular picture button. Notice that the rule sets both the value of the respective format field and the value of the DisplayLabel field at the same time.

Use the F5 shortcut to enter Preview mode while in Formats view. This will allow you to see what this view would do for the form user in Run-time mode.

View 3 (Questions)

If you are not already back in the Designer, close out of Preview mode and, using the Page Design tab on the ribbon, navigate to the Questions view. This view asks the user some questions about the nature of their requirements and then displays appropriate information. The method that the form uses to do this is Formatting Rules. The formatting rules in this view are primarily to show or hide information depending on the user’s answers. As with the previous two views, the Questions view also makes use of picture buttons tied to Action rules, but in a slightly different and creative manner.

Use F5 to enter Preview mode so that you can understand what this view performs when a user is in Run-time mode. After you have familiarized yourself with the functionality of the Questions view, return to InfoPath Designer.

INSIDE OUT

Conditional formatting

A common mistake that forms designers make is to try to display a large amount of information to users, thus overwhelming them and making the form difficult to use. As demonstrated with the Questions view, conditional formatting rules can help overcome this challenge by allowing the interface to dynamically show or hide sections of information, thereby greatly enhancing the form’s usability.

With the Questions view open in InfoPath Designer, click the Question Mark picture button, as shown in Figure 21-7.

Figure 21-7 When selected, the Question Mark picture button enables further explanatory text to be displayed.

Notice that once you select the Question Mark picture button, you will have a couple of items displayed in the Rules pane. There are two possible rules instantiated when the user clicks the button: a Show rule and a Hide rule. The purpose of the rules are to either show or hide the Help sections for each question. The Help section contains the actual help text. When the user clicks the question mark, the Show rule sets a Boolean field’s value to True. When they click it again, it sets the field’s value to False, as shown in Figure 21-8.

Figure 21-8 The Show Action rule is displayed when the Question Mark picture button is selected.

As you can see in Figure 21-9, each section also has a formatting rule that simply references its respective Boolean field to determine whether it should display the help text on the form.

Figure 21-9 A conditional formatting rule is being applied to a section of text.

To summarize, when clicked, the Question Mark picture button runs an Action rule that sets a Boolean field to True or False. The section containing the actual help text then references the hidden field via a conditional formatting rule to determine whether to show itself or not.

In addition to the Help sections, notice at the bottom of the form that additional Action Items informational sections will be displayed to the user depending upon his or her answers. In Figure 21-10, you can see that these Action Item sections will be shown or hidden using the same type of rules and logic as the above Help sections. Notice that the logic here tells the section that if the hidden Boolean field is not equal to True, hide the section.

Figure 21-10 At the bottom of the form, additional Action Items informational sections are displayed depending upon users’ answers.

View 4 (Summary)

If you are not already back in the Designer, close out of Preview mode and, using the Page Design tab on the ribbon, navigate to the Summary view. This view aggregates and displays information that has already been collected in previous views, as shown in Figure 21-11. It uses the same type of logic as the previous view did to determine whether to display any of the Action Items.

In Figure 21-12, you will see that the most interesting use of rules on this view is once again using a picture button with a Switch View Action rule in order to allow users to return to a previous view to edit their answers.

Figure 21-12 A Switch View rule is being applied to a picture button in the Summary view.

Publishing InfoPath forms to SharePoint libraries

One major component is missing in the Site Request form that you will need to add to a form like this in the real world—a Submit button. If you want to have your users easily submit (save) the form to a SharePoint form library once they are done filling it out, the best practice would be to add a nice large SUBMIT THIS FORM button somewhere on the last view. In order to do this, you or your SharePoint administrator will need to create a SharePoint form library for your forms to be published to. And then you will need to add a button to your form that uses an InfoPath rule to submit to a data connection. In our case, the data connection would be a SharePoint library.

NOTE

If creating a SharePoint form library is unfamiliar to you, there is plenty of information online regarding SharePoint form libraries. Also, an entire chapter in Using InfoPath 2010 with SharePoint 2010 Step by Step (Microsoft Press; 2011) focuses on publishing and submitting InfoPath forms. The content is still relevant for the 2013 version of InfoPath, which has not changed much since the prior version.