Plan a forms-driven application (SharePoint Server 2010)

  • Article

 

Applies to: SharePoint Server 2010

Many SharePoint Server applications contain InfoPath forms. A subset of these applications are actually driven by a form. These form-driven applications usually share the following characteristics:

  • They automate a business process, such as placing an order or completing employee performance evaluations.

  • There is a key piece of structured information, instances of which flow through different activities to complete the business process.

Although each form-driven application is unique, the structure found in form-driven applications often is of a common design. If your application fits this common design, you might be able to use the design presented in this article and modify it to fit your specific case.

This article describes a design for a particular kind of Microsoft SharePoint Server 2010 application that uses forms. It does not cover how to design other kinds of SharePoint Server applications or how to design the forms themselves. For more information about how to design Microsoft InfoPath 2010 forms, see Office.com (https://go.microsoft.com/fwlink/p/?LinkId=187550&clcid=0x409).

In this article:

  • Structure of a form-driven application

  • About planning a form-driven application

  • Identifying the key piece of information

  • Using a list or a form library

  • Workflow

  • Additional data sources

  • Portals

  • Summary

Structure of a form-driven application

A complex form-driven SharePoint Server application can contain the following components:

  • A SharePoint site in which to host the application.

  • A form template that captures the core piece of information. The form template might have different views for different groups of users or for different stages of the information’s life cycle.

  • A SharePoint list or library in which to store instances of the completed form template (known as forms).

  • A workflow that routes an item through a business process. The workflow starts when a new form is created.

  • SharePoint lists that contain auxiliary information that is used to populate fields in the form template. Forms and workflows might be associated with these lists to manage the information in the list.

  • External databases or line-of-business (LOB) applications that provide data for the form template or the workflow.

  • Business logic represented as validation rules in the form template or as part of the workflow.

  • A Web page that serves as a portal and enables users to create a new instance of the form template and to view other information about the forms. There might be multiple portals for different audiences.

Your application does not have to match this structure exactly. Some form-driven SharePoint Server applications do not contain all these components, and other applications add small variations, such as having more than one workflow.

About planning a common form-driven application

To design a common kind of form-driven application, you first determine the key piece of information that drives the business process. Then you decide whether to store the information in a SharePoint list or a library, and define the workflow that is used to process the information. Next you determine any additional data sources that will be needed. Finally, you design the portals through which users will access the application.

Identifying the key piece of information

The first step in planning a form-driven application is to determine the key piece of information around which the application revolves. In many situations, the key piece of information is obvious. In a helpdesk application, for example, the key piece of information is probably a service request. In an employee performance review process, the key piece of information is probably a performance review form. In a purchasing system, the key piece of information is probably an order.

Identify the key piece of information that drives the process. If the key piece of information is not obvious, consider the following suggestions:

  • If the application will automate an existing process, is there a document or a file that is handed off from one person to another as the process progresses? That document or file is likely to be the key piece of information.

  • Does a process start when an item is created or when an item appears in a certain location? That item could be the key piece of information.

  • The key piece of information probably has some structure, and might grow or change as it is processed. For example, an order contains the customer’s name and address, a list of items complete with quantity and price, and other details. More information such as a tracking number is added to the order as it is processed.

  • The key piece of information probably has a status associated with it, and the status changes over time.

If you cannot determine the key piece of information that drives the process, the design presented in this article probably does not fit your application.

When you implement the application, you will create a form template for this key piece of information. This form template will be called the “core form” throughout this article.

Using a list or a form library

Determine whether you will store instances of the core form in a SharePoint list or in a SharePoint Server form library.

If possible, use a list. A list-based solution is simpler and more efficient. However, there are certain situations in which a list will not work. If any of the following conditions is true, use a form library:

  • You have to keep a history of changes to form instances.

  • The core form contains repeating sections, such as an arbitrary number of accomplishments in an employee’s review form.

  • The core form has nested data, such as an order form that contains an item, where an item can contain a product code, a quantity, a size, and a price.

  • The core form will contain code.

    The following are some situations in which a form might contain code:

    • The form includes buttons that perform custom actions.

    • The value of one field in the form is based on a complex combination of other values in the form.

  • Instances of the core form will be digitally signed.

  • You have to store data about each instance of the core form in XML.

If you store instances of the core form in a list, each field in the core form will become a column in the list, and each instance of the core form will become a list item. If you store instances of the core form in a form library, each instance will be turned into an XML document, and the documents will be stored in the library.

Workflow

The business process starts when something happens to an instance of the core form. Often, creating a new instance of the core form itself starts the business process, but other events such as an instance of the core form being modified or being assigned to a person could also start a process.

The business process routes the instance of the core form through the people and systems that have to perform actions. If the core form were a service request, for example, creating a new service request might start a process that assigns the service request to a service representative to interact with the person who originated the request. The service representative might take various actions depending on the outcome of the discussion with the originator: for example, escalate the request to a senior representative, mark the request as resolved, forward the request to the orders department if the originator should be sent a replacement, and so on.

Identify the steps and decision points that are involved in processing an instance of the core form. This sequence of steps will be represented in SharePoint Server as a workflow. For more information about workflows, see Plan workflows (SharePoint Server 2010).

Additional data sources

A form template can retrieve data from external sources such as a database, a Web service, or a SharePoint list. One common use for external data is to populate a list of valid values for a field in the form template, such as a list of cost centers. You could also use a rule to calculate the value of one field based on a combination of external data and the values of other fields. For example, the value of an “approver” field might be obtained by using an external data source to look up the manager of the employee whose name was entered in the “submitted by” field.

Identify the external data that the core form will access. For each source of external data, indicate where the data comes from. For example, does the data come from a SharePoint list, an SQL database, a LOB system such as SAP, or some other source?

Note

You can access some LOB data directly from SharePoint Server lists by creating an external content type. For more information about how to create external content types, see Business Connectivity Services overview (SharePoint Server 2010).

For any SharePoint lists that provide data to the core form, consider how you will manage the data in the list. Will you create a form to enter new data in the list? Are workflows needed to manage items in the list? For example, if the core form uses a list of cost centers, you might add an Approval workflow to the list.

Portals

Who will use the application? Are there different user roles, with members of one role performing different actions or viewing different information than users of other roles? If users in different roles will do different things with the application, consider creating a portal for each role. Tailor the actions and information that are available in each portal to the role of users who are using the portal.

For example, in an employee performance review application, there are probably at least three roles:

  • Employees, who complete performance review forms.

  • Managers, who add information to performance review forms and approve performance reviews.

  • Human resources professionals, who create reports and aggregate information from performance reviews.

Employees would access the performance review application through an employee portal that could enable them to create a new performance review form and to track whether their own performance review was approved by their manager. Managers would access the application through a manager portal that might show a list of their employees with an indication of whether the employee had already submitted a performance review form, and a link to open an employee’s performance review form. Human resource professionals would access the application through an HR portal that might show summary statistics of how many performance review forms were approved, submitted but not yet approved, or not yet submitted.

The simplest kind of portal to create is merely a view over the SharePoint list or library in which instances of the core form are stored. You can use a filter or apply conditional formatting to customize the view to the specific user.

You can also design a custom Web page for each user role, and give each user the URL appropriate to their role to access the application. On the portal Web pages, you might include some of the following elements:

Summary

If you have been able to determine characteristics of your application that correspond to most of the previous sections, it is likely that you can implement the application by following the paradigm of a form-driven application. Create a SharePoint site to host the application. Create a form template for the core form; create a list or a library to store instances of the core form; and associate the form template with the list or library. Add a workflow that is triggered when a new form is added to the list or library. Create and populate any additional lists that are needed to provide data for the form template. Create one or more portals through which users will interact with the application.

See Also

Concepts

About forms in SharePoint Server 2010
InfoPath forms administration (SharePoint Server 2010)

Other Resources

Resource Center: Workflows in SharePoint Server 2010