Using Document Sets to manage document based processes

The right tool for the right job

In SharePoint, I use a couple tools to manage the processes within my organization.  In the case of process automation, my default is to use Nintex, automating the process where it makes sense and improving the user experience where ever possible.  When I have a process that is document based, I will employ document sets, managed metadata and content types to automate the document provisioning for the process and then employ Nintex for additional functionality.

Today, I want to write mainly about Document Sets and how we can use them to make Document management easier within your SharePoint ecosystem.  One of the greatest difficulties we have in document and records management is the classification and application of Metadata; it is the holy grail, so to speak, of document management and is an area where many third party tools exist to perform auto classification.  In reality with Document Sets, Managed Metadata and Content Types and the support of Nintex workflow and forms, we can do almost anything you need for document classification.

Content Types

I first want to talk about Content Types.  Why? Because a Document Set is a Content Type for one and also because part of the reason we use Document Sets is to manage Content Types within a container.  So, let's get to it...
What is a Content Type?  A Content Type is a piece of reusable content that has a predefined selection of attributes (Metadata) assigned to it.  Think of it like a document template, because in reality, that is what most people use content types for.  Something many users do not realize however, is that with content types, you can build a Taxonomy (Hierarchical Structure) of Content and Metadata and that the taxonomy is explicitly required.  Understand that when we deal with content in SharePoint, there is an understanding that an Information Architecture should be designed and created and you need to do it using Content Types and Metadata. So lets quickly go through Content Type creation so it makes a bit more sense, the following steps were created using Office 365, but they are the same for On Premise or SharePoint Online.

Creating a Content Type

1. Go to Site Settings
2. Choose Site content types
   
   
3. In the Site content types screen, you will see all the content types applicable to the site, arranged into groups.  At the very top you will see the Create button, Click it.
   
   
4. Create the Content Type
   
   

Notice when we created the Content Type, it asked us for the Parent Content Type?  That is the implicit Taxonomy I referring to.  We can choose any content type as a parent and like real parents, their attributes are passed on to their children and we can then choose what is important, making the information architecture and the result much easier to manage; that even includes Document Templates.

Now this blog is about Document sets, so that is all I am going to talk about Content types for now, but stay tuned in future blogs, I will provide more insight into Content Types and how to use them.

Document Sets

Now you may be wondering what a Document Set is? well simply put, it is a folder within SharePoint that is used to apply shared metadata to all the objects within that folder.  So for example, lets say you have a project, the project has a project name, a project manager, a project number, a sponsor, a status and perhaps a region or other metadata that tells you about the project.  Some of this information is information you would want to associate to your documents, like to project Name and Project Number. Other information, like the Project Manager and Sponsor are not that important at the document level and don't need to be associated.  A Document Set has the ability to decide what is assigned and what is not when you configure the document set.

Another feature of the Document Set is the ability to assign specific content types that can be created within it, much like you would do in a document library or list.  You can pick and choose what can and can not be created within the document set.  Each content type within the document set has two portions of metadata, the assigned metadata from the document set and the content type metadata that was assigned when you created the content type.  Now you may ask, should I add the document set metadata I want to share to each content type I am going to use?  The answer is No, they are independent and your Document set management will be easier if you don't do that extra work.

Finally Document Sets (and this is the reason for the name) allow you to automatically provision a group of documents as a set.  In other words, every time you say > [Document Set Name] it will create a set of however many documents you decide, all ready for collaboration and all with the document set metadata already assigned.  Okay, so enough about all the things we can do with a document set, we created one when looking at content types, lets see what it can do...

Using a Document Set

 I am going to pick up where we left off from the last example as we clicked OK, if you closed out of it, not to worry, you can get back into the document set by going to site settings, choosing Site content types and then clicking on the content type you originally created.

1. Create all the metadata for the Document Set
   
   
   I will add three pieces of Metadata for the demo, Category, Status and Keywords, all from the Core Document Columns Group.
