Users can contribute documents to SharePoint by individually selecting them from a file system and storing them into a library. This is referred to as file upload and occurs when a person initiates the transfer of content from the local client machine or shared network drive to the SharePoint server(s). To do this, the user must first have read/write access to the library they want to contribute to.

As we outlined earlier, you need to do some planning and also education of people before content capture is initiated. This will ensure that you build a solid foundation prior to files being uploaded randomly by SharePoint users. We recommend that prior to upload you specify for your organization what constitutes a proper file. You should intentionally define a file in the following order:

Often, file naming conventions are more about what to exclude than include. For example, you should never put the initials of individuals, dates, times, or version numbers in a file name. This will seem counterintuitive to you and most people that are using only email and local and network file shares to store and share files. This is because a directory structure does not provide the same metadata and search functions that SharePoint provides. This is what makes Information Architecture so powerful. In general, the file name should pertain only to the topic matter, and perhaps include a business function that the content pertains to. It should not include metadata that is better suited for content types.

When the user knows that a file is appropriate to add to SharePoint, they will browse to the library and use one of the following methods of upload:

When uploading an individual document into SharePoint, a user will specify relevant metadata to be added by using an upload dialog, as shown in Figure 2-1. To upload the document, click the Add Document button at the bottom of a library in SharePoint 2010, or click the New Document button in the top-left section of a library in SharePoint 2013.

Figure 2-1. Upload dialog.

Browse the local file system, identify the file to be uploaded, and double-click the file. The next step is for the user to apply appropriate metadata. Fields marked with a red asterisk indicate mandatory fields. These fields will be defined as part of the Information Architecture. By default, the metadata fields for the Document content type are Name, Title, Created Date, Last Modified Date, Created By, and Last Modified By. Remember that Name and Title are the only user editable metadata fields. As we will discuss in Information Architecture, in many cases you will want to add more fields.

Both SharePoint 2010 and SharePoint 2013 support the ability to upload multiple files at once. This feature allows users to contribute batches of documents in SharePoint. The feature can be beneficial when users are guided to upload content that is already strictly organized. But often this feature is used as a quick way to bypass proper addition of content to SharePoint. In 2010 and 2013, this feature can be disabled with some deep modifications to the SharePoint ribbon or via CSS.

Similarly to multiple file uploads, you can upload files from the File Explorer view. The benefits of this are added user adoption and the comfort with file movement that users are accustomed to. The downside is that it also allows the bypassing of metadata and records. For newer deployments of SharePoint, we recommend that you tightly control the use of this method by training users to use only the SharePoint user interface.

In SharePoint 2013, there is the added ability to drag documents into SharePoint from the desktop to the browser. As shown in Figure 2-2, a user can select a file by right-clicking, holding the button, dragging the selected file over the document library in the SharePoint browser interface, and releasing the button. This requires that the user workstation have Microsoft Office installed and a supported browser. For users without these minimum requirements, the drag method for content capture will not function.

The benefit of this feature is greater convenience for the user. The downside is that the user is not given an opportunity to provide the proper metadata, which typically results in no metadata. If features like drag and drop are being used, you will want to adopt policies that promote the proper use of the feature and train the user community to follow the correct steps for uploading content and providing metadata.

Figure 2-2. Dragging a file for upload.

When organizations can standardize on the Microsoft stack, they get the added benefit of tight integration with SharePoint. Tight integration not only means greater convenience for your users, but it also means great support when there are questions about functionality and configuration options.

For this reason, we strongly recommend that the organization standardize on using Microsoft Office as one of the primary capture sources. You have the option of allowing users to upload existing Office documents to SharePoint. In addition, they can also save them directly from Office into a SharePoint list or library.

Starting in Office 2007 and subsequent versions, the integration with SharePoint is strong. In Office 2010 with SharePoint 2010, the integration is more than a “Save” location. You also have the ability to modify certain metadata fields, see previous versions, and you have check-in | check-out document management functionality.

When SharePoint is configured to support single sign-on, the integration is seamless. If your organization does not use a single sign-on method or if users are remote, they might be asked during document opening and saving to enter their SharePoint credentials.

The process for creating a new document by using Microsoft Office in SharePoint can be initiated in SharePoint or Office. We recommend that you have users initiate creation in SharePoint. This method is seamless, offers the fewest steps, and avoids confusion about how to save documents. To create an Office document in SharePoint, follow these steps:

