The metadata for a content type can consist of either site columns or list columns. Site columns are reusable columns that are defined at the site level and may be used by any list in a child site. List columns are defined at the list level and may only be used by the list where they are defined. When you create a new content type, it will inherit the site and list column definitions from its parent. You can also add any of the previously defined site columns that are available. Finally, you can define your own new columns and add them to the content type. As you can see, it is important to determine what metadata fields you will need to properly support your information structure before you begin creating content types.

When you create a new column, you assign it a name and select a data type. SharePoint offers you many different types, from simple text and lists to full HTML. Depending on the type, you may also have to specify additional information to complete the column definition. When you create new columns, they may also be grouped together under a custom heading so that they are easier to find later. As an example, I'll create some site columns to use with the software specification document.

Follow these steps to define the site columns:

Site and list columns play a critical role in SharePoint. Not only are they used to classify information, but they can also be used to create views that sort and filter lists. Additionally, they can be indexed to speed the display of lists within the browser. Creating a view of a list is done in this version of SharePoint in much the same way as in the previous version. The existing views are listed on the Customize page, which is accessible from the list by selecting Settings

Creating a Standard View of a list results in a columnar display of the list that may be sorted, filtered, and grouped. Creating a Datasheet View of a list results in a tabular display that allows editing of all data in a single web page and includes a fly-out task pane that provides quick links to editing tools. Calendar Views require that one column in the list be a date/time dimension so that a calendar can be created using the list data. Gantt Views of a list create a Gantt chart view, but they require a list to have columns that can be mapped to Title, Start Date, and Due Date fields. An Access View is used to link a SharePoint list with a Microsoft Access 2007 database, which allows you to use Access to create reports and views.

Using List Data in Microsoft Access

SharePoint lists can be used in Microsoft Access 2007 in two key ways: list data can be imported into Access databases or lists can be linked to an Access database. Selecting Actions

Linking a SharePoint list to an Access database is similar to creating a new Access View for a list. The difference is that creating an Access View will automatically prompt you to create a new view for the list, whereas simply linking the list just creates a new database and you have to create any new views manually. In both cases, the term view really refers to either a form or a report created in the Access database.

After you create forms and reports in the new database, you may publish the database to a SharePoint library so the forms and reports can be viewed by end users. This is accomplished by clicking the Publish to SharePoint Site button inside of Microsoft Access. Figure 6-1 shows the button as it appears in the Document Action Panel of Access.

Figure 6.1. Publishing an Access database to SharePoint

Once published, users can open the Access database directly from the document library. Once opened, they may use the forms and reports as they would for any Access application. They may even take the entire database offline and synchronize their changes later. Figure 6-2 shows the SharePoint Lists group and the Work Offline button.

Figure 6.2. Working offline with Microsoft Access

Using List Data in Microsoft Excel

SharePoint lists are used in Excel spreadsheets by exporting the list. Selecting Actions

You should note, however, that the data connection operates in only one direction. This means that you can refresh your workbook data from the list by clicking the Refresh button in the Workbook Connections dialog. However, you cannot push the changes you made in the spreadsheet back to the SharePoint list. While this was possible under Excel 2003 and SharePoint 2003, it is not possible in the 2007 versions. This behavior is potentially dangerous because changes made to the spreadsheet data manually can easily be overwritten by refreshing the data connection. To avoid this, you may want to remove the data connection from the workbook.

All document libraries and lists in SharePoint utilize content types. The content types help determine the columns that appear in the library, the types of new items you can create in a list, and the workflows associated with the list. When you are creating a list or a library, however, you are not given the opportunity to associate content types with it. Instead, you are either given a default content type (for lists) or asked to select a document template (for libraries). In order to change the content types associated with a list or a library, you must explicitly enable management of content types.

Enabling content type management for any list or library is done from the Customize page. On the Customize page, click the Advanced Settings link where you can select the option to allow management of content types. Figure 6-3 shows the option.

Figure 6.3. Enabling content type management

Once you enable content type management, you can add new content types to the list. When a new content type is added to the list, all of the columns defined in the content type are copied to the list. Note that lists and libraries never use site columns directly. Instead, the site columns associated with the content type are copied as list columns. Any changes made to a list column will not be reflected upward into the site column. In fact, you can never push changes up from any child content type or column to a parent. However, you can push changes down. Whenever you make a change to a site content type or site column, you can select an option to update all of the associated children.

