Things to Ask our self Before Setting Up a Site:

ü  Site Quotas- what is the custom quota size for a site collection ? (http://technet.microsoft.com/en-us/library/cc891489.aspx )

ü  Primary and Secondary admin details -

ü  Site collection name should be unique(I.e. Following  naming Convention - http://technet.microsoft.com/en-us/library/ff919564.aspx )

ü  Clear Process to create  new managed path - If required in future.

ü  Are we supporting Mysites ? If so we need to consider the Storage occupied by each Mysite (i.e. 100 MB default ).

ü  What is retention period for a site collection or Sub Site or Document libraries.

ü  Backup/Restore strategy

Things to Ask our self Before Setting Up a Site:

§  What is the purpose of the site?

§  What are your business goals?

§  Is there already an existing site that fulfills these goals?

§  Do I need an entire site? Or would a new page or item in an existing site be better?

§  Who needs access to the site? Team members, everyone in the department, external partners/vendors?

§  What is the expected lifespan of site? 6 month project, until the next reorg, indefinite?

§  Does the site need to be searchable?

§  Should information within the site be able to be tagged and shared with others?

§  What kind of navigation is needed within the site? Complex subsite and library structure? Or fairly shallow, simple Information Architecture?

§  Will the site be for publishing and broad communications or for small group collaboration?

§  What kind of content will be stored within the site? Documents, project tracking, rich media, lists and spreadsheets?

Application Usage Policies in Sharepoint Governance

Application Usage Policies will cover the following major areas as below :

“Site Provisioning, Design, User Access, Site Management, Storage Quotas, Document Management, Content Management, Conduct “

Site Provisioning

New sites will be created on sites.auburn.edu or sites.aces.edu or my.auburn.edu, as appropriate.

Site Collections on sites.auburn.edu will be placed under one of the following managed paths: admin, academic, research, group, outreach or stuorgs.

Requests for Site Collections that cannot be categorized will be referred to SPOC for approval or rejection.

Site Collection requests must identify a certified, permanent Site Collection Administrator.

Site Collections may be requested by an employee or graduate student with an active AU username.

Site Collection Administrators will be responsible for provisioning and managing top level sites, but they may grant provisioning permissions (create, administer, delete) over their own sites to other users.

Design

All sites will also follow a consistent baseline design template to ensure consistency and usability across collaboration sites. Sites and Site Collections are based on templates that are centrally designed in accordance with OCM guidelines and Auburn University policy. (see Extranet section 6.3) In the case of ACES, templates will also be governed ACES/Ag IT and ACES Communications and Marketing Departments guidelines.

Employees, graduate students and retirees will be able to create their own My Site and manage sub-site creation in their My Site up to the 250MB storage quota.

Intranet Aggregate Sites should only be used in instances where:

 Content that applies to multiple parts of the organization is being aggregated and made available.

 There is a commitment of resources for a site.

 The site can be recognized as a top level topic within the organization and is enduring.

User Access

All potential SharePoint Site or Site Collection Administrators must review the training materials and complete a skills assessment prior to becoming a Site or Site Collection Administrator.

Off-campus collaborators may be able to access Auburn University’s SharePoint environment through an OpenID account.

OpenID users must accept and abide by Auburn University acceptable use policy to use AU SharePoint Resources.

Site Management

Site auto expiration: To ensure stale sites are removed and data storage is reclaimed, sites untouched for 365 days will be slated for automatic deletion. Site owners will be notified via email if their site is slated for deletion and provided with a mechanism to remove it from the automatic deletion list.

Development

For any development work, stakeholders should first contact their distributed IT department’s developer if one exists, then contact central OIT if necessary.

Custom development needs to be first scoped by the developer and then approved by the Site Collection Administrator. This includes any development under Windows Workflow Foundation (WinFX) and SharePoint Designer Workflows.

SharePoint Designer, Visual Studio and any other web development tool provided by Microsoft for development in SharePoint may be used for the development of the SharePoint user interface. The use of these development tools will be limited to SCA’s, with individual exceptions being granted by Site Collection Administrators for Site Designers and Owners.

Auburn University/ACES Employees must develop websites in compliance with Internet design standards and laws concerning copyrights, proprietary names and trademarks.

Storage Quotas

Auburn University’s custom configuration of SharePoint imposes a 250MB limit on the size of a single document that can be uploaded into a document library.

 250 MB of storage is allotted for each user’s My Site.

 10GB of storage is allotted for all site collections.

 SCA’s receive alerts when storage is at 90% of quota.

 SharePoint administrators can override storage quota for Site Collections with the approval of SPOC.

Document Management

Documents shared across multiple divisions should be stored on an Intranet Aggregate Site or in a site collection under the “group” managed path on sites.auburn.edu.

Video files should not be house on SharePoint servers. Video files should be housed on Auburn University’s streaming media server instead.

Posting software to SharePoint must comply with the above quotas and prohibitions and with the rules of software distribution as stated in the Auburn University ERP Data Protection Policy

Some file types may be prohibited as determined necessary by SPOC. Users may petition SPOC for addition of allowable file types.

Content Management

Content will be maintained by the appropriate content owner, typically the author of the content.

Content posted to SharePoint as:

 INTERNAL is not to be transmitted outside Auburn University. Content that is not identified is considered to be INTERNAL unless it is posted to a public facing site, in which case it will be designated as PUBLIC USE.

 CONFIDENTIAL is not to be transmitted or shared with anyone who does not have authorization to see it.

 PUBLIC USE has been deemed to not contain proprietary or confidential information and

 PRIVILEGED is regarded as attorney-client communication and shall be dated and not transmitted or shared with anyone who does not have authorization to see it.

 COPYRIGHTED shall be assumed to be protected by copyright and shall be dated and marked. It shall show the copyright owner’s name and shall not be reproduced in electronic or hard-copy form without authorization. Copyrighted material will not be added to the site without the proper licensing or approval.

SCA and Site Owners should publish content in a way that ensures confidential content is only shared on sites with limited access.

Conduct

Auburn University Employees/ACES or guests and agents of Auburn University/ACES using the Auburn University SharePoint environments are representing

their organization. They are expected to follow all Auburn University/ACES IT Network Policies currently in place.

Introduction to customizing pages by using Web Parts

Introduction to customizing pages by using Web Parts

This article is intended for Web page owners and administrators. It provides an overview of Web Parts and Web Part Pages and explains how you can customize a page by adding, changing, or deleting Web Parts.

---

• Overview of Web Parts and Web Part Pages
• Types of Web Parts
• Ways to use Web Parts and Web Part Pages
• Web browser support for Web Part Pages

---

Overview of Web Parts and Web Part Pages

A Web Part is a modular unit of information that forms the basic building block of a Web Part Page. You can add Web Parts to Web Part zones in a Web Part Page and then customize the individual Web Parts to create a unique page for your site users.
The following example uses the Image Web Part to describe the basic features of a Web Part.

---

 The Web Part title bar contains the heading for the Web Part.

 The Web Part menu contains functions that enable you to minimize or close the Web Part, edit the Web Part, or get Help for a specific Web Part. When the page is in edit mode, you can also use this menu to delete the Web Part or connect it to other Web Parts, depending on the type of Web Part that you are using.

 The body of the Web Part contains the content that you specified for the type of Web Part that is being used. In this example, the Web Part is an Image Web Part, which displays an image.

---

A Web Part Page is a special type of Web page in which you can use Web Parts to consolidate data, such as lists and charts, and Web content, such as text and images, into a dynamic information portal that is built around a common task or special interest.
Your site home page is one example of a Web Part Page. When you create a new site or workspace site, you are creating a Web Part Page. You can also create a Web Part Page by selecting one of the available site templates, or you can use a Web design program that is compatible with Microsoft Windows SharePoint Services, such as Microsoft Office SharePoint Designer 2007, to create a Web Part Page from scratch.
You can use a Web Part Page to present a variety of structured and unstructured information in an organized, useful, and convenient way. Web Part Pages often contain several Web Parts that are connected so that you can dynamically display data and content to see the results that you want.
For example, you can create a Web Part Page called Customer Orders that you frequently use to display critical information. You get a call from a customer who has a question about an order, does not remember the order ID number, but does remember the date when the order was placed. You can use a Web Part Page to do the following.

---

 Look up an order by order ID number or, in this case, the order date.

 Display all orders by date.

 Select the correct order, based on the customer's name, and look up the order details as well as the customer details.

 Select a line item in the order (in this case, the lamp), and display a product picture to confirm the customer's question.

 Scan for late-breaking business news that is pertinent to the customer's order.

---

Web Part properties

Each Web Part shares a set of common properties (also called base class properties) that are organized into sections in the tool pane and that control the Web Part's appearance (such as the title, height, and width), layout (such as the Web Part order in the zone and the direction of the content), and advanced characteristics (such as the image icon and description).
Many Web Parts also have custom properties that are unique to the Web Part. These are usually displayed either above or below the common Web Part properties in the tool pane. For example, the Image Web Part has additional custom properties, including the image link, its horizontal and vertical alignment, and background color.
 Note   Depending on how the Web Part was created, a Web Part custom property may be displayed in a default Miscellaneous section below the common properties in the tool pane.

Web Part views

You can customize a Web Part in one of two views:

• Shared view    You can add a Web Part to a Web Part Page and then edit the Web Part Page in a shared view. Shared Web Parts are available to all users of a Web Part Page who have the appropriate permission.
• Personal view    You can add a shared Web Part to your own personal view and then edit your view of the Web Part. The changes that you make to a Web Part while you are in a personal view are available only to you. Other users who did not make changes in a personal view continue to see the shared view of the Web Part.

The view of the Web Part that you are working with can be important because:

• You may have permission to edit only some Web Parts on certain Web Part Pages but not on other Web Part Pages.
• You may be able to connect to certain Web Parts on a Web Part Page but not to other Web Parts on the same Web Part Page.

Web Parts and Web Part connections

An additional feature of Web Parts is the ability to easily connect them by passing data between them and synchronizing their behavior. By connecting Web Parts, you can manage data in dynamic and interesting ways. In many products and technologies, the task of connecting sets of data from different data sources is not easy and often requires programming skill. But with Web Parts, making data connections is as simple as using menu commands. By connecting Web Parts, you can, for example, present data from two Web Parts in alternate views, perform related calculations between two Web Parts, and filter a Web Part by using values from another Web Part — all on one Web Part Page.

Web Part zones and their properties

Web Part zones are containers of Web Parts that are used to group and organize Web Parts on a Web Part Page. Web Part zones also have a set of properties that serve a dual purpose. You can use one subset of properties to organize the layout and format of Web Parts on the Web Part Page. You can use another subset of properties to provide an additional level of protection from modification (or "lock down") of the Web Parts within the zone.
The Web Part zone properties each have default settings or behaviors. As you add Web Parts to the Web Part Page, some of these property values are automatically set. These property values are not designed to be edited in the browser, but you can edit them by using a Web design program that is compatible with Windows SharePoint Services, such as Office SharePoint Designer 2007.
For more information about Web Part zone properties, see the Windows SharePoint Services 3.0 SDK, which is available from the Windows SharePoint Services Developer Center on MSDN.
Top of Page

Types of Web Parts

Windows SharePoint Services provides several Web Parts that are ready to use with your site. You can use these built-in Web Parts, customize them to suit your needs, or create new Web Parts and upload them for use throughout your site.

Default Web Parts

The following Web Parts are included by default in any site and can be customized to suit the needs of your team. Many of these Web Parts can also be connected to each other to create a variety of unique solutions:

• Content Editor Web Part    You can use the Content Editor Web Part to add formatted text, tables, hyperlinks, and images to a Web Part Page.
• Form Web Part    You can use the Form Web Part to connect to and filter a column of data in another Web Part. Both Web Parts must run on the same server.
• Image Web Part    You can use the Image Web Part to add a picture or graphic to a Web Part Page. To more easily coordinate the image with other Web Parts on the page, you can control the vertical alignment, horizontal alignment, and background color of the image inside the Image Web Part by editing its custom properties in a shared view.
• List View Web Part    You can use the List View Web Part to display and edit list or library data on your site and to connect to other Web Parts, including other List View Web Parts. Lists are information that you share with team members and often display in tabular format. List views display this information in different ways for different purposes, such as filtering, sorting, or selecting specific columns.

 Note   There is no Web Part called List View. When you create a list on your site, a List View Web Part is automatically created and named after the list. For example, if you create a list called Boats, a Web Part called Boats will be available in the Site Name gallery. The Web Part automatically displays the data contained in the list that you created.

• Page Viewer Web Part    You can use the Page Viewer Web Part to display a Web page, file, or folder on a Web Part Page. You enter a hyperlink, file path, or folder name to link to the content.
• Site Users Web Part    You can use the Site Users Web Part to display a list of users and groups who have permission to use a site. The Site Users Web Part automatically appears on the home page of a Document Workspace site. You can also add the Site Users Web Part to any Web Part Page.

 Note   In sites that are running on Microsoft Windows SharePoint Services 2.0 and earlier, the Site Users Web Part was called the Members Web Part.

• XML Web Part    You can use the XML Web Part to display Extensible Markup Language (XML) and apply Extensible Stylesheet Language Transformations (XSLT) to the XML before the content is displayed. For example, you might have an XML file that contains a list of boats, prices, and links to images of the boats. You can use the XSLT to transform the data to display a list of boats and prices and make the boat name a hyperlink to display the image in a separate window.

Preconfigured List View Web Parts

The following Web Parts are built into the Windows SharePoint Services team site template and are automatically configured and ready to use on a Web Part Page when you create a new team site. Different combinations of these Web Parts are included when you create a team site or workspace site, depending on which site template you select.
 Note   These Web Parts are derived from the List View Web Part and use preconfigured Web Part templates to create their unique layout and design. To add data to these lists, on the Quick Launch, click View All Site Content, and then click Lists. On the All Site Content page, click the name of the list for which you want to add data.

• Announcements    Use the Announcements Web Part to post news, status, and other short bits of information that you want to share with team members.
• Calendar    Use the Calendar Web Part to display upcoming events or team schedules.
• Links    Use the Links Web Part to post hyperlinks to Web pages that interest your team.
• Shared Documents    Use the Shared Documents Web Part to share files from the default document library with site users.
• Tasks    Use the Tasks Web Part to assign a task to a member of your team, specify its due date and priority, and indicate its status and progress.
• Team Discussion    Use the Team Discussion Web Part to provide a forum for talking about topics that interest your team.

Custom Web Parts

By using a programming environment that is compatible with Windows SharePoint Services, such as Microsoft Visual Studio, developers can exploit the full feature set of Microsoft ASP.NET to create custom Web Parts. A Web Part Page is an ASP.NET file (.aspx), and Web Parts are derived from Web Form Controls. To further enhance Web Part Pages, developers can create their own Web Parts that provide new functionality. Developers can also add custom properties to the Web Parts, add custom builders in the tool pane for specialized user interfaces, and connect to other Web Parts by using Web Part connections. For more information about creating and deploying Web Parts, see the Windows SharePoint Services 3.0 SDK, which is available from the Windows SharePoint Services Developer Center on MSDN.
You can also use Web Parts that other people or companies have created. You must have appropriate permissions to add a third-party Web Part to your Web Part Page or site. Some Web Parts may need to be deployed directly to the server. If you are unable to add a third-party Web Part to your Web Part Page or site, contact your administrator for assistance.
Top of Page

Ways to use Web Parts and Web Part Pages

You can use Web Part Pages in the following ways:

• Consolidate data from different data sources.
• Report and summarize critical data.
• Analyze and aggregate data (for example, sums, totals, or counts).
• Summarize key information that you want to see at the beginning of each day.
• Prioritize and highlight project or customer data to help you make effective decisions.
• Display an up-to-date work schedule and meeting information to quickly plan your day.
• Get quick access to business news, local weather, and your favorite Web sites to focus your Web browsing.

Ways to create and customize a Web Part Page

There are several ways to create and customize a Web Part Page:

• The New Web Part Page form    The most common way to create a Web Part Page is through the New Web Part Page form. On the Site Actions menu , click Create, and then click Web Part Page to open the New Web Part Page form. After using this form to create a page, you can begin designing the page right away in the browser. When you want to browse through the page, just close the tool pane.
• A Web design program    By using a Web design program that is compatible with Windows SharePoint Services, such as Microsoft Office SharePoint Designer 2007, you can make advanced customizations to a Web Part Page, including the following:
• Customize the theme of a Web Part Page that uses the site theme by default.
• Edit a Web Part Page template or create a new one.
• Customize the page layout.
• Edit zone properties.
• Add HTML code or Web controls.
• Change the way Web Parts are ordered inside a zone.
• Add Web Parts outside a zone, or add a Web Part to a Web page that is not a Web Part Page.
• Create connections between Web Parts on different Web Part Pages.
• Publish a Web Part Page to a Web site that is running Windows SharePoint Services.
• Customize the Form Web Part and use the Data View Web Part.

Top of Page

Web browser support for Web Part Pages

Web browser support for Web Part Pages can be categorized into two levels:

• Level 1 support is the highest level of visual and functional support. Browsers that provide level 1 support include recent versions of Microsoft Internet Explorer for Microsoft Windows.
• At level 2 support, a few visual and functional features are not available to some browsers, and some other features are compromised and behave differently from the way they behave in level 1 browsers. However, the majority of features are still available to users. Browsers that provide level 2 support include Firefox 1.5 and later for Windows and Netscape Navigator 8.0 and later for Windows. Level 2 browsers are not supported for Windows SharePoint Services 3.0 Central Administration.

 Note   Level 2 browsers do not support the creation of connections between Web Parts.
The following table shows the level of support that some common browsers provide.

Minimum browser version	Operating system	Level 1	Level 2
Internet Explorer 6.x	Windows	Yes	Yes
Internet Explorer 6.x 64-bit version	Windows	Yes	Yes
Internet Explorer 7	Windows	Yes	Yes
Firefox 1.5	Windows	No	Yes
Netscape 8.0	Windows	No	Yes
Firefox 1.5	Unix	No	Yes
Netscape 7.2	Unix	No	Yes
Mozilla 1.7.12	Unix	No	Yes
Safari 2.0.2	Macintosh	No	Yes
Firefox 1.5	Macintosh	No	Yes
Other	Other	No	No

Content type and workflow planning

Content type and workflow planning (SharePoint Server 2010)

SharePoint Server 2010

15 out of 33 rated this helpful - Rate this topic

Published: May 12, 2010
A content type is a reusable collection of metadata (columns), workflow, behavior, and other settings for a category of items or documents in a Microsoft SharePoint Server 2010 list or document library. Content types enable you to manage the settings for a category of information in a centralized, reusable way. A workflow lets you attach a business process to items in SharePoint Server 2010. This article describes content types and workflows and provides guidance about how to plan to integrate them into your SharePoint Server 2010 document management solution.
In this article:

• Content type overview
  
  
• Plan document content types
  
  
• Plan information management policies
  
  
• Plan list content types
  
  
• Plan workflows
  
  
• Worksheet
  
  

Before you use the Content type and workflow planning (http://go.microsoft.com/fwlink/p/?LinkID=165878) worksheet included with this article to plan your content types and workflows, ensure that you have read Identify users and analyze document usage (SharePoint Server 2010) and completed the "Analyze document usage" and the "Document participants" worksheets associated with that article.

Content type overview

A content type defines the attributes of a list item, a document, or a folder. Each content type can specify the following:

• Properties to associate with items of its type.
  
• Metadata to associate with items of its type.
  
• Workflows that can be started from items of its type.
  
• Information management policies to associate with items of its type.
  
• Document templates (for document content types).
  
• Custom features.
  

You can associate a content type with a list or library. When you do this, you are specifying that the list or library can contain items of that content type and that the New command in that list or library will let users create new items of that type.

Note:
You can also associate properties, workflows, policies, and templates directly with a list or library. However, doing this can limit these associations to the list or library and is not reusable across your solution. In SharePoint Server 2010, site-level workflows can be associated with multiple lists or libraries.

Document libraries and lists can contain multiple content types. For example, a library can contain both the documents and the graphics related to a project. When a list or library contains multiple content types, the following apply:

• By default, the New command in that list or library lets users select from all available content types when they create a new item. Content type owners can configure the New command to display only certain content types.
  
• The columns associated with all available content types are displayed.
  

You can define custom content types in a site's content type gallery. A custom content type must be derived, directly or indirectly, from a core content type such as Document or Item. After it is defined in a site, a custom content type is available in that site and in all sites below that site. To make a content type most widely available throughout a site collection, define it in the content type gallery of the top-level site. You can also create a custom content type in a content type hub that is defined in a managed metadata service instance. When it is created in a content type hub, the content type will be available to other site collections that are part of Web applications associated with that managed metadata service instance.
For example, if your organization uses a particular contract template, in the content type gallery of the top-level site in a site collection, you can create a content type that defines the metadata for that contract, the contract's template, workflows required to review and complete the contract, policies that enforce auditing of actions related to the contract, a retention period for the contract, and labels to insert in printed versions of the contract. Then, any document library in your site collection to which you associate the Contract content type will include all these features and will enable authors to create new contracts based on the template.
In sites that are based on SharePoint Server 2010, each default list item or library item, — such as Contact, Task, or Document, — has a corresponding core content type in the site's content type gallery. When you plan content types, you can use these core content type definitions as starting points and base new content types on existing ones as needed. Or, you can use core content types.
Content types are organized into a hierarchy that lets one content type inherit its characteristics from another content type. This inheritance enables classes of documents to share characteristics across an organization, and it enables teams to customize these characteristics for particular sites or lists.
For example, all customer-deliverable documents in an enterprise might require a set of metadata, such as account number, project number, and project manager. By creating a top-level Customer Deliverable content type from which all other customer-deliverable document types inherit, you ensure that required information, such as account numbers and project numbers, will be associated with all variants of customer-deliverable documents in your organization. Note that if the content type owner adds another required column to the top-level Customer Deliverable content type, the content type owner can propagate the changes to all content types that inherit from it, which will add the new column to all customer deliverable documents.

Properties integration with the Office 2010 release

In the Microsoft Office system, when a user edits a document from a SharePoint Server 2010 document management server, a Document Information Panel is shown at the top of the document. The Document Information Panel displays an editable form of the document's properties on the server.
SharePoint Server 2010 makes it easy to customize the property form for a content type. When you configure a content type, you can start Microsoft InfoPath 2010, which generates a default property form that is based on the properties of the content type. The default form includes the same controls, layout, and schema that InfoPath 2010 would use if no custom form were defined. You can then customize and deploy the form as you would any other InfoPath 2010 form. For example, you can add your company logo, fonts, and color scheme to a form; connect it to a custom data source; add conditional logic; and design form features that are available to users based on their roles.
Along with editing properties in the Document Information Panel, authors who use Microsoft Word 2010 can insert properties that are defined on the server into their documents. For example, if the document properties include a project manager name, this name can be inserted into the title page, the footer, or anywhere else the name is used in the document. If a new project manager is assigned to a project, the Project Manager property can be updated on the document management server. This updated project manager name will be reflected in every instance of this property that was inserted into a document.

Using metadata with content types

Metadata is information about a document that is used to categorize and classify your content. Metadata is associated with a content type as a column. Metadata can provide contextual information about your document by associating it with an author, subject, audience, language, and so on Unlike properties, metadata are stored as columns and can be indexed and searched on by the SharePoint Search engine.
Metadata added at the site collection level can be associated with content types. By using metadata with content types, all later content types can inherit some or all of their metadata from the parent content type at the site collection level. Additional metadata can then be added at a lower level, such as an individual document.

Column templates

Each item of metadata that is associated with a content type is a column, which is a location in a list to store information. Lists or libraries are often displayed graphically as columns of information. However, depending on the view associated with the list, the columns can appear in other forms, such as days in a calendar display. In forms associated with a list or library, columns are displayed as fields.
You can define columns for use in multiple content types. To do this, create them in a Column Templates gallery. There is a Column Templates gallery in each site in a site collection. As with content types, columns defined in the Column Templates gallery of a site are available in that site and in all sites below it.

Folder content types

Folder content types define the metadata that is associated with a folder in a list or library. When you apply a folder content type to a list or library, the New command in that list or library will include the folder content type, which makes it possible for users create folders of that type.
You can define views in a list or library that are available only in folders of a particular content type. This is useful when you want a folder to contain a particular kind of document and you want views in that folder to only display columns that are relevant to the document type that is contained in that folder.
By using the SharePoint Server object model, you can customize the New command for a folder content type so that when a user creates a new folder of that type, the folder is prepopulated with multiple files and documents based on templates that are stored on the server. This is useful, for example, for implementing a compound document type that requires multiple files to contribute to a single deliverable document.
Document sets is a new feature in SharePoint Server 2010 that lets you use Microsoft Office 2010 to manage deliverables that span multiple documents. Document sets are special kinds of folders that are used to manage a single deliverable, or work product, which can include multiple documents in multiple locations. You create document sets by using extensible templates that are provided with SharePoint Server 2010. You can also customize Document Set templates to represent the work products that are relevant to your organization. Document sets also include version control, which lets you capture the state of the complete document set at various points in its life cycle. For more information about document sets, see Document Sets planning (SharePoint Server 2010).

Plan document content types

The first stage in planning document content types is to review each document type that is listed in your Analyze document usage (http://go.microsoft.com/fwlink/p/?LinkId=165873) worksheet to determine whether an existing content type will work for that kind of document. Each document content type should inherit its settings directly from the core Document content type or from a content type that is descended from the Document content type. This ensures that the basic columns for your document types, such as Title and Created By, are present and that you can associate a template with the content type. If a core content type (such as Document) is sufficient, enter the content type name in the Content Type column of the "Analyze document usage" worksheet.

Plan information management policies

An information management policy is a set of rules for a kind of content and is made up of policy features that provide the details of each rule, such as whether items of the content type can be printed or which actions on the item should be audited. You can apply a policy to any custom content type. However, you cannot apply a policy to a core content type. For more information about information management policy planning, see Information management policy planning (SharePoint Server 2010). After reviewing policies and determining which policy features and policy templates are available, use the Content type and workflow planning (http://go.microsoft.com/fwlink/p/?LinkId=165878) worksheet to record information about what policies to associate with document content types, list content types, and document sets content types.

Plan list content types

The elements of a list content type include the columns of metadata that are associated with the content type and workflows that can run on items of that content type. Use a list content type to define a kind of list item that is unique to your solution. For example, in a customer call center solution, in which support professionals investigate and resolve customers' technical issues, a list content type could be used to standardize the data for each support incident and to track the incident by using a workflow.

Plan workflows

Workflows implement business processes on documents, Web pages, forms, and list items inSharePoint Server 2010. They can be associated with libraries, lists, or content types.
In document management, use workflows to route documents from person to person so that they can each complete their document management tasks, such as reviewing documents, approving their publication, or managing their disposition. Also, use custom workflows to move documents from one site or library to another. For example, you can design a workflow to copy a document from one site to another when the document is scheduled to be archived.
SharePoint Server 2010 includes workflows that address the following document management needs:

• Collect Feedback   Sends a document for review.
  
• Approval   Sends a document for approval, often as a prerequisite to publishing it.
  
• Disposition   Manages document expiration and disposition.
  
• Collect Signatures   Routes a document for signatures.
  
• Translation Management   Manages the translation of a document into one or more languages.
  
• Three-state   Manages business processes that require organizations to track the status of an issue or item through three different states (phases).
  

Associate a workflow with a content type when you want to make that workflow available whenever that content type is being used. For example, a purchase order content type could require approval by a manager before the transaction can be completed. To ensure that the approval workflow is always available when a purchase order is initiated, create a Purchase Order content type and associate the approval workflow with it. Then add the Purchase Order content type to any document libraries in which purchase orders will be stored.
To plan workflows for your document management solution, analyze each document content type that you plan to implement and identify the business processes that have to be available to run on content of that type. Then identify the workflows you will have to make available for that content.
The following is a sample table that analyzes workflows for a contract content type.

 

Contract Process	Contract Workflow	New?
Review drafts.	Collect feedback	No
Get approval from the manager and the legal counsel.	Approval	No
Resolve open issues.	Issue tracking	No
Get signatures.	Collect signatures	No

For more information, see Plan workflows (SharePoint Server 2010).

Worksheet

Use the following worksheet to record the information discussed in this article:
Content type and workflow planning worksheet for SharePoint Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=165878)