However, if the user elects to initiate the creation in Office, the user will create the standard blank document. To save the document, the user will click the Browse button and enter the site they want to save to. When they press Enter, they will be able to browse that site and its libraries directly in Office. They can select the destination library, name the file, and click Save.

In both scenarios, after a document is saved the user will have additional properties available in the Info portion of the document, as shown in Figure 2-3. After a user has saved to a library once, it can be conveniently accessed as a Recent Location for storing documents to SharePoint in the future.

Figure 2-3. Document Info page.

It is also possible to save links to documents. A link to a document is a pointer to an alternate save location, normally locally on the user’s machine. We strongly recommend that you do not use this feature. It results in confusion about where documents are actually saved. It leads quickly to frustration from the users, missed versions, and duplicate files.

In the last 10 years, there has been a major shift from legacy ECM implemented via client/server applications to ECM implemented via a browser/server infrastructure. In both scenarios, the storage and management of the content was managed by a heavy server-side application, but the interface for the users went from an accompanied thick client that tied users to a specific device to device independence wherever you have a browser. The shift away from legacy ECM applications that require program files loaded on the client workstation is still not complete. The initial feature set transitioned from thick client programs was focused on features like administration, search, and processing of content after being saved to SharePoint. What remained was content authoring that was still tied to thick client programs, like Microsoft Office, installed on individual devices. We are of the opinion that over the next several years, desktop client authoring tools will primarily be used for production level authoring and web interfaces will be used by the vast majority of users who create basic documents. The other consideration is the rise of mobile authoring and content contribution using tablets and smart phones.

Starting in SharePoint 2010, it is now possible to create documents in the browser. For the average user, all required functionality is present in the browser, with the ability to use the new Ribbon toolbar to perform word processing, spreadsheet, and presentation creation. In SharePoint 2010, the ability to do so still relied on the client machine having an install of Microsoft office.

Now, in SharePoint 2013, the reliance on the device having a client Office application is no longer the case, allowing for fully independent creation of content via the web browser. This is a game changer that helps define SharePoint 2013 as a fully cloud-enabled ECM solution.

In either SharePoint 2010 or SharePoint 2013, this requires an additional product called Microsoft Office Web Apps. In SharePoint 2010, this is an add-in to the existing farm, and in SharePoint 2013, this is a separate Microsoft Office Web Apps server, also referred to as Web Applications Companion (WAC). This gives you the ability to interact with a spreadsheet exactly as you would in the thick client Microsoft Excel program, as shown in Figure 2-4.

Figure 2-4. Microsoft Excel 2013 Web App.

When this functionality is deployed, it is nearly unnoticeable that the user is not working within a thick client application. In addition, access to this functionality is supported across many mobile devices, including laptops, tablets, and handheld smartphones.

The latest support of Office Web Apps allows for users to simultaneously edit documents. This functionality is useful in a team site scenario when multiple people are contributing to the early drafting of content, where the direction of the content isn’t fully outlined. Having multiple contributors, regardless of location, be able to share ideas in real time is extremely powerful.

If at all possible, organizations should take the extra step into native SharePoint document creation. If it is possible for your organization to take this path, we recommend an all-or-nothing approach. That is, if you can deploy Web Apps for your SharePoint 2010 farm or install the Office Web Apps Server 2013 and connect it to your SharePoint 2013 farm, you should also remove the thick client-side applications from your user desktops.

In some scenarios, you might want to give certain power users access to the full Office suite. You need to understand that the combination of the two will make supporting users complex due to the interface similarities of both products. Because there are huge technical differences between thick client programs and browser-based usage, it can make it more difficult for the IT support or help desk staff to triage the issue and troubleshoot.

As we mentioned in Chapter 1, the use of electronic forms is a great way to capture structured information from submitters. It’s important to understand that electronic forms capture is used only for the purpose of capturing data, whereas the capture process using Microsoft Office also facilitates document editing and modification.

Electronic form capture is typically used to receive responses to a specific set of questions submitted by an audience of users. In SharePoint, each submission results in a document saved in a special format located in a library accessible by the publishers of the form and usually not the submitters or respondents of the published form.