Adding content types to a list or a library is also done through the Customize page. Once content type management is enabled, you will see the default content type on this page. For document libraries, it will be the Document content type. For other lists, it will be the content type for the default list item such as Event or Task. On this page, you can add new content types from the gallery and change the order in which they appear on the New button in the list toolbar.

Follow these steps to add a content type:

Figure 6.4. Adding a new content type

Once you add a content type to a library, you will be able to make new documents based on that type. Therefore, you'll want to define a document template that users will see when they create a new document of that type. Adding a document template to the content type is done by accessing the content type through the Content Types Gallery. When you are viewing the content type definition, click the Advanced Settings link and you will be able to upload a new document template to associate with the content type. Figure 6-5 shows the upload function.

Figure 6.5. Uploading a document template

Document libraries in SharePoint 2007 have some nice improvements over earlier versions. Some of these improvements, such as the recycle bin, I have mentioned previously. In this section, I review the new capabilities in more detail. These capabilities include new versioning settings, document policy settings, the recycle bin, item-level security, and item-level audience targeting.

Configuring Versioning Settings

As with any document management system, you would expect SharePoint libraries to have check-in, checkout, and version control capabilities. In this version, however, these capabilities are improved. From the Customize page, you can configure these functions by clicking the Versioning Settings link. On the Versioning Settings page, you can turn on versioning for a list or a library. You can also specify whether to version only major versions or both major and minor versions. Creating minor versions allows you to have draft versions that are only visible to selected individuals. These options give you a rudimentary process for creating, reviewing, and approving documents without the use of a workflow. Figure 6-6 shows the versioning settings.

Figure 6.6. Versioning settings

Configuring Policy Settings

Document policies allow you to configure document labels, auditing, expiration dates, and bar codes for each content type used by the library. Document labels define text that will appear when the document is printed to help track its source and key information. Auditing allows you to track key documents events and changes along with the identity of the person who initiated the event. Expiration dates allow you to delete a document or initiate a workflow after a given period of time. Bar codes allow you to generate a bar code for the document for tracking.

Take these steps to configure policies:

Now you can return to the document library and create a new document. Enter some text in the document and then save it. When you try to save it, you should be prompted to add a label to the document and a bar code. Additionally, you should see the policy statement appear within Word to let you know that policies have been defined for the document. Your policy should also be auditing your actions as you work with the document, and you can run a report.

Follow these steps to run an audit report:

Managing the Recycle Bin

Adding a recycle bin for SharePoint libraries was perhaps the most requested enhancement from the previous version. That's because there was no simple way to recover a deleted file in the previous version of SharePoint. Instead, administrators would have to completely recover a site from backup and retrieve the lost file by hand. With the recycle bin, users can recover their own files.

The recycle bin is actually a two-stage bin. This means that even if a user deletes the file from the library and the recycle bin, it will still be available in an administrator recycle bin. The end user recycle bin is located at the site level. The administrator's recycle bin is at the site collection level. At this level, administrators have a special view that shows the items that were deleted from other bins.

Administrators can set the time that a deleted file will remain in the recycle bin and the storage quota of the second stage bin so that old files do not take up space unnecessarily. This allows you to set a policy for users that deleted files can't be recovered after a given period.

Follow these steps to configure the recycle bin:

Managing Item-Level Security and Audiences

Along with the recycle bin, item-level security was another high-priority request from SharePoint users. In the previous version of SharePoint, security could only be set at the library level. In this version, you may use the drop-down menu for an item and select Manage Permissions to set the security just for that item.

Along with permissions, you can also manage the visibility of an item through audiences. In order to associate a document with an audience, you must first enable audiences for the library as a whole, which is done from the Customize page by clicking the Audience Targeting Settings link. Once audiences are enabled for the library, each individual item will have a Target Audiences property that you can set.

Configuring Column Indexing

Indexing a column is intended to improve the performance when displaying a view. You can index any column in the list directly from the Customize page by clicking the Indexed Column link. However, you should note that indexing a column will not remove the soft 2,000-item limit for a view. Indexing only increases the speed at which those items are displayed. Therefore, while a list or library may contain a virtually unlimited number of items, you should only create views that return 2,000 items or less.