2.  My intent is that the Category and Keywords are both Metadata fields that are important to the documents that exist in the document set, while the status is only important to the document set itself.  So now I need to go into the Document Set settings (under Settings) and modify the Document Set.
3. Now to describe the Document Set Settings and what each section does, I have labelled an image and will go through each section, it's purpose and what you need to do.  The only one out of order is the Shared Columns, I want to go through that section first.

1. Shared Columns -  As I mentioned, I wanted to have Category and Keywords included with all my documents in the set, this is where I do that.  Checked columns are shared to the contents of the document set, unchecked are not.
2. Allowed Content Types - This is where you choose the content types that are available for creation under the button.
3. Default Content - This is where you add the documents (not templates) that will automatically be added to every new document set created.
4. Welcome Page Columns - Document Sets have a custom welcome page layout, at the top of the page is a folder icon, project name, description and any additional columns you want to add.
5. Welcome Page - The Welcome page can be customized by you, allowing for additional web parts and content.

You now have enough information about Document Sets, start playing with them and you will quickly see way to use them in your organization.  Some additional functionality can also be realized through the use of Nintex forms and workflows and also through the use of Managed Metadata. Stay tuned for future post on how we can use Metadata to create taxonomies, folksonomies and vocabularies, to further add value and structure to our solutions through proper information architecture.

I would be happy to provide answers to this or anything else to do with SharePoint, Information Governance and Information Architecture.  Comments and feedback, good or bad are appreciated, if you like what you see, follow my blog or follow me on Twitter, LinkedIn and Facebook:

Office Delve, the answer to your unified search prayers

What is Office Delve?

The easiest way to explain Office Delve is to say it is a unified search center for Office 365, but in reality it is much more than that.  Delve is all about collaboration and it learns from your usage (and your organizations usage) to create a relevance hierarchy that works best for you. The more does in Delve, by viewing, editing and sharing each other's documents, the more useful Delve will be for all of you.  What you see in your views in Delve is different from what your colleagues see in theirs, because it is tailored specifically to you.

What does Delve look like?

One of the biggest advantages to Delve over traditional search is the user experience.  Delve is about allowing you to find what you are looking for and it is about making it easy for you to see the information.  Delve provides a user interface that is both intuitive and understandable for users.

Delve provides recent activity when you first load the browser and provides the ability to see, search, group and explore documentation, e-mails and content within your Office 365 ecosystem.

How can I and my team get the most out of Delve?

Remember Delve is adaptive, so the best way to get Delve working for you is by you working with Delve.  Delve doesn't modify access to anything, so you need to ensure that your documents are somewhere within the Office 365 ecosystem, like SharePoint online or One Drive for Business.  You also need to make sure documents you want to share are accessible to the people you intend to use them and finally, just like any search, you still need to concentrate on good metadata behind the scenes.  Delve is adaptive, but it can't read your mind, think of it as an extension of your standard search functionality, a good Information Architecture (IA) will make Delve work better, delve only makes the user experience (UX) portion easier to manage.

For additional information on getting the most out of Delve and making your documents accessible check out Microsoft Support article on it: http://devfac.to/1C7aByT

Update:

In an update this week (March 21, 2015), Delve has added additional content into the search results, you can now see Yammer and web search results in the result sets.  The web search results are based of what you and your coworkers have been navigating to.  It is quite nice to have it all consolidated.

Follow me on Twitter: @DavidRMcMillan and @DevfactoPortals or on Facebook at https://www.facebook.com/moss.adventures.  Feedback and sharing are always appreciated and encouraged.

 

Governance Series - How to create a Single Source of Truth in SharePoint

I was in the SharePoint Community site last night and someone asked about maintaining a single source of truth.  One way to do it is to have a central repository for documentation; in SharePoint we would use a record center.  But it brings up a good point of how you would distribute those documents out to the team sites where they are actually used and manipulated.  The answer is simple, we create a new type of document library that can only contain links to documents.  We template it and save it as part of all our site templates instead of a regular document library.  In addition, we could add form and workflow functionality that would allow the users to upload files, but they would automatically be routed to the document repository; but that is for another time.