In SharePoint, this is most often accomplished by using InfoPath. We will not cover InfoPath in detail in this book and recommend, if you are using electronic forms to capture information, that you get specific training on InfoPath.

The last form of capture we will discuss is image capture. This is the process of taking physical documents, converting them from paper to digital, and storing them in SharePoint.

Document imaging in SharePoint is not a native function or feature of the product. The most common deployment of document imaging for SharePoint is front-loaded using third-party software applications. The two ways to perform document imaging in SharePoint are as follows:

External capture applications allow you to capture and convert documents and then automatically or manually upload them to a SharePoint document library. The primary benefit of these applications is that they can scale to support the capture of large volumes of paper documents. Ideally, an organization should seek such applications that support the conversion of images from image-only files to richer document files such as Word or PDF. This is done by using Optical Character Recognition (OCR), which we will detail below. Your organization should also seek applications that allow the population of metadata to document libraries as content is uploaded to SharePoint. Simply scanning paper and dumping to SharePoint with simple file names is not a best practice and will leave you unable to find, manage, or process the content effectively, if at all.

There are also a handful of ad hoc capture applications that run natively in SharePoint. These applications allow a user to initiate a scan and store a paper file directly from a document library, just as if the user was creating an Office document from scratch. The same metadata considerations apply for this type of solution. You want to find a solution that offers conversion from image-only file types (TIFF, JPG, BMP) into other more-useful formats, combined with metadata.

In either type of solution, the considerations of image capture are the same. You must first isolate which of the following type(s) of capture meets your organization’s needs:

In SharePoint, the physical storage of documents happens in MS SQL. The documents and their associated metadata are stored into content databases. To ensure scalability and performance of the farm, it’s recommended to keep content database sizes below 150 GB. To do this, you need to know more about the information you are storing there. In most organizations, the best gauge for how large an ECM platform will grow is to first establish a starting point.

Roughly 40 percent or less of the total size of shared network drives and storage will end up in ECM. After proper evaluation of shared drives, you will find that much of the content is not proper ECM content, contains duplicate files, or has met its retention date. For this reason, it is very important to perform a records inventory of your shared drive content so that you can eliminate redundant and outdated information.

So to begin, take 40 percent of your total shared drive space utilized. This will give you a total estimate. If your organization is lucky enough to have this already at less than 150 GB, you are in good shape, but if it’s larger, you need to dig deeper and start calculating that same size, but in sub-units such as departments and/or functional operations within departments.

The results of a records inventory, data cleanup, and segmentation of this information into logical factors will give you a general idea of how many content databases you will need for initial deployment. The tricky part is determining what will be needed as the organization and the information it creates grows. We have a fundamental understanding that there is rapid information growth taking place today. This is supported by the fact that most of the world’s information was created in the last five years. If you weren’t experiencing the demands this amount of information is putting on your organization, you probably wouldn’t be reading this book.

However, for your organization, content can be created only as fast as and with as many knowledge workers that are employed there. Therefore, growth of content should be relatively steady and predictable. There are various means to get to your annual growth, but the easiest way is to take a subset of your shared drive and calculate the total size of it.

If your organization is large and you are fearful of SharePoint’s limits on content databases, you need to consider implementing Remote Blob Storage (RBS).

SharePoint supports configuration of Remote BLOB (Binary Large Objects) Storage (RBS) as an option for storing content objects directly in the database. This is actually a function of SQL Server and provides the ability to offload storage from the content database to external non–SQL-based hierarchical storage platforms. It is recommended for content databases 4 GB and larger.

RBS can facilitate a measure of scalability for specific use cases that involve large individual file sizes and/or high volumes of objects. The configuration of RBS can be targeted to specific SharePoint web applications, site collections, or individual sites. An example of this would be large engineering vector files and high-volume document imaging solutions. In most use cases, this is not necessary, and storing the objects in the database has the advantage of providing one source from a backup and disaster recovery perspective.

There are third-party solutions built to take advantage of RBS to reduce the impact of database BLOB I/O performance issues. This can also reduce the overall footprint of the database architecture needed to support SharePoint and enable the use of lower-cost storage devices. Your most accessed and current content can reside as BLOBs in the content database and be migrated to external RBS storage locations based on metadata values, content types, or other configurable parameters. As a side note, External BLOB Storage (EBS) was a hotfix provided for MOSS 2007 that provided entire farm-level externalization of content objects.