Creating a template part is a new capability of InfoPath 2007 that lets you build reusable sections for forms. With this capability, you can create a library of template parts for use in form design. This makes it easier to create new forms using the template parts as a starting point. As a best practice, you should start by creating a content type to represent template parts within SharePoint. After you create a content type, you can create a library to store them.

Follow these steps to create a content type:

Once you have created a new content type with a blank template part, you can use it in a library. Creating a template parts library is a good idea because it allows template parts to be accessed by form designers throughout the enterprise. This approach saves a lot of time and ensures consistency across all forms.

Follow these steps to create a template parts library:

After you have created a library to store template parts, you can create new template parts from Microsoft InfoPath. Using this approach, you can build up a library of reusable parts. As an example, I'll build a reusable part that contains basic customer information.

Follow these steps to create a template part:

Figure 6.7. Creating a template part

While creating template parts is a good way to build up a library of components for form development, they do have limitations. Template parts do not have all of the functionality of an InfoPath form, and that can be a bit frustrating. For example, you can't write any script or managed code behind a template part. The following is a complete list of functionality not available to template parts:

Many organizations have moved away from paper-based forms and made a significant investment in electronic forms. These electronic forms may be Word documents, Excel spreadsheets, Adobe forms, or other formats. Because of this investment, it has not been a simple matter for them to implement InfoPath forms. InfoPath 2007, however, includes a template import feature specifically designed to migrate electronic forms to InfoPath.

Out of the box, InfoPath 2007's import feature can handle Word and Excel forms. For other form types, InfoPath provides a set of interfaces for creating your own importer. Creating your own importer is beyond the scope of this book; interested readers should check out the InfoPath 2007 SDK.

Follow these steps to import a Word document:

After the form is imported, the Import Wizard will notify you if there were any issues converting the form. When it discovers issues, the wizard will refer you to the Design Checker to investigate the issues. The Design Checker is a new feature of InfoPath 2007 that assists you in not only importing forms but also making forms that are compatible for different deployment scenarios. I discuss using the Design Checker for deployment scenarios a little later in this section, but for now you can review any issues with the import using the Design Checker, which will appear after you close the Import Wizard. Figure 6-8 shows the Design Checker in my environment after the import.

Figure 6.8. The Design Checker

InfoPath forms often use data connections to databases, web services, and other sources to retrieve information such as lookup lists. In the past, these connections were always defined as part of the InfoPath form. In InfoPath 2007, however, you can use a SharePoint data connection library to store connection information that may be used across the entire organization. These are the same data connection libraries that I discuss in Chapter 4 in relation to Excel Services, except the file format is different. Excel Services utilizes Office Data Connection (ODC) files, whereas InfoPath utilizes Universal Data Connection (UDC) files.

Selecting Tools

If you created the data connection library in Chapter 4, you can follow these steps to create a UDC file in InfoPath:

Over the past nine years or so, Microsoft has supported Office developers with a built-in development environment known as Visual Basic for Applications (VBA). VBA was intended to be a simplified development environment for creating macro functionality within Office products. Typically, developers would detect events such as document creation and then exercise the Word or Excel object model to provide customized functionality such as data imports.

While VBA applications worked fine for a number of applications, VBA was created when the component object model (COM) standard was the prevailing technology for Microsoft development. As we all know COM has been steadily replaced by the .NET standard for development, but Microsoft Office continues to lag behind. Unfortunately for Word and Excel, this will remain the case in Office 2007; however, InfoPath has a new development environment known as Visual Studio Tools for Applications (VSTA) that finally brings managed code development to the Office suite.

VSTA is not installed by default when you install Microsoft Office 2007; it is an advanced installation option. To install VSTA, launch the Office 2007 installation disk and select to Add or Remove Features. You'll then be able to locate the VSTA installation under the Microsoft InfoPath options. Figure 6-9 shows the VSTA installation location.

Figure 6.9. Installing VSTA

Once you have VSTA installed, you'll want to set your programming language in InfoPath to use C#. This is done by selecting Tools

Writing VSTA code in InfoPath is a familiar experience for anyone who has used Visual Studio before. You can set references to .NET assemblies and utilize any of the classes contained in the .NET Framework. However, there are a couple of areas where development is unique to InfoPath. These areas concern accessing elements in the InfoPath form and managing trust levels.

Accessing Form Elements

