## How to Add the SharePoint Version Number to a Word Document

[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

How to Add the SharePoint Version Number to a Word Document

So You have your new Company Policy Manual, or your new Login Procedures document, or whatever. You’ve seen the power of Microsoft SharePoint when it comes to managing document version and you can’t wait to get started. But wait, you know that this document will not exist solely in SharePoint. It will be printed, faxed, emailed, scanned, converted to PDF and so forth. So you are going to want to have the document version (or “Rev” as some folks call it) printed on the document somewhere. The problem comes when trying to keep that bit of text synced up with the SharePoint version number.

### The Solution

For those of you who have worked with SharePoint metadata in Word, you have probably discovered that you can use the Quick Parts button to inject document properties, including some SharePoint columns. However, columns that are modified by the system such as calculated columns and Version are not available. So what to do?SharePoint 2010, you can use Information Management Policies. This is where you can set things like document retention policies, Audit polices and so forth. One feature that will help us is the Label feature. By enabling a Label, we can expose a string of text as a document property. This particular string of text can include the version number.

### Enable Labels in SharePoint

1. Login to SharePoint and navigate to the Document Library, you would like to enable.
2. Make sure versioning is turned on. If it’s not, turn it on now.
3. Click on “Library” link to open the Library ribbon and select Library Settings:
4. In the “Permissions and Management” section, select “Information management policy settings”:
5. Select “Document” from the Content Types Section:
6. Click the checkbox to enable Labels and type in the {Version} “Label format” field:
7. Click the “OK” button to save

### Using the Label in a Word Document

1. First we need to have the document in the library, so if you haven’t uploaded your document, go ahead and do that now.
3. Place your cursor anywhere on the page (including in a header or footer) that you want to display the version number.
4. Click on the “Insert” heading on the ribbon and select “Quick Parts > Document Property”. The “Label” property should now be available. Click it to insert it on the page:
5. You may seem some funny text there until you save the file (and check it in if your Doc. Lib. settings requires). Once you open it back up from SharePoint, it should display the normal version number.
[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Working mainly on the administration and architecture side of SharePoint, I don’t get to do a lot of development. That’s not necessarily a bad thing as it means that I can be more objective when it comes to deploying solutions to SharePoint farms and making changes to our infrastructure.

[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

However, I do like to keep an eye on the development side to help ensure that we follow best practice, and frequently come across articles detailing common mistakes made during development (such as this one on SharePoint Magazine). I figured that I have seen – and made – a fair few “common mistakes” over the years on the infrastructure side that might be helpful for those new (and perhaps not so new) to SharePoint administration.

Note that this list:

• Should not be considered authoritative (I’ve worked in this space for around 3 years).
• Is by no means complete (there are a lot more than 10 common mistakes in my view).
• Focuses purely on technical issues as opposed to taking a holistic view of things (which is of course at least as important!).
• Also applies to earlier versions of the product – especially SharePoint 2007.

In no particular order:

1. Not having “SharePoint” in your job title.

This is probably the most controversial “mistake” listed so thought I would get it out of the way first.

This obviously isn’t a hard and fast rule but the point is that Windows server administrators cannot expect to learn SharePoint overnight. Don’t get me wrong – I’m sure that there are dozens of Windows admins that also know SharePoint; however, if you have just taken on the role of “SharePoint administrator” in your company I highly recommend you ask your boss for some training. It’s a big, scary product and it’s not just “another Web site” to look after from within an IIS MMC snap in. Be warned that if you are taking this on in addition to dozens of other responsibilities you might be in for a tough time and you will probably need some extra hands on deck.

2. Creating too many Web applications.

Frequent readers of my blog (and anyone who has said the words “Web application” to me) are probably bored to death of this one. However, it’s an important point that I think is worth underlining.

I think Neil Hodgkinson summed this up nicely at the European Best Practices Conference last week by stating that he could not think of any typical reason why anyone would require more than 4 Web applications (intranet/portal, mysites, teamsites and partner access).

Inside Microsoft SharePoint 2010 also summarises this well by explaining that creating a Web application is “typically required only when initially installing and configuring SharePoint Foundation or SharePoint Server 2010.” It’s a great book that I recommend you check out.

Plan your logical architecture. Refuse to create Web apps for every public site / project / client / <insert apparent reason for a Web app here>.

3. Making changes in IIS manually.

This one is covered off nicely in this article by Michal Pisarek. My rule of thumb here is that “if the option is in Central Admin, never make the change from within IIS”. At its roots, SharePoint is a provisioning engine and it likes to store Web site configuration information in its configuration database if at all possible – examples include a list of Web applications and corresponding IIS sites, Alternate Access Mappings and Authentication Providers. It will save you a lot of headaches if IIS and SharePoint settings match.

There are some things that you must change from within IIS (such as applying SSL certificates and logging settings) – just make sure the options not in Central Admin first.

4. Failing to use the SharePoint solutions framework.

This one overlaps the administration and development space. My rule is simple: if a developer gives you a bunch of files that aren’t in a WSP, don’t deploy them to your servers.

Making changes manually to the SharePoint Root folder (some call it the “14 hive” due to legacy terminology) will lead to a world of hurt when it comes to adding additional servers to your farm and will lead to inconsistencies including missing files and permissions. In case you are wondering this includes features, templates, branding, sandboxed solutions and farm solutions (don’t drag files in into the GAC!). Also watch out for web.config changes: again, changes should be made via code as opposed to manually.

Try to avoid manual changes to the SharePoint farm at all costs.

5. Inadvertently installing a standalone server.

Most green SharePoint admins make this mistake without even realizing it simply due to the almost laughable manner in which the SharePoint installer UI repeatedly invites you down the standalone route. Before you know it you have yourself a single server deployment using SQL server express that has very limited scalability and will inevitably be more complex to upgrade.

Don’t accept the default options. Think long and hard before clicking “next” as it can have significant ramifications later on.

6. Using the default SQL DB growth settings.

In a lot of cases, SharePoint administrators will simply use the UI to create content databases. While this will work, SQL performance will be limited due to the somewhat out-dated default size and growth settings. Consider the fact that by default, your content database will grow by 1MB each time: that means that a 10MB file upload will result in your DB growing ten times!

7. Failing to document the farm configuration.

So you’ve just set up a comprehensive SQL DB backup plan. That means that the entire farm is safe should disaster strike, right? Wrong.

A common misconception is that you can happily restore the SharePoint configuration database. This is a myth which is covered in Sean McDonough’s post on the Configuration-only backup. I also covered this at around the same time here.

02/09/2012 update: I should probably clarify this statement by saying that restoring a standalone SQL backup of the SharePoint Config DB is not supported. This explains why you can’t backup the Config DB alone via Central Admin (SPCA).

A full farm backup taken using SPF VSS (e.g. via SPCA or PowerShell) *can* be restored in-place, which includes both the Farm Config and Central Administration database. Thanks to Sean McDonough for clarifying this. ​

In short, a full-fidelity farm backup (that can be used for in-place restoration) is still not possible without using third party tools. If you don’t have those tools available you must document your configurationpossible, as long as it is taken using SharePoint-aware Backup tools and not just using SQL or DPM. See Back up a farm configuration in SharePoint Server 2010.

8. Manually changing SharePoint databases to “fix” things.

Manual changes to SharePoint databases are not supported.

This is a simple rule that is often misunderstood or ignored. There are some exceptions to this rule (such as a support situation with Microsoft and the logging database) but this rule hasn’t changed. Always use the object model or Microsoft supported third party tools to make changes. See this post for more details.

9. Believing that PowerShell is only for developers.

PowerShell is new for SharePoint 2010 and while it might seem scary at first it is a very handy administration tool. You can use it to rapidly check logs. Remove those pesky database GUIDs. Setup a test environment. There are dozens of reasons to use PowerShell that I won’t go into here.

Spend some time with PowerShell and you will learn to love it. I’ve also blogged some of my thoughts on it if you are interested.

10. Disregarding SharePoint capacity planning recommendations.

Every time I go to a SharePoint conference I hear someone ask the same question: “I have a GB content database, what do I do?” I think this nicely illustrates a common problem: technical capacity limitations are often brushed under the carpet.

Read the authoritative technet article on SP2010 capacity planning. Note that meeting the supported limitations often involve some form of compromise (e.g. A Document Library can currently store up to 30 million documents. The default maximum document size is 50MB. The recommended maximum size for a site collection for is 100GB: something has to give!).

If you are fortunate enough to be deploying a green field SharePoint farm, make the business aware of these limitations and deal with them today (even if it involves a navigation / structural change). If you currently have site collections that exceed the 100GB limit, consider splitting up content to improve performance and save you further headaches.

Post by: Benjamin Athawes[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

## SharePoint 2010 Infopath Print Button

I received a request to put a print button within a List Item display view so that one could easily print the current item they’re viewing.  After searching for a way to put a print button within the Infopath form itself (and coming up empty), I figured out how to simply add it to the page that displays the form.

The end goal

Once you have your Infopath form put together and published to a List, go to the List page.

1. Click on the “List” tab under List Tools

2. Click on the drop down arrow on the “Modify Form Webparts” button (pictured)

[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

SharePoint 2010 Infopath Print Button

3. Select “(Item) Display Form”

4. This will take you to an edit page screen with your Infopath form set as a webpart

[/fusion_builder_column][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

SharePoint 2010 Infopath Print Button

5. Add a “Content Editor Webpart” to the page

6. Edit your new webpart’s source and paste in the following:

 1 
 2 onclick="window.print();return false;" />

Note: <form> tags are not required

This adds a print button to the page that uses the default print call within a browser.  Since we edited the “Display” form, the button will not appear if a user is editing the form or creating a new item.

Of course, the best part of this discovery is the added bonus of being able to add extra code to our Infopath forms, making them a much more versatile tool than they were before.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

## How to Add a Print Button to InfoPath Forms!

A common complaint I hear about custom InfoPath forms on lists and libraries is that you can’t print them. If you try and use the print button through the browser, you will likely end up printing the entire page. If you take a screenshot, you might not capture the entire form.

We can fix all these problems by adding a “Print” button to the forms

[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

Adding a Print Button to InfoPath Forms.

Read on to find out how!

First, open up Visual Studio 2010, and create an empty SharePoint project. In the project, add a new element, and add the following to it.

 1234567891011121314151617181920212223 <Elements xmlns="https://schemas.microsoft.com/sharepoint/">  <CustomAction Id="PrintButton" Location="CommandUI.Ribbon" Rights="ViewListItems">    <CommandUIExtension>      <CommandUIDefinitions>        <CommandUIDefinition          Location="Ribbon.Tabs.InfoPathListDisplayTab.Manage.Controls._children">          <Button Id="Ribbon.Tabs.InfoPathListDisplayTab.Manage.Controls.Print"            Command="Print"            LabelText="Print Item"            Sequence="16"            TemplateAlias="o1"            Image16by16="/_layouts/images/printer.png"            Image32by32="/_layouts/images/printer.png"/>                    <CommandUIHandlers>        <CommandUIHandler         Command="Print"         CommandAction="javascript:window.print();" />            

You will notice in the XML above that we reference an image file. This is the icon that will show in the ribbon. You can download the image I used from here. You must place this file in the SharePoint root (14 Hive) as show in the image below.

[/fusion_builder_column][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

How to Add a Print Button to InfoPath Forms!

Make sure you have the element added to a feature, and deploy the solution to your farm. After you deploy your solution and activate the feature, you should see a Print button on the display view of your forms. When the print button is clicked, it will bring up the Print dialog from the browser…and it will only print the form!

If you don’t have access to Visual Studio 2010 (or prefer not to dabble in custom coding), you can download the .wsp file from here. To deploy, open up PowerShell on your SharePoint server, and run

 123 Add-PSSnapIn Microsoft.SharePoint.PowerShellAdd-SPSolution C:\path\to\bguidinger.PrintButton.wspInstall-SPSolution -Identity bguidinger.PrintButton.wsp -GACDeployment`

Hopefully this helps you (and your end users) out![/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

## Content Types can Make your Life Easier

Every business utilizes many different types of data for many different reasons.  This data is crucial, critical, and any mismanagement of data can often directly affect your productivity, time spent on projects, and inevitably your bottom-line.  The problem is, employee information is different than product data. Similarly, Client contracts are different than consumer contracts.  Every time somebody accesses one of these documents, it opens the door for errors.  When you have more than one person accessing the same content, the margin of error increases exponentially.

Good news!  By utilizing SharePoint Services 3.0, you can avoid mismanagement, and you can organize your data & Workflow in whichever way benefits your business the most.  Not only is it easy to use, but it also has a plethora of features that can be customized to fit any of your business needs.  Two of the core concepts in SharePoint that are designed to organize your data are content types & columns.  *It is important to understand the concept of governance, because governance is the key ingredient that enforces the organization of your Workflows & Content Types.  For a detailed analysis of this relationship, see the article that proceeds this one: “Govern your Governance.”

1. Description of Content Types & Look-up Columns
2. How to create Content Types
3. Create Lookup Columns

## Understanding Content Types

Content types can be any piece of data that you want to store, display, list, search, query, or set access rights to. Content types can consist of anything: a word document, a contract, an ISO document or memo, a web article, an update, video, audio, a forum topic, a page, a picture and so on.  Any piece of data that has content that someone can view and comprehend can be a content type.

The way that Content types are usually deployed is by putting them in a list or a library.  Once you have customized any given content type, you can make it available to the designated library or list.  All of the functionality built into each content type will be available to each library or list that the content type is associated with.  Changes to the parent Content Type can be passed down to any list that uses that Content Type.  Since the user will not have to manually re-create that piece of content every time they want to apply it to a project, typing errors become a thing of the past.

A Content Typecan be utilized by a list or library. You can customize the functionality of any given content type & make it available to that library or list.  Whenever the Content Type is associated with a library or list, all of the functionality built into the customization of that Content Type would be available to that library or list.  Any changes to the parent Content Type can be passed down to any list that is using that Content Type.  The consistency that this provides can be essential to preventing typing errors, since the user will not have to manually re-create that piece of content every time they want to apply it to a new project.  In other words, using a single Content Type in multiple lists allows for consistency in the data structure.  This consistency adds to the ability to find those list items through a search across the metadata. For example: “Find me all list items that have a Priority of ‘High’ that were requested by ‘Mark Miller or Bob Mixon’”.

Imagine you have two types of documents: software specifications and legal contacts. For whatever reason, you want to store these documents in the same document library.  Most likely, the metadata you would want to gather and store in each of these document types would be very different, and so would their workflows.  *For more information on Workflows, check out “Workflows that Actually Work.”

Consider the following two types of documents: Employee Contract and Employee Training Manual. It is reasonable to assume that you might want to store documents of those two types in the same document library. However, the metadata you would want to gather and store about each of these document types would be very different. In addition, you would most likely want to assign very different workflows to the two types of documents.  Yet items of both content types could be stored in the same document library.

Content types
enable you to store multiple, different types of content in the same document library or list. In the preceding example, you could define two content types named EmpContract and Emptraining. Each Content Type could include different columns for gathering and storing item metadata.
In order to reduce typos and increase efficiency it is sometimes necessary to restrict the amount of typing users are allowed to do in any given application. This is a handy way of accomplishing both – less typing = less typos!

### Look-up Columns

Look-up columns provide a reusable model for content definition.  Each list that you use a column in will retain the same definition.  Much like Content types, you define a Look-up Column at the site level, independent of any actual list or content type. Because they consistently retain the same definition, they also alleviate the tedious work of reproducing the column in each list that you create.  Look-up Columns decrease rework and help you ensure consistency of metadata across sites and lists.  If you create a column named Contracts, users would be able to add that column to any list, and it will consistently retain any attributes that have been assigned to it, wherever it appears.  Users will always be able to search for it by referencing any of its attributes.

A Look-up Column is a reusable column definition, or template, that you can assign to multiple lists across multiple SharePoint sites. For example, suppose you define a site column named Customer. Users can add that column to their lists and reference it in their Content types. This ensures that the column has the same attributes, at least to start with, wherever it appears.
Additionally, look-up columns provide you with the simplicity of a single maintenance point. For example, you can create a status site column, which might contain multiple choices of an enterprise’s specific statuses, and implement the column in multiple scenarios.

Look-upcolumns
are similar to content types in respect to the fact that they can be added to sites and lists, and that they can be customized so they are centrally managed.   Unlike Content types, the information in look-up columns is focused to a single definition of data as opposed to encapsulating multiple definitions of data.  In other words, look-up columns give your data specific descriptive traits that they can be searched by, such as date, amount of units, status of access, and so on.
To that end we can create Look-up Columns to give the user a list of options to choose from.  For example: If our document library is going to store 3 types of documents we can create a look up list that contains 3 choices: Contracts, Proposals, and Quotes.  Using the look up column restricts the user to choosing 1 of the 3 available choices, and it does so while alleviating the user of the need to type.

Look-upcolumns
can be very useful because they can easily be managed without special permissions, and they can store an unlimited amount of options.
Lets say you have a department in your database called project development.  A look up column named department is created as a single line of text for users to enter their department name and a Content Type is created named Projects, which includes the site columns of Department, Project Name and Project Due Date.  This way, if the user knows any of these three pieces of information, they can look up the department accordingly.

To create proper Look up Columns we first need to create a location to store the “list of choices”.  To do this we use a “Custom List”.  The custom list would then contain column such as Document Type and Document Type Description.  Once this list is created we can then use the values in the list as the source for our Look up Column.

Here is a quick step by step guide to creating a “Document Type“ Look up column in a document library.

Step 1 – Create a custom list to hold the choices for the document type look-up column.

1. Navigate to the site that contains the document library you want to add the look-up columns to.

2. Click Site Actions > More Options

3. On the left hand side in the “Filter By:” section click List

4. In the details pain click “Custom List” *see figure 1

5. Enter a “Document Types” as the name of the Custom List

6. Click create to create a the list

7. In the Ribbon click List

8. In the List Ribbon click List Settings (far right side)

9. Scroll down to the Columns section

10. Click on the title column

11. Rename the title column to Document Type (Type over the text “Title”)

12. Click OK

13. Click Create Columns

14. Type Document Type Description as the column name

15. Click OK

Step 2 – Create a new site column Look-up column to show the values from the document type list

1. Click site actions > Site Settings

2. In the Gallery Section click Site Columns

3. Click Create

4. Enter Document Type as the column name

5. Select Look-up as the type of information in this column

6. In the group section either choose and existing group or create a new group to categorize your new column (this will make it easier to find later)

7. Require that this column contains information

8. Under get information from chose the Document Type list that we created earlier

9. Click OK

Step 3 – Add the new Document Type site column to a Document Library.

1.  Navigate to the document library that you want to add your look-up column to.
2. In the ribbon click Library
3. In the Library Ribbon Select Library Settings (far right side)
4. In the columns section click add from existing site columns
5. In the “Select Site Columns from:” drop down select the group that you created earlier (The one that will make it easier to find later)
6. Select the Document Type columns we created earlier.
7. Click OK

Step 4 – View Document Library

1.  In the breadcrumb trail click the Name of the document library.
2. In the Ribbon click Document
3. Click New (far left side)
4. Notice in the Document Information panel there is now a field called document type.

This is a very simple example; however it can still be seen as a basic template to implement complex relational databases with Sharepoint lists.  Creation of these lists and utilization of the concept is virtually guaranteed to decrease errors and work expenditure.

*Remember Content Types and Look-up Columns can be a bit tricky. Because of the relationships that may or may not be set up at the parent level, deleting a Column could easily mean deleting the content stored in that Column. If you want to delete a Column from a list, it is recommended that you write code that will explicitly allow this, since it means you’ll also lose any content that was stored in that column in the list.

Conclusion

Site columns and Content Types are the foundation of Information Architecture planning in Windows SharePoint. You should always use Content Types and Look-up columns to separate the definition of your content from the actual content.  Whenever possible, you should reuse these definitions across the whole application, as well as other applications if you can customize them to do so.  When you use these definitions, it eliminates the need to re-type your code every time you want to apply it, and it guarantees that there will be no typing errors at run-time.

Utilize these tools, and you can decrease rework and ensure consistency of metadata across sites and lists. Using Look-up columns and Content types can be tricky.  Too much duplication of effort is typically done because of lack of planning before starting to build the infrastructure of a Site Collection.  As long as you make the necessary effort in the beginning, you will find that the extra investment of time will help you immensely with management & maintenance of your SharePoint site & implementation.

Data that describes Data

SharePoint makes it possible to build a site that all of your users can manage and customize for almost any purpose. Not only does SharePoint make it possible, it also makes it extremely easy for users to create, change, and share documents.  How you choose to organize the structure for each given site depends on many different factors, such as the size of the site, the amount of users it will have, and what the needs are for the people who use it.  Basically, you can customize it to fit whatever business needs you may have.  Sounds great right?  It is great, but at the same time, the fact that different people from different departments at different stages of the documents life-cycle can access documents, opens the door for human error.

HR department employees think differently than I.T. employees, I.T. employees think differently then accounting dept. employees, and the examples go on & on.  An auditor may associate a document with who worked on it last, but a sales rep will likely associate the same document with the customer information it contains.  Subsequently, they interact with the documents according to these associations.  They may end up changing important information, saving it under a different name, or even deleting the document before it has completed its life-cycle through the other departments.

This article explores the concept of metadata: the data that describes your data.  Being that this is essentially the lifeblood of any successful business, we will also provide some guidance on how to organize your metadata so that it works seamlessly through the various departments that deal with it.

• Plan and create Content Types
• Plan and create workflows
• Search for documents using Columns & Content Types

So what is metadata?  Well, believe it or not, when it comes to designing sites in SharePoint, it’s probably your best friend.  It has been said that metadata can be best understood as “data about data”.  An easier way to think about metadata is to think of metadata as the attributes of an object.  Let’s take a music CD as an example.  Attributes of the CD could include the title, artist, release date, genre, and bar-code number.  All of these attributes would be the “metadata” of the CD.

In SharePoint, metadata can be described as the data about the documents, or any properties that describe the attributes of the document.  In such a case, you will actually see the metadata in a SharePoint document library.  SharePoint actually captures certain per-determined metadata by default, such as document title, document type, last modified date etc.  .  These are displayed in SharePoint as columns.  Therefore, metadata is also equivalent to and may often be referred to as columns in the SharePoint environment.  If there is metadata that you wish to search by that is not included in the default, you also have the option to make customized columns.

Metadata provides keywords that describe the content of a document, whether it’s for tagging blog posts, photos, or folders.  This allows for ease and efficiency of search.  This way, when a user goes to search for a report called: employee discount under the keyword employee, everything tagged with that data will show up in the search, including employee forms, employee policies, and who to contact in regard to employees.  *It should be noted that, without proper Governance of your site, your metadata will not be utilized properly. For more information on Governance, read the article that precedes this one: “Govern your Governance.”

By managing metadata (or columns), an organization can make it easier for its members to find the content they are looking for when they need it. The fact that it does so easily, and without overburdening them during the creation process is one of the key factors that make SharePoint work seamlessly between separate departments that use the same documents.  The management of your data will also include the mastering of content types, but they will not be discussed in this article.  To hear more about Content Types, read the follow up article “Make your life Easier with Content Types.”

#1 – Be Descriptive.  Every time you create a new column, fill in the Description field describing the information you’re asking for as definitively as possible. The more contexts you give your users for the metadata, the more likely it is they will enter information correctly.   In other words, when you are at the creation level, make sure metadata provides an alternative description for your data.  For example, when uploading a document, you should use descriptions such as Author, Date, Topic, Department, and Expiration Date.  All of these descriptions of your metadata will make it easier to group for viewing, or to find in searches.

#2 – Always spell check your metadata. I know that this sounds fairly obvious, but users are great at creating data with typos.  When this happens in Document Information Panels, (or really anywhere else for that matter) it usually leads to DISASTER.  The biggest and most prevalent issue is that when metadata is misspelled & then applied to documents, those documents are in effect “hidden” from search engines. That definitely spells trouble, pun intended.

#3 – Keep lists short. When referring to lists, we are talking about the choices that are made available to users as a Menu, Drop-Down, Check-boxes, or Radio Buttons. For the sake of your users, keep this list to a 4-6, and if necessary use 8-10 maximum.

#4 – Differentiate Columns with similar attributes: Define Columns that contain overlapping attributes decisively.  Columns that have the similar defining attributes can cause confusion for your users. For example, what’s the difference between Author, Contributor, Publisher and Source? Depending on the company, they might mean similar or completely different things. Decide what describes your metadata the most conclusively, and then refer to #1.

#5 – Create Subsets: If necessary, create a subset of a Column that extends the main set above. For example, Category, Keywords and Subject may contain more descriptive metadata than the main set, but they are harder to define. Often times, these types of Columns overlap in many ways. Choose one (e.g. Category) and use that for more descriptive metadata.  *Remember to keep the subset lists as short as possible.

#6 – Build Views.  Metadata can be used to build views that are specific to designated teams or departments.  If you do not choose the default (View: All Documents), you can customize views by associating them with columns that you have already created.  If a user only views documents that deal with accounting, then why burden them with documents from sales, HR, IT, legal, and inventory?  With their own specified View, they can deal with the documents that they need to deal with without the clutter of irrelevant data constantly popping up.

Creating a Look-up List & a Custom Column

Often times, you will want columns that you create to represent metadata that is uniquely meaningful to your organization.  When this is the case, you will do well to record this information as the documents are created.  Creating Custom Columns can capture this unique Metadata, and organize it in a way that benefits users tremendously when it comes to searching for specific documents.  A good example of this is when a user wants to know what employee last opened a document, and what department it is associated with.

In the example below, we will create a look-up list, and a custom column.

Create a Look-up List

1.  Select “Lists” from the side menu

2.  Click “create” in the top menu bar

3.  Filter by: Lists

Now you see the default choices for the different types of lists that SharePoint provides.

4.  Choose “Custom List”

4. In the details pain click “Custom List” *see figure 1

5. Enter a “Document Types” as the name of the Custom List

6. Click create to create a the list

7. In the Ribbon click List

8. In the List Ribbon click List Settings (far right side)

9. Scroll down to the Columns section

10. Click on the title column

11. Rename the title column to Document Type (Type over the text “Title”)

12. Click OK

13. Click Create Columns

14. Type Document Type Description as the column name

15. Click OK

Step 2 – Create a new site column Look-up column to show the values from the document type list

1. Click site actions > Site Settings

2. In the Gallery Section click Site Columns

3. Click Create

4. Enter Document Type as the column name

5. Select Look-up as the type of information in this column

6. In the group section either choose and existing group or create a new group to categorize your new column (this will make it easier to find later)

7. Require that this column contains information

8. Under get information from chose the Document Type list that we created earlier

9. Click OK

Step 3 – Add the new Document Type site column to a Document Library.

1.  Navigate to the document library that you want to add your look-up column to.
2. In the ribbon click Library
3. In the Library Ribbon Select Library Settings (far right side)
4. In the columns section click add from existing site columns
5. In the “Select Site Columns from:” drop down select the group that you created earlier (The one that will make it easier to find later)
6. Select the Document Type columns we created earlier.
7. Click OK

Step 4 – View Document Library

1.  In the breadcrumb trail click the Name of the document library.
2. In the Ribbon click Document
3. Click New (far left side)
4. Notice in the Document Information panel there is now a field called document type.

This is a very simple example; however it can still be seen as a basic template to implement complex relational databases with Sharepoint lists.  Creation of these lists and utilization of the concept is virtually guaranteed to decrease errors and work expenditure.

*Remember Content Types and Look-up Columns can be a bit tricky. Because of the relationships that may or may not be set up at the parent level, deleting a Column could easily mean deleting the content stored in that Column. If you want to delete a Column from a list, it is recommended that you write code that will explicitly allow this, since it means you’ll also lose any content that was stored in that column in the list.

Conclusion

Site columns and Content Types are the foundation of Information Architecture planning in Windows SharePoint. You should always use Content Types and Lookup columns to separate the definition of your content from the actual content.  Whenever possible, you should reuse these definitions across the whole application, as well as other applications if you can customize them to do so.  When you use these definitions, it eliminates the need to re-type your code every time you want to apply it, and it guarantees that there will be no typing errors at run-time.

Utilize these tools, and you can decrease rework and ensure consistency of metadata across sites and lists. Using Look-up columns and Content types can be tricky.  Too much duplication of effort is typically done because of lack of planning before starting to build the infrastructure of a Site Collection.  As long as you make the necessary effort in the beginning, you will find that the extra investment of time will help you immensely with management & maintenance of your SharePoint site & implementation.