Where content databases meet web applications and site collections is where the logical storage of content begins.

Information Architecture (IA) at first seems to be one of those vague things that people talk about to sound smart. This section will define it in more tangible terms. IA is where your organization will spend most of its time and planning for a SharePoint ECM Solution. If you don’t understand, formulate, and execute a sound IA, you are almost certainly destined for failure, or at the very least, you will only duplicate what exists on your shared drive infrastructure.

Like its parent ECM, IA is not a technology or feature. It’s a collection of features that, when put together properly, make up the organization of content. IA breaks into the following categories:

Repositories are the bridge from the physical storage to the logical storage. Many users don’t realize that the folder location of the file has little to do with where it’s physically stored. This is an example of how what we see on the screen translates to something very different in the IA.

The metadata model is how the content is tied to its associated metadata. Think of the metadata model as a cell in a spreadsheet, and the metadata is the value placed in the cell; there is an inseparable bond between the two, yet they are distinct in their purpose and their properties. The model also details what metadata a document should have or require during capture and how it should be visible to the user.

The presentation layer is where users can interact with the IA. This layer provides a way to slice and dice content, given good metadata, to better find and interact with it.

Metadata is a separate condition from taxonomy and folksonomy, and they take separate consideration. Together, these are tools that can be used to define ways of organizing content in lieu of folders. Ideally, good-enough taxonomies are created to support any number of combinations to find content. Taxonomy and folksonomy serve the same purpose and are implemented in the same way. However, folksonomy is less strict and more prone to a user’s nomenclature, while taxonomy is a strict listing of terms that is very rarely modified.

During the discussion of managed metadata, we will go deeper into how to build these. Table 2-1 shows the various categories and components that need to be considered as part of a complete IA.

Even though we have identified the individual components, that alone will not solve the IA challenge. When you bring them all together, they will strongly impact how users will interact with a system, the quality of capture, and the results they find when performing a search. Now let’s discuss the goals of IA and then how to approach each individual component.

Ideally, an organization will spend sufficient time planning out the IA for SharePoint; the actual deployment of the farm is just an execution on this plan. Although the IA aligns to SharePoint features, most of the planning work is done outside of SharePoint instead of inside a configuration interface.

The first thing you must consider is what will be the determining factor for creating new repositories in SharePoint. It could be related to the type of content, to the size of content, or by organizational structure.

The type of content might determine that it has a special type of security that no other content in the organization uses. Because of this, it might need a more high-level type of organization so that the proper security can be applied. For example, many organizations have “management” portals. While each manager in the portal heads a department with its own separate SharePoint site, all managers have access to information that users in those departments should not have access to. Therefore, managers have access to the portal as well as access to their individual departments, whereas users can have access only to the department to which they belong.

The size of the content might determine some IA because, as we stated earlier, content goes in content databases. The first two portions of SharePoint IA are web applications and site collections, which also determine the number of content databases. For example, a small organization might get away with one web application and a site for each department, whereas an organization with a higher volume of content will need a web application per department. Even assuming security access for both organizations are the same, the size constraints could be the deciding factor.

And finally, what do you organize by? When you consider only purely logical storage of information without any size or security constraints, you are deciding how users access information. We recommend choosing organization in the following two ways:

Only in unique verticals and cases will this not work for an organization. In many organizations, they are the same. However, some organizations don’t have departments that align directly with function. Generally, if departments are more tied to management than to function, you will want to organize by function, because users are joined by function. However, most organizations get away with departmental organization. You might be asking, “What if users cross departments?”

They could! And there are several ways to approach this. In organizations where security is a larger concern, you will grant access to those knowledge workers who bridge departments on an individual basis. The other option is to create team sites for cross-functional teams while not altering the security at a departmental or functional level. Finally, there is the recommended approach for the vast majority of organizations, which is tying security not to a department level but to a role. For example, all knowledge workers should have knowledge worker access to all department sites no matter which they belong to. The only real downside of this approach is that users might waste time on content that does not pertain to their function.

The first thing to consider is the web application, which is where the hand-off from physical to logical storage occurs. Because it’s rare to have a web application without a root site collection, we will also consider site collections at this point.