Whenever you write VSTA code, you will almost always want to manipulate the field values in the form. Field values are accessed through the XPathNavigator class, which is used to reference the form's data source. The following code shows how to reference the form's data with the XPathNavigator class:

XPathNavigator data = this.MainDataSource.CreateNavigator();

Once you have a reference to the form's data source, you can use XPath to access any individual element on the form. This is accomplished by using the SelectSingleNode method of the XPathNavigator. The SelectSingleNode method takes as an argument the XPath that references the target element. Figuring out the correct XPath string necessary to access a given element can be tricky. Fortunately, you can retrieve the XPath for an element directly from the Data Source pane in InfoPath. Figure 6-10 shows the Copy XPath menu item in the Data Source pane.

Figure 6.10. Retrieving the XPath for an element

Once you have the XPath for a target element, you can paste it in to the code and use it to retrieve the target element as an XPathNavigator object. Using this object, you can read the element through the Value property or set its value through the SetValue method. Listing 6-1 shows a simple example of setting the username element in a form to the username of the person filling out the form.

using Microsoft.Office.InfoPath;
using System;
using System.Xml;
using System.Xml.XPath;
using System.Security.Principal;

namespace Travel
{
    public partial class FormCode
    {

        public void InternalStartup()
        {
            EventManager.FormEvents.Loading +=
              new LoadingEventHandler(FormEvents_Loading);
        }

        public void FormEvents_Loading(object sender, LoadingEventArgs e)
        {
            //Get a reference to the User Name element
            XPathNavigator data = this.MainDataSource.CreateNavigator();
            XPathNavigator element =
              data.SelectSingleNode(
              "/my:travelRequest/my:username", this.NamespaceManager);

            //Show user name
            WindowsIdentity identity = WindowsIdentity.GetCurrent();
            element.SetValue(identity.Name);

        }
    }
}

The best thing about VSTA is that all of the code is part of the InfoPath form. This means that you do not have to deal with separate assemblies that must be distributed to clients. You also do not have to configure client-side code access security (CAS) settings as was necessary in previous versions of InfoPath. You do, however, have to manage the trust level of the form.

Managing Form Trust

InfoPath forms can operate at three different trust levels: Restricted, Domain, and Full Trust. Restricted forms are not allowed to access any data that resides outside the form itself. Domain forms can access data that comes from within the same domain as the form. Full Trust forms have no restrictions on the operations that they can perform.

By default, InfoPath is set to automatically select the appropriate security level for your forms. This typically means that forms operate with Domain trust. Domain trust is appropriate for most of the operations you will perform in a form. Some forms, however, may need an increased trust level to function correctly. Such is the case for the code in Listing 6-1, which tries to use the WindowsIdentity class to access information about the current user. If you want the form to operate with a different trust level, you must set it manually.

You can change the trust level of a form by selecting Tools

In order to change the form's trust level, you must not only select the Full Trust security level, but you must also sign the form template with a digital certificate. If you have an appropriate digital certificate available, you simply check the box labeled Sign This Form Template, click the Select Certificate button, and pick a certificate. If you do not have a certificate available, you can make one by clicking the Create Certificate button.

If you deploy a form that performs operations that require full trust and you do not properly modify the form's trust level, you will receive typical security error messages from the .NET Framework. If, on the other hand, you sign the form with a certificate you created yourself, the end user will receive a message indicating that the certificate is not from a trusted source. In this case, the user can choose to trust the form, but you had better make this clear to end users before they receive the message shown in Figure 6-12.

After you finish creating your forms, you will want to publish them using the Publishing Wizard so they can be used by others. In Chapter 3, I showed you how to create a form library in SharePoint and publish a form to it. Beyond simply publishing a form, however, you can also use the Publishing Wizard to deploy your form and associate it with a new content type. You can then use the content type in multiple libraries throughout a site.

Figure 6.11. Accessing security information

Figure 6.12. InfoPath security warning

Follow these steps to create a new content type:

While InfoPath is a good tool for creating forms, almost the instant it was released, customers began to request a way to fill out forms without having the InfoPath client installed. There are many scenarios, such as personnel on the road, or clients without access to InfoPath, where a zero-footprint form is useful. Microsoft's response to this need was to create InfoPath Forms Services.

InfoPath Forms Services allows you to take InfoPath forms and render them as HTML in a browser. InfoPath Forms Services is technically a separate product from SharePoint, however, MOSS ships with it. The server is set up automatically for you during the MOSS installation process.

