There are two distinct types of columns within SharePoint: list columns and site columns. From a functional perspective, they are identical, with one major difference: site columns are
reusable.
List columns
As an example, let’s consider a new list for a small company’s building management that will be used to assign a new desk to a worker. The company currently has two offices, one in Houston and one in San Antonio, and has only one building in each city. The plan is for the organization to eventually expand into other states.
The requirement is to capture a simple series of metadata elements, and for each office to maintain its own list:
■■ User name
■■ Office location
■■ Phone number
■■ City
■■ State
■■ Zip code
Within each office’s list, you could build simple list columns to capture each of these distinct pieces of metadata (also known as information types), shown in Table 1-1.
TABLE 1-1 List columns and information types
| List Column Name | Information Type |
| User name | Person or group |
| Office location | Choice, enforce unique values |
| Phone | Choice, enforce unique values |
| City | Choice |
| State | Choice |
| Zip code | Choice |
Adding values to each list requires you to visit that list to make changes. Not too bad for one or two lists, but as the company begins to add sites (and lists), maintenance of the multiple list columns could become error-prone.
Site columns
The next step on the path to reusable metadata is to build site columns instead of list columns and associate the site columns to list or library. The major benefit of moving from list columns to site columns is extensibility; what was once a piece of metadata that could be associated with only one list can now be associated to many.
Site columns are created the same way as list columns are, but with one major difference: they are hierarchical in nature. When a site column is instantiated on a particular site, that site and all its child sites inherit the site column and its properties.
Figure 1-3 shows the inheritance of two site columns. This example is purposely oversimplified, but you can see the inheritance of site columns based on where they were initially created.
FIGURE 1-3 Site column inheritance.
Site columns are hierarchical:
■■ A site column that is created at the top-level site in a site collection (SC1) is available to all sites in the site collection.
■■ A site column created at a subsite level (SC2) is available to that site and its child sites.
After a site column is created, a list can be assigned that column (along with its information type and all metadata). If the metadata associated with the information type changes (for instance, adding a new color choice), this change can be propagated throughout any list that had previously been assigned that site column.
Both list columns and site columns are defined by the type of content they possess (also referred to as the column’s information type). Most of these information types are scoped to the particular list or site column, meaning that metadata contained within the column is available only to sites residing in a particular site collection.
This site collection limitation presents a real problem: If you build multiple site collections (and you should be), you must now have a mechanism to make metadata available beyond the site collection boundary without having to build the same information type over and over again in each new site collection.
Fortunately, SharePoint provides a model for presenting information types in multiple site columns across multiple site collections; this model is called the managed metadata service. The MMS allows for the creation of a both local and global term sets, as you will soon see in the “Planning term sets” topic. A global term set can be used to store metadata (terms) for them to be reused and maintained in list and site columns across multiple site collections.
Content types
So far, you have been working with one column at a time: a name, a color, and a product type. Although it is perfectly viable to build each list or library and then assign distinct list or site columns, this does not allow you to manage groupings of similar items in a list or library. To address this need, SharePoint provides the notion of content types.
A content type defines the attributes of a list item, document, or folder. These attributes not only provide descriptive information about the item (metadata and properties) but also provide activities that can be associated with each item (workflows, information management policies, document templates, and other features).
Content types behave in a hierarchical fashion and are inherited from each parent site to its child within the same site collection, as shown in Figure 1-4.
FIGURE 1-4 Content type inheritance.
The hierarchy of content types behaves similarly to the hierarchy of site columns, meaning the following:
■■ A content type that is created at the top-level site in a site collection (CT1) is available to all sites in the site collection.
■■ A site column created at a subsite level (CT2) is available to that site and its child sites.
After a content type is created, a list or library can be assigned that content type. If the content type is changed (for instance, a new retention policy stage or new site column), these changes can be propagated throughout any list or library that had previously been assigned that content type.
It should be noted that all content types are related: documents, items, pages, lists, libraries, and more are all part of a large ecosystem of content types.
For example, when you provision a new document library, the default content type provisioned is Document. If you were to want to build a hierarchy of legal documents and have contracts as one of the available content types, its content type hierarchy might look something like Figure 1-5.
FIGURE 1-5 Content type hierarchy.
In this case, you might assign a core set of site columns to the legal document content type and then assign workflows, retention policies, and more site columns to the individual child content types (contract, will, and so on).
Any site collection created within a SharePoint environment is automatically populated with a series of content types that themselves are composed of out-of-the-box (OOB) site columns. The number and type of content types provisioned depend on the two different factors:
■■ Site template The template you choose when provisioning a new site will determine what content types are created.
■■ Features The features you select to add to an existing SharePoint site/site collection can also provide new content types.
The key here is to remember the scope. So far, we have a series of site columns that can inherit managed metadata, but the content type is still limited in application scope to the site collection.
If this structure is to be truly extensible, it’s time to learn how to apply content types from outside the site collection. For that, we will use the Managed Metadata Service (MMS) and a concept known as a content type hub.
Content type hub
Although content types can easily be defined within the boundaries of a site collection, you haven’t yet seen any provision for creating a content type that can be used in multiple site collections. This situation is quickly remedied by the use of a content type hub.
A content type hub is aptly named and is simply a normal site collection that has been specified to provide content types to other site collections.
Content types are syndicated by the MMS; the process is fairly straightforward:
- The MMS is configured to allow the content type hub to be the only source for centralized content type syndication.
- The MMS Connection is configured to consume content types from the hub’s content type gallery.
- Content types are placed in the content type hub for syndication.
- Content types are published by the Content Type Subscriber timer job on a regular basis (every hour by default) to all web applications that are connected to the MMS application.
Content types that are syndicated function exactly as those built within site collections. When a content type is published into a web application, it is simply placed into the content type gallery of each site collection for use.
External content types
External content types incorporate Business Connectivity Services (BCS) functionality to enable external data to be represented within SharePoint sites. These content types are metadata that represent the following:
■■ Connectivity information to data
■■ Data definitions for the data
■■ Behaviors applied to data
Information that is provided via the use of external content types is reusable, mimicking the behavior of normal content types within a site or site collection. Workers interacting with an external content type do not have to be aware of the underlying data type, connection type, or security present in the content type.
As the ultimate goal is to present external content exactly the same as internal content contained within SharePoint itself, external content types act the same as any other data presented in and consumed by both Microsoft Office and SharePoint. This includes the ability to search the content as well as taking it offline in Microsoft Outlook 2013.
External content types are highly useful after they are configured, allowing for the creation of lists and data columns within SharePoint that function identically to their native SharePoint
counterparts.
As the information represented by external content types is provided by BCS, it only stands to reason that there would be some specific web parts created for this purpose:
■■ Business Data List Displays a list of entity instances from a business application presented by BCS, such as a customer or order list
■■ Business Data Item Displays the details of an item from a business application presented by BCS, such as a particular customer or order
■■ Business Data Item Builder Creates a BCS item, providing it to other web parts
■■ Business Data Related List Displays a list of related items from a business application presented by BCS, such as all orders related to a particular customer
■■ Business Data Actions Displays a list of actions available to a portal user, such as sending e-mail or editing customer information
External content type and item pickers are also available for use within SharePoint along with profile pages, which can display details about a particular item. If more functionality is desired than what is presented by the OOB tools, development using external content types is available via the following:
■■ SharePoint object model
■■ Client object model
■■ Representational State Transfer (REST) URLs
NOTE SHAREPOINT DESIGNER (SPD) 2013 AND EXTERNAL CONTENT TYPES
SharePoint Designer (SPD) has always been a tool that is heavily integrated with the Share-
Point platform. In certain governance situations, it might make sense to limit the use of SPD, but note that there are some things that SPD does exceptionally well that are beyond the scope of other toolsets. Designing SharePoint/BCS external content types is one of those functional requirements that heavily promotes the use of SPD for knowledge worker design specialists.