The web application is the first envelope where the user gets involved. It is also the demarcation of new content databases. While web applications can have multiple content databases, they usually have only one. As illustrated in Figure 2-5, the name of the web application and root site should be simple; that is, legal should be “Legal” and human resources should be “Human Resources.”

Figure 2-5. Legal web application in SharePoint.

If your organization is small and you have a single web application, these will be the names of your sites, and your web application could be a personification of the web application or just your organization name. For example, some companies used \ECM or \DocumentCafe. There are some cases where you will have special web application names, such as in the case of content type publishing, which we will discuss later.

Web applications and root site collections go hand and hand. It’s rare to have a web application without a site collection. The root site in a site collection is the landing location of the web application URL.

Within each root site collection are sites. Sites, like web applications and site collections, are dependent on how large your SharePoint deployment will be. If you have a single web application for the organization, you will most likely have a site per department and function with the addition of restricted legal and management sites as needed. If you have a web application per department or function, you might not need any subsites, but for very large organizations with nested departments, it might be required.

The rule we would like you to follow in your ECM implementation is to never use sites two layers deep. The most successful user adoption of IA in SharePoint is to be as flat as possible. We find that when you have layers of navigation and repository drilldowns, it’s troublesome for users trying to find the content they need and for administrators working to support enterprise governance.

Sites are where you can also differentiate the types of templates you use. A template contains settings and branding for new sites to be built on. In this book, we use almost exclusively the document center site template. However, customized templates can be used in SharePoint to more rapidly deploy a solution. For example, you can build just the ideal ECM site template for a department just once and then easily use that template to create all other departments in much less time. This takes discipline, because it requires that your full deployment happens up front, prior to any content being uploaded.

After web applications and root sites are established and all subsites are created, document libraries and lists must be created as well. Unstructured content lives in libraries, and structured content lives in lists. Because most of what ECM addresses is unstructured content, we will focus on document libraries for your ECM solution.

The first mistake organizations make with libraries is allowing them to be created by individual users. Generally, this results in tree navigations that go on forever and library names that are confusing. The benefit of standardizing libraries across ECM sites is that no matter where a user is in the organization’s farm, they will understand what goes where.

Many organizations will use libraries as the topic matter. Where sites stop at functions, libraries start with topic. However, in the ideal ECM environment, where we are keeping the IA flat, libraries are associated with types of content. The ideal ECM environment will have three libraries per site: Documents, Rich Media, and Email.

While this three-library concept, shown in Figure 2-6, seems radical, it allows for the most flexibility and the least amount of clicks to any document. The concept is that libraries are the types of content—that is, unstructured documents in the “Documents” library; for email-enabled farms, email in the “Email” library; and media files in the “Rich Media” library.

Many organizations already have special considerations for email and rich media, so these might be exceptions. For example, it’s not uncommon to have a separate web application for the entire organization’s rich media files. It is not common to store email in SharePoint, and that takes some serious consideration. Therefore, many organizations might find that the number of libraries they have using the outlined principles in this book are small.

The primary reason that you might choose to expand the listing of libraries would be having too many individual items to contain in a single library. It’s recommended not to exceed 5,000 items per library. Often, we find if you are wanting to store this many items in a library in the first place, you did not heed the initial recommendation of not using SharePoint as a shared drive.

A secondary reason is large amounts of specific document types such as invoices or contracts. Although we can address this easily in the library with the metadata model, it might be enough to consider having separate libraries. How you would decide to handle this is based on the processes that surround those documents and the ease of access at the time of retrieval.

Figure 2-6. Document libraries.

Now our discussion will move from repositories, the local filing location, to metadata. At the library level, content starts to be populated, and as that happens, you need to have metadata properties defined and populated as well. The big difference between the two in the case of SharePoint is that repositories are the paths to content and do not exist as pieces of metadata that belong to a document, whereas the metadata model is associated with the documents themselves.

In this section, we will consider the metadata model as all inclusive. Metadata is data about data. As shown in Figure 2-7, metadata comprises the values that appear in SharePoint columns that allow you to organize, view, and find content without opening files individually.

There are two types of metadata, structured and unstructured, just like types of content. Structured metadata are things like “Last Modified Date” and “Author.” These values are usually automatically entered by the system. Unstructured metadata values are created to specifically support the content that will be stored in a particular document library and can be entered at the time of capture during a workflow process or by some other automated means.