Before you can begin using forms in the browser, you must make sure that InfoPath Forms Services is enabled at the farm and site level. You can access the configuration settings for InfoPath Forms Services from the Central Administration site. On the Application tab, you will find a section dedicated to InfoPath Forms Services. Here you can click the link titled Configure InfoPath Forms Services. This link will open a configuration page where you can enable services for the farm.

After you have enabled services for the farm, you must activate the Office SharePoint Server Enterprise Site Collection Features for each site collection where you want to use InfoPath Forms Services. Additionally, you must activate the Office SharePoint Server Enterprise Site Features for each site where you want to use InfoPath Forms Services. Note that there are features at both the site collection and the site level that must be activated for InfoPath Forms Services to work correctly.

Designing for InfoPath Forms Services

Most of what you know about creating forms in InfoPath also applies to forms that target InfoPath Forms Services. However, there are many InfoPath features that can't be duplicated in a browser, such as master-detail views. Therefore, when you create a form for use with InfoPath Forms Services, it will always be limited to a subset of features that are available to InfoPath as a whole. As of this writing there is not a definitive list of lost InfoPath functionality; however, you can use the Design Checker to help ensure compatibility.

The Design Checker is available as a link in the Design Tasks pane in InfoPath. Clicking this link opens the Design Checker task pane, which shows errors and messages for the current form. Before you can get any meaningful information, however, you must change the compatibility settings for the form to indicate that you are targeting InfoPath Forms Services. Clicking the link titled Change Compatibility Settings opens the Form Options dialog where you can check a box to indicate the form should be browser-enabled. You should also provide the path to VSMOSS so that InfoPath Forms Services can verify compatibility. Figure 6-13 shows the browser compatibility options.

Figure 6.13. Changing browser compatibility

Once you have changed the compatibility settings, the Design Checker will begin to display errors and messages regarding your form. Each error or message will show not only in the Design Checker task pane, but also in the form or dialog box where the issue can be addressed. Furthermore, the Design Checker provides hyperlinks that will take you to each issue so that you can fix them. Figure 6-14 shows the Design Checker with an error message in the task pane and the same error flagged on the form.

Figure 6.14. The Design Checker

After you have created a browser-compatible form, you will be able to publish the form to a form library in SharePoint. Here again, you can publish the form directly to a library or as a content type. If you publish the form directly to a library, it will be available immediately. If you publish the form as a content type, you'll need to create a library and associate the content type with the library so it can be used.

After you have created a form library with your new form available, you can create a new form using the toolbar and fill it out. However, you'll notice that the form does not initially open in the browser as you would expect. This is because the library has an option you can set to specify the preferred client for the form. The default is to always open the form in InfoPath if it is available. This setting is accessible from the Customize page for the form library by clicking the Advanced Settings link. On the Advanced Settings page, you can change the Browser-Enabled Documents setting for the library to always display the document as a web page. Because the setting never mentions forms, it's easy to miss. Figure 6-15 shows the correct configuration to display forms in the browser by default.

Figure 6.15. Displaying forms in the browser by default

Deploying Centrally Managed Forms

When forms require full trust, they may not be published directly from InfoPath to a form library. Instead, fully trusted forms must first be uploaded into a central management store where they can be reviewed by a SharePoint farm administrator. Once reviewed, these forms are deployed from a central store to selected web applications where they can be made available to libraries or act as templates for content types.

In order to deploy a fully trusted form, you must first use the Publishing Wizard to prepare the form. As part of preparing the form, InfoPath publishes it to a network location of your choosing so that it can be accessed by the SharePoint administrator. Figure 6-16 shows the Publishing Wizard set to prepare a form for administrator approval.

Figure 6.16. Preparing a fully trusted form for approval

Once the form is prepared, it may be uploaded to the central repository. This is accomplished through the Central Administration web site. On the Application Management tab, under the InfoPath Forms Services section, click the link titled Manage Form Templates. This will display the forms stored in the central repository and allow you to upload new forms. During the upload process, you can even have the form validated for errors before it is added to the repository.

After the form is added to the central repository, you may use the drop-down menu associated with the form to make it available to a site collection on the farm. Selecting Activate to a Site Collection from the menu will bring up a page where you can select the site collection where the form will be deployed. Clicking the OK button deploys the form into a library named FormServer Templates. This library is not visible from within SharePoint, but you can see it if you open the site in the SharePoint Designer. The point, however, is that once it's deployed, you can reference it as a template for a content type within the site collection.