So how do we do this?  First we are going to need two sites with two document libraries one we will use as the source, the other as the link. In my example I will start with the "Linking" site first, but it really doesn't matter which site is first, only that the document exists in the repository prior to creating a link.

Linking Site

Ok, so we created a new site, lets say it is a team site template.  With a team site and most sites you get a document library named "Documents",  I am going to modify that library and make it a "Link Library".  Now don't confuse this with the "Links" app, which is just a list of hyperlinks.  At the end, I will add the steps to make it into a "Link Library" template so it can be reused.

Creating a Link Library from a Document Library

1. In the Document Library Click the Library tab then Click "Library Settings"
   
2. In the Settings page, Click "Advanced Settings"
   
3. In Advanced Settings, under "Content Types", "Allow management of content types?", Select "Yes", then scroll down and Click "OK"
   
4. Under "Content Types", Click on "Add from existing site content types"
   
5. Scroll through the list and Select the "Link to a Document" content type, Click "Add" and then Click "OK"
   
6. Under "Content Types" Click "New Button Order and Default Content Type"
   
7. Change "Link to a Document" from "2" to "1" and Click "OK"
8. Under "Content Types" Click "Document"
   
9. Under "Document" Click "Delete this content type"
   
10. When Prompted, Click "OK" to delete the content type
    

Your Library is now configured to create links to documents rather than documents themselves, but I have not addressed the issue of the upload button, but it is simple enough to hide the button or if you want a complete solution you can create a workflow to move uploaded files to a designated location in the repository; to me that is a much better option.  One caveat I want to point out is that the "Link to a Document" uses a URL, not a navigation pane, so you need to know where the document you are linking to is located, the advantage to this is it allows you to cross site collections and farms, but does not provide a great user experience.

Repository Site

The Repository site, like the Linking site contains a Document Library, unlike the Linking site, however, we are not going to manipulate it in the same way.  Instead, we are going to configure it to make it fit for our purpose, which is the storage of documents.  Now I am not going to tell you have to do that, because everyone is different, but some things that you might look at doing include setting up folder containers to classify documents that are uploaded. creating retention and disposition workflows and of course version control.

Test out the solution and let me know what you think.  Based on writing this, stay tuned, I think I like the idea of showing you the Nintex workflows that would go along with ths.

Follow me on twitter @DavidRMcMillan and @DevFactoPortals.  Feedback and suggestions are appreciated and encouraged.

ECM Governance - Post 2

It has been a few days (and a weekend) since my last post, which for me is a lightening fast response.  In this weeks post, I would like to continue along the ECM governance work we started and delve to the core of what defines governance.

Guiding Principles

If you want to consider implementing governance of any type, you are going to need to define a foundation on which we can build our rules for how things will be governed.  As an example, our society is governed by legislation and laws, but in reality, legislation and laws sit on a morale foundation for their existence.  This morale base can be referred to as the principles of our society or the "Spirit of the law".  As society defines the morale base and politicians and law makers interpret the morale base to make the laws and legislation, so to does the business define the guiding principles for ECM.  The actual interpretation of the guiding principles into the making of rules will come later on when we talk about the job of the steering committee, but I think you already have an idea of their role.

In the case of ECM governance, the foundation needs to be clearly defined through what we refer to as guiding principles.  The guiding principles are general rules that help guide us toward the vision we defined in our previous weeks exercise.  With each Principle we have two parts, the definition and the implication.  The definition defines what the principle intends to set rules around, while the implication provides context and understanding of how the principle will affect business users.  If we look at an example (one that should exist in all governance plans), we can see how the principles provide a foundation for use.

All Content is Owned  

Principle
All content must have a clearly identified “owner.”
Implication
Users need to know who to contact if information is out of date or inaccurate. The owner is responsible for the content in a site and for ensuring it is up to date.

This is a simple principle, but the implications can be quite extensive in an organization.  As mentioned in this basic example, ownership implies accountability for content and all content must be owned.  Notice the principle is short and concise, while the implication should be as detailed as needed to ensure that it identifies all the areas affected by the principle.  Our example is currently not detailed in the implication, but that is because the implications are typically specific to each organization.

If we were to look at these principles they can be categorized into several areas of impact.  These areas are as follows:

• General Principles
• Security Principles
• Document Management Principles
• Publishing Principles
• Collaboration Principles
• Business Process Principles
• Esthetic Principles

Each of the above areas cover off the usage and capabilities of the ECM, but additionally help you guide and focus on rules that are important to an ECM.

In our next session, I will examine each of these principle areas and outline the types of principles that you would expect to see in an organization.  For all our future examples, I will use SharePoint as the ECM of choice, though these principles could be applied to any ECM.

ECM Governance - Post 1

Introduction

If you were ever looking for a main cause for the failure of SharePoint implementations, look no further than ECM Governance.  Over the next couple weeks I am going to share some insights I have experienced with governance of enterprise content and what organizations need to do to ensure the successful implementation and use of solutions like SharePoint and OpenText Content Server.

I am a solution architect who has been working in SharePoint and OpenText (and integrating the two) for many years.  I have seen many implementations fail and they all stem from the same cause, a lack of governance.  It isn't just that organizations fail to plan, though that is part of it; it really has to do with how the organization prepares for the changes that a new system brings.

There is nothing worse than building a system and just letting everyone do whatever they want with the system.  Not only does it breed anarchy, it guarantees a poor user experience and a failed result.  The failure to plan is why so many organizations have no governance in place; we need to think ahead and decide how we are going to steer people towards proper use of the solution, that steering or guiding of people is known as governance which makes sense when you consider the source of the word.

The word governance derives from the Greek verb κυβερνάω [kubernáo]which means to steer and was used for the first time in a metaphorical sense by Plato. It then passed on to Latin and then on to many languages. (Origin from http://en.wikipedia.org/wiki/Governance)

In a modern sense, governance is the act of governing.  It involves determining where the organization needs to be and the rules that need to be followed in order to get there.

The Hydra

Every organization has its own ideas and reasons for using a system and this driving force is where we need to start when we talk about governance.  This driving force is actually a multi-headed beast, hence the section title.  The reason it is a Hydra has to do with the organization itself, companies are setup in silos, based on function and there is no way around it.  Engineers will use a system differently from accounting and so on.  In order to figure out the direction the organization needs to take, you are going to need to involve every group that is going to use the system.

Once you have the reasoning behind each groups use of the system, you can begin finding a commonality to their use.  This commonality will define the "Vision" of your governance plan.  It is the core of how the organization will use the solution, while the uniqueness of each group will provide variances that will be used later on in the governance definition process.

If we were building a governance plan, we now would have two sections ready to fill in, the business cases, which summarize your finding from speaking with each group in the organization and the vision, which defines the direction we need to take the solution.

Next Week

Next week I will explore the idea of guiding principles and how we can make those principles a reality in your organization.

Office 365

Well it has been a while since I posted last, having a baby takes up a lot of time... I thought I should post some information I think is very important if you are planning an Office 365 SharePoint Site. If you were considering Office 365 for small business and professionals (P1), you need to realize that SSL capabilities are not part of that package. This means that you essentially have no security in anything that you do with the P1 package. Microsoft doesn't seem to care, but I can't recommend the product to anyone I do business with with such a glaring security hole. Don't get me wrong, Microsoft might think this is acceptable for their "low end" offering, but the reality is they are saying small business and professionals don't need security. I hope they rethink their stance on this as I for one will go to a third party hosting site for this specific reason.