Unstructured metadata includes comments, keywords, tags, and so on. The mechanism for entering metadata is via a content type. Content types are the containers of metadata columns. The default content type for a document contains the metadata fields Name and Title, with the additional fields Modified and Modified By added by the farm. While it is possible to create new columns on a library level, we recommend that you do not. At minimum, we recommend that you create and modify content types from the root site. Ideally, you will want to use the content type publishing feature in SharePoint.

Figure 2-7. Metadata properties.

Content type publishing allows you to create content types in a single location and then publish them across the farm. This means that all modifications to the content type will be syndicated. This requires you to set up a Content Type hub with all desired content types, as shown in Figure 2-8, in advance of using them in any site. The benefit of the hub is that you know that all content types and metadata fields will be consistent throughout the farm, which also means that if content moves from one library to another, the experience will be consistent.

Figure 2-8. Content Type hub.

Organizations should use the Document base content type as the starting point for any new content types. New content types will be created based on a heavily used type of document that is specific to a transaction or operation in the organization. This can follow the same examples we used in the discussion of higher volume and repetitive content items such as invoices and contracts.

Content types should not be confused with a method of organization but rather should be seen as the container of the organization criteria. This distinction is a subtle one. For example, an organization might feel that it can create content types for every type of document and use that as a method of organization. The problem is that content types themselves are not metadata, just containers for it. Therefore, the value of that content type goes only as far as the library where it’s set up. For organizational purposes, you should create new columns, and those columns will have the metadata you desire.

Before creating a new column, decide on its purpose. During the planning phases of your ECM solution, you might tend to put everything you can possibly think of in a content type for fear of missing something. However, this usually results in too much information that is never used. So before you ever add a new column, decide how the column will be used. You should be able to write out use-case examples of how each new column will be consumed and the purpose for having it.

To complete our IA, we have two remaining components that are a part of the metadata model. They are rather unique, and it’s important to understand the nuances of each. They are document IDs and taxonomy and folksonomy.

The document ID is a relatively simple feature with a very high impact. The document ID service will allow you to implement persistence for documents across the farm, especially in the scenario where your organization has broadened the IA to include a web application per department, knowing that documents have singularity and that the ability to identify a document wherever it’s located in SharePoint is critical.

The document ID will automatically generate a unique ID per document uploaded to the farm. The document ID is stored as a searchable piece of metadata associated with the content. The document ID (DocID) is persistent for the life of the content object. Therefore, regardless of where that document is sent, the ID will remain the same. If this weren’t the case, Records Management (RecMan) would not work and the chain of custody would be broken. We will cover the importance of legal authenticity and chain of custody in more detail in Chapter 8.

We recommend that you enable the document ID feature on all your ECM site collections. While you might not always show the ID to the user, the feature supports a best practice for your overall content governance strategy. To enable document IDs, you will turn on the document ID site collection feature for all site collections in the farm that you’re planning to use for your ECM solution. When the feature is enabled, a new setting option will appear on the site collection level called “Document ID Settings.” As shown in Figure 2-9, you can specify the prefix for the document ideas to be created. Using custom code, you can also customize these IDs even further to support your enterprise governance requirements.

Figure 2-9. Document ID Settings page.

When we talk about the terms taxonomy and folksonomy, we’re usually greeted with some blank stares and quizzical expressions. They are uncommon pieces of the natural English language but are used very commonly in the discipline of Records Management and content organization. To make it more familiar, think of a folder structure that you might see when you use File Explorer to navigate and find documents in your local My Documents folder. This is likely the closest thing to a taxonomy structure that anyone should be able to relate to. The file system that the folders and the documents are stored in is just a piece of metadata, and nested folders are a hierarchical organizational structure.

Taxonomy implies a collection of terms and their hierarchy. This creates a relationship that allows you to save content and find it later in a repeatable and logical manner. Taxonomies also branch into areas of synonyms (ontologies) and relationship of terms. But the general purpose of taxonomy is to organize your content based on specific department or operational terminology.

Folksonomy is implemented as a taxonomy that gives departments or operational units more flexibility. Folksonomies tend to be more personal, while taxonomy is stricter and applied to an entire organization. In SharePoint, both are implemented as managed metadata columns as shown in Figure 2-10. When you have mastered how to create and manage your taxonomy, the process is simple. The hard part is the concepts behind these tools.

Figure 2-10. Taxonomy definition using managed metadata.

As we stated already, taxonomy is stricter and folksonomy is more flexible. The biggest mistake organizations make is to build a taxonomy for the entire organization. Not only is this extremely time-consuming, it is very difficult to get consensus between departments, whether or not they are cross-functionally dependent. In your taxonomy, we strongly urge you to abide by the following guidelines:

There are essentially three types of taxonomies. These are functional, regional, and time based. A functional taxonomy for the organization is possible only when it’s simply a listing of the organization’s structure. Each organization is unique, and yours might not fit exactly into a taxonomy as we describe it, but we have found that for the vast majority of organizations, taxonomy per department is required.

Many organizations choose to employ types of taxonomy. A document will be assigned to only one term per taxonomy. For example, if I upload an employment agreement to the HR department’s ECM site and I’m located in the New York office, I would apply “New York” from the regional taxonomy, “HR” from the organization-level taxonomy, and “Legal >> Agreements >> Signed Contract” from the HR-level functional taxonomy.

Taxonomies are stricter. Because of this, you will want to create them up front, and for the most part, they will remain unmodified. Instead of introducing new terms to the taxonomy, you will add synonyms to existing terms to help user adoption.

We have worked with many companies that struggle with the strict nature of taxonomies, and you might find that your organization encounters a similar experience as you start to define them. Therefore, you might elect to incorporate a strict taxonomy with a more flexible folksonomy, or skip taxonomy altogether.

Folksonomy is implemented via managed metadata just like its stricter cousin, taxonomy. The big difference is that the terms are usually user contributed and not assigned up front but as the users interact with the content stored in the ECM solution. The benefit is that the terms more closely align with the terms and idioms that the users commonly call content. You could even think of it as corporate slang or operational lingo. It’s important not to get too carried away with folksonomy because you could end up with term sprawl as terms are rapidly adopted and applied to content to support every spelling variation of every term possible.

The ease of administration of taxonomies and folksonomies in SharePoint doesn’t do justice to how powerful and dangerous they can be. Simply creating a set of terms and publishing to your users without validating language and use can be extremely problematic and difficult to unravel. Your organization needs to spend considerable time planning the use of taxonomies and folksonomies.

The metadata elements “Like” and “Rating” fall roughly into the category of folksonomy, which is the lose tagging of content by users. They also show up as metadata but have their own functions inside of SharePoint.

Would you ever “Rate” your boss’s document with 1-star? Rating documents is the ability for users in a library to note how useful a particular document is with a granular 1–5 rating.

Similar to rating content is the ability to like content, which is a binary way of flagging content. The biggest difference is that “Like” creates a collection of favorite documents for individual users that are presented in their profile pages as a part of MySites. For this particular feature to be useful, the organization has to plan to use and be effective with MySites.

In this book, we are not going deeply into MySites. However, we do want to assert a position on them so that you can properly prepare if you do decide to implement them. MySites should be carefully planned out, and the benefits and drawbacks should be weighed prior to turning on the Profile Services and MySite features. We have defined the IA that should be followed for an ECM solution. MySites should also be defined and planned in a similar fashion, and it should be considered a project in and of itself.

As you can see, IA, although usually the most ignored element in ECM planning, is an absolutely critical component that will largely define the successful user adoption, content findability, and governance objectives in ECM. Later, we will see examples of SharePoint deployments where the full deployment is executed using the best practices and principles we have covered in this section.

When new documents are uploaded to SharePoint, they can be automatically routed, automatically initiate a workflow, or be modified based on specific criteria. This is a basic way to enrich content and reduce burden on users at time of document upload. In SharePoint, this is achieved with a feature called the content organizer. There are many use cases for this feature, and we recommend this as a good place to start automating notifications for users that new documents have been uploaded. In Figure 2-11, we show a simple configuration that will notify Chris that a new document has been added to the Press Release document library and needs his review.

Figure 2-11. Notification trigger is set using the Content Organizer.

This type of workflow manages document expiration and retention by allowing participants to decide what action to take on expired content. The expiration is determined by information management policies that trigger an event. This usually results in a task created for someone, and a workflow process is initiated to track the completion of the assigned task.

As shown in Figure 2-12, when a document has expired (in this case, a Press Release [PR]), a task is assigned to Chris to review the PR document and approve its expiration. This will remove it from the extranet website that it is published to.

Figure 2-12. Press Release document expiration triggers a review task.

This workflow is typical of a waterfall workflow, but with limited states. (The term waterfall infers that you can move forward in actions, with limited ability to send documents backward.) The individual states are the steps the document will take based on human decisions or systematic actions. The uses for this workflow are primarily document approval. In the following example, shown in Figure 2-13, a document needs to be approved by three individuals prior to being published to an extranet site.

Figure 2-13. Press Release document is routed to three individuals for approval.

Conditional formatting is used highlight specific content, based on rules and triggers applied to metadata. Many users are already used to conditional formatting, because it is commonly used in Microsoft Excel, and can be similarly used in SharePoint in libraries and lists. It’s most common in lists of data but also very useful in a library of documents to “flag” or highlight content.

This more general form of workflow is a very powerful tool to create many types of more advanced workflows. This type of workflow is created outside of SharePoint, using SharePoint Designer and Visio for flowcharting to create a visual representation of the process. After design, they are published to a SharePoint site for use on content. The more advanced workflow allows the use of variables, multiple column data, parallel actions, Boolean logic, and basic conditions. After the workflow has been published, it’s available to be scheduled or used on content in an ad hoc manner. A good illustration of creating a workflow in SharePoint Designer is shown in Figure 2-14.

Figure 2-14. Visio flowcharting.

Content routing, disposition workflow, and three-state workflow can all be achieved in the browser with any authorized user. Conditional formatting and general workflow are created by using SharePoint Designer. It’s an external client application that connects to the sites on the farm for more advanced modification. This tool is not for typical users and can be used to modify many more complex features of SharePoint besides core ECM functionality.

We recommend limiting the use of workflows in ECM to the features and example given, if at all possible. You should also try limiting the number of features and third-party tools to as few as possible. We have found that the key to successful process implementation is simplicity. The general workflow is based on the Windows Workflow Foundation. The administrator will most likely create this workflow in SharePoint Designer with the addition of a Visio flowchart if needed. Obviously, this can be taken further with code, but we caution you to keep it as simple and straightforward as possible. Otherwise, you will follow in a long line of projects that never seem to end.

Organizations can conceivably build any workflow scenario they can dream up by using the methods and features we have covered. Use caution when designing and implementing your workflow, and remember that you will have to provide maintenance in the form of updates and modifications. Some best practices to follow when designing workflow include the following:

It’s not uncommon for individuals who create a workflow and have intimate knowledge of how it works to leave an organization, leaving the company stuck with one option, which is to discontinue the use of a workflow. This could be very disruptive to the usage of the ECM platform. It’s uncommon in ECM to need advanced workflows beyond approval workflows based on states. Such custom workflows are best suited for custom line-of-business applications built on SharePoint. We therefore recommend that if the workflow cannot be easily created using OOTB methods or SharePoint Designer, the organization should consider a third-party tool for managing and building the workflows.

The subtle difference between Business Process Management (BPM) and workflow is the maintenance of workflows. The “Management” part of BPM separates it from standard workflow creation. In a standard workflow creation, a workflow is published without regard to previous workflow versions, without regard for who created it, and without regard for when it needs to be updated, and so on.

We further extend process into the area of Business Intelligence (BI). Although it’s not terribly common on documents, BI in SharePoint is very powerful. Like conditional formatting, BI is a way to visualize content to surface key data and performance metrics that can be used to improve business decisions and outcomes. BI is most common on list data and not content, but some organizations find ways to leverage BI also on documents. More specifically, we are referring to the visualization form of BI, not self-service BI or data mining.

The differences between BI in SharePoint 2010 and SharePoint 2013 are fairly substantial. The subset of features to accomplish this is called PerformancePoint. Typically, an organization will have a separate site collection for data reporting. To be successful with PerformancePoint features and documents, the metadata has to be a top consideration. To achieve relevant and meaningful visualization of the business data, you must have a well-structured, consistent, and accurate metadata model for document content types.