Before you begin this exercise, you should have read through the InfoPath information in this chapter. Additionally, you should have created the Template Parts library from the "Creating Template Parts" section earlier in this chapter and built the sample template part for entering customer information. This exercise will make use of this template part to create a form for customer issues.

For this exercise, you will create a new site for tracking customer issues. This site will have a form library that will contain the form for tracking issues. Therefore, you'll need to create this site before building the form.

Follow these steps to create the new site:

The form that you'll create will contain a list that will allow you to categorize the customer issue. This list will be maintained in the SharePoint site so that it can be edited when necessary. You will subsequently utilize the list in your form by using a data connection.

Follow these steps to create the new list:

The Customer Issues form will utilize several of the new features of InfoPath and SharePoint. You will use template parts to help create the form, the Issue Categories list as a data source, a form library for saving the forms, and a simple workflow to route the issue for review. Once the forms are saved, you'll use library views to analyze the data.

Follow these steps to create the InfoPath form:

Creating the Data Connection

The CustomerInformation template part acts as the header for the new form. The body of the form will have the description of the problem and allow the user to select a category. The category will be driven by the Issue Categories list you created earlier.

Follow these steps to create the data connection:

Creating the Form Body

Once the data connection is created, you can use it to populate a list in the Customer Issues form. The category list along with a text area will make up the body of the form. The form can then be published to the Customer Issues site for use.

Follow these steps to complete the form:

Figure 6.19. The Customer Issues form

Once the form is completed you are ready to publish it to the site. In our scenario, you want the form to be accessible over the web. Therefore, you will publish the form so that it can be delivered via InfoPath Form Services. This means that you must run the Design Checker and publish the form to be delivered across the web.

Follow these steps to publish the form:

Once the form is published, it is available for use. However, you want to configure the new library so that it delivers the form through the browser by default. Additionally, you are going to use a built-in workflow to route the form for review.

Follow these steps to configure the library:

Once the new form is published and the library is properly configured, you are ready to use the form. You should now be able to fill out the form with customer information and details about the problem. The category list should also be populated from the SharePoint list you created earlier. Additionally, you should be able to route the form for approval when the issue is resolved.

Follow these steps to fill out a form:

Before getting started with this exercise, it's important to note that you must have MOSS available to complete it. Records management is a MOSS capability and is implemented through a special web service and site template. WSS alone simply doesn't have the functionality.

Another thing you'll want to do before you get started is to download some document templates from the Microsoft Office site. In this exercise, you will create both an Invoice and Purchase Order content type so you'll need templates for them. I simply went to http://office.microsoft.com and searched for templates that I could use. Then I saved the templates for later.

All document and records management revolves around the definition of content types. Therefore, you will create several for this exercise. Content types begin with the definition of site columns that can be used for metadata. In this section, you will create some site columns that can be used later in a content type definition.

Follow these steps to create the site columns:

Content types bring together site columns, templates, and workflows to define a document. In this section, you will use the site columns defined earlier to help create several content types. You will also associate the templates you downloaded at the beginning of the exercise with these content types.

Follow these steps to create the content types:

Once the content types are created, they may be associated with a document library. In this exercise, you'll create a document library for the financial documents and configure it to use the content types you defined. Once configured, you can use the library to create new financial documents.

Follow these steps to create the new document library:

The records repository is where important documents will be archived. The repository is created using the Records Center template. Once created, you can associate the repository with a site collection so that documents may be sent to the repository directly from a document library.

Follow these steps to create the records repository:

There are several configuration tasks that must be performed when a new records repository is created. Specifically, you must configure the repository to recognize content types and route them to the correct archive within the site. Additionally, you should set up retention policies so documents are automatically processed after they expire.

Follow these steps to configure the records repository:

Once the repository is configured, you may begin sending documents to it. Documents can be sent to the repository directly from an enabled document library. In this section, you'll make a new document and send it to the repository.

Follow these steps to archive a document:

Once documents are in the repository, they may be put on hold. Holds help ensure that a document is not altered or destroyed during an important time period such as audit or discovery. In this section, you will place an archived document on hold for a tax audit.

Follow these steps to set up a hold: