This document outlines a presentation on taming taxonomy in SharePoint. The presentation covers content architecture and taxonomy theory, including how they relate. It discusses practical SharePoint concepts like content types, site columns, and metadata in depth. The presentation includes an exercise where attendees work through a taxonomy scenario. It emphasizes the importance of planning, documenting, and following governance for taxonomy.
1. SharePoint Saturday New England 2017
#SPSNE
spsnewengland.org
Taming Your Taxonomy in SharePoint
Jonathan Ralton
All trademarks and registered trademarks are
the property of their respective owners.
12. In Theory…
Business
Process
Automation
Portals Social Co-Authoring
External
Collaboration
Workflow
Team
Collaboration
Incident
Management
Project
Management
Knowledge
Management
Enterprise
Content
Management
Application
Platform
15. In Theory…
What is…
• Content Architecture
• Taxonomy
How do they relate?
Content Architecture
Taxonomy
16. Content Architecture
1. The specification for a content management
solution
2. A set of activities and outputs for effective
content management
– Cleve Gibbon
39. Content Type
“a reusable collection of:
1. metadata (columns),
2. workflow,
3. behavior, and other
4. settings
for a category of items or documents in a…list or
document library”
40. Name Parent Name Group
System #N/A _Hidden
Document Collection Folder Folder _Hidden
System Page #N/A _Hidden
System Page Layout #N/A _Hidden
System Master Page #N/A _Hidden
Audio Rich Media Asset Digital Asset Content Types
Image Rich Media Asset Digital Asset Content Types
Rich Media Asset Document Digital Asset Content Types
Video Rich Media Asset Digital Asset Content Types
Document Item Document Content Types
List View Style Document Document Content Types
Form Document Document Content Types
Picture Document Document Content Types
Master Page Document Document Content Types
Wiki Page Document Document Content Types
Basic Page Document Document Content Types
Web Part Page Basic Page Document Content Types
Link to a Document Document Document Content Types
Dublin Core Columns Document Document Content Types
Document Set Document Collection Folder Document Set Content Types
Folder Item Folder Content Types
Discussion Folder Folder Content Types
Summary Task Folder Folder Content Types
Announcement Item List Content Types
Comment Item List Content Types
Contact Item List Content Types
East Asia Contact Item List Content Types
Event Item List Content Types
Issue Item List Content Types
Item System List Content Types
Link Item List Content Types
Message Item List Content Types
Post Item List Content Types
Reservations Event List Content Types
Schedule Event List Content Types
Schedule and Reservations Event List Content Types
Task Item List Content Types
Page System Page Publishing Content Types
Page Layout System Page Layout Publishing Content Types
Publishing Master Page System Master Page Publishing Content Types
41. Content Types – Inheritance
Item
Announcement Contact Event Issue Link Post Task
Document
Picture
Folder
Discussion
Document Set
42. Content Types – Categories
Item
Document
Folder
Document
Set
44. Content Types – Warning
DO NOT modify
the out-of-the-box
content types!
45. Content Types – Considerations
Site 1
Site 1.1
Site 1.1.1
Site 1.1.2
Site 1.2 Site 1.2.1
Site 1.3
• Where to define (Scope)
46. Content Types – Considerations
Intranet
Home
IT
Department
HR
Department
Marketing
Department
Sales
Department
Benefits
Team
Compensation
Team
• Ad
• Development Plan
• Invoice
• Offer Letter
• Performance Review
• Purchase Order
• Salary Increase Request
• Termination Letter
47. Content Types – Considerations
Content
Type 1
Content
Type 1.1
Content
Type 1.1.1
Content
Type 1.1.2
Content
Type 1.2
Content
Type 1.2.1
Content
Type 1.3
• Hierarchy (Inheritance)
• Levels of abstraction
48. Content Types – Considerations
• Ad
• Development Plan
• Invoice
• Offer Letter
• Performance Review
• Purchase Order
• Salary Increase Request
• Termination Letter
49. Content Types – Considerations
Document
Ad
Invoice
Offer Letter
Purchase Order
Salary Increase
Request
Termination Letter
50. Content Types – Considerations
Document
HR Document
Offer Letter
Salary Increase
Request
Termination LetterAd
Invoice
Purchase Order
51. Content Types – Considerations
Document
Corporate
Document
Invoice
Purchase Order
HR Document
Offer Letter
Salary Increase
Request
Termination Letter
Marketing
Document
Ad
52. Content Types – Considerations
Document Master Document
Corporate
Document
Invoice
Purchase Order
HR Document
Offer Letter
Salary Increase
Request
Termination Letter
Marketing
Document
Ad
53. Content Types – Considerations
Standard Shipping
Request
Expedited Shipping
Request
Air Freight Request
International Air
Freight Request
Rail Freight Request
Ocean Freight
Request
International Ocean
Freight Request
• Shipping Approval
• Expedited Shipping Approval
• Exports Authorization
54. Content Types – Considerations
Shipping Request Type
Shipping Approval
Type
Standard Shipping
Request Type
Standard Shipping
Request
Non-Standard
Shipping Request Type
Air Freight Request
Rail Freight Request
Ocean Freight Request
Expedited Approval
Type
Expedited Shipping
Request
International Shipping
Request Type
International Air
Freight Request
International Ocean
Freight Request
• Shipping Approval
• Expedited Shipping Approval
• Exports Authorization
55. Content Types – Considerations
Site
Content
Type A
Content
Type A
in List 1
Content
Type A
in List 2
Content
Type A
in List 3
Content
Type A
in List 4
• Site vs. List/Library content
types
56. Content Types – Considerations
My Document.docx
Document Content Type
http://path/My%20Document.docx
Link to a Document Content
Type
• Link-based content types
60. Site Columns – Types
All Day Event
Audience Targeting
Calculated
Choice
Currency
Computed
Cross Project Link
Date and Time
External Data
File
Hyperlink/Picture
Integer
Lookup
Managed Metadata
Multi-Text
Number
Number of Ratings
Person/Group
Publishing HTML
Publishing Image
Publishing Schedule End
Date
Publishing Schedule Start
Date
Rating (0-5)
Recurrence
Summary Links
System
Text
Yes/No
61. Site Columns – Considerations
Site 1
Site 1.1
Site 1.1.1
Site 1.1.2
Site 1.2 Site 1.2.1
Site 1.3
• Where to define (Scope)
62. Site Columns – Considerations
Site
Column
Type A
Column
A in List
1
Column
A in List
2
Column
A in List
3
Column
A in List
4
• Site vs. List/Library columns
63. Site Columns – Considerations
Choice
Lookup
Managed
Metadata
• When to use which type
65. Site Columns –
Considerations
• ID;#Value
• Does update
• Metadata about choices
• Projected Fields
• Expand scope of List, but not
across Site Collections
• Possibility for cascading lookups
Lookup Column
66. Lookup Columns – Considerations
Site 1
Site 1.1
Site 1.1.1
Site 1.1.2
Site 1.2 Site 1.2.1
Site 1.3
• Where to define (Scope)
List
List
67. Site Columns –
Considerations
• Hierarchy of terms
• Scope across site collections, web
applications, farms
• No metadata about choices in
2010
• Extended Properties in 2013+
• Can assist with navigation
• No InfoPath support
• Folksonomy possibilities
Managed
Metadata Column
69. Site Columns – Considerations
• Too few columns?
• Too many columns?
• Required/Not Required?
70. Site Columns – Considerations
My Column
• My%20Column
My Column
• Mycolumn
Renamed Column
• oldnamecolumn
• ‘Internal Name’/Static Name vs.
‘Display Name’/Title
80. Metadata – Process
1. Identify common elements
2. Identify unique elements
3. Associate at the appropriate level(s) on the appropriate content
type(s)
81. Metadata – Process
Document Master Document
Corporate
Document
Invoice
Purchase Order
HR Document
Offer Letter
Salary Increase
Request
Termination Letter
Marketing
Document
Ad
• Employee Name
• Termination Date
83. SharePoint Building Blocks
Content Types
• Use to…
• Maintain consistency across
libraries and lists
• Isolate workflow, policies, and
other settings
• Information Management (Records
Management)
• Etc.
Site Columns
• Use to…
• Drive views
• Expose via search
• Drive reports
• Preserve information
• Trigger workflow
• Etc.
84. SharePoint Building Blocks
Farm
Web
Application
Content
Database
Site
Collection
Site List/Library
Item
Item
Site
Collection
Site List/Library Item
Site List/Library Item
Content
Database
Site
Collection
Site List/Library Item
Web
Application
Content
Database
Site
Collection
Site
List/Library
Item
Item
List/Library ItemSite
Collection
Site
85. Taxonomy/Context – Uses
• Leverage security (List, Site)
• Differentiate list-based workflows (List)
• Segregate content (List, Site, Site Collection)
• Facilitate geographic placement (Farm)
• Control versioning (List)
• Account for alternate authentication method(s) (Web Application)
• Account for encryption (Web Application)
• Etc.
86. Taxonomy/Context – Approach
1. Determine what content is needed where
2. Associate at the appropriate level(s) with the appropriate
container(s)
87. Taxonomy/Context – Considerations
• The content that will be stored as items
• The site and list/library columns that will identify, qualify, and differentiate those
items from each other
• The content types that will help maintain appropriate metadata, workflow,
behavior, and other settings for different kinds of items
• The lists/libraries that will segregate those items within the sites
• The sites that will contain those lists/libraries
• The site collections that will contain those sites
• The content databases that will house those site collections
• The web applications that will contain those site collections
• The farms that will host those web applications
88. Site Templates
Assets Web Database
Basic Meeting Workspace
Basic Search Center
Blank Meeting Workspace
Blank Site
Blog
Business Intelligence
Center
Charitable Contributions
Web
Contacts Web Database
Custom
Decision Meeting
Workspace
Document Center
Document Workspace
Enterprise Search Center
Enterprise Wiki
FAST Search Center
Group Work Site
Issues Web Database
Multipage Meeting
Workspace
Personalization Site
Projects Web Database
Publishing Site
Publishing Site with
Workflow
Records Center
Social Meeting
Workspace
Team Site
Visio Process Repository
89. Library Templates
Asset Library
Dashboards Library
Data Connection Library
Document Library
Form Library
Picture Library
Record Library
Report Library
Slide Library
Wiki Page Library
95. Deduction
Management
Site
Deduction
Library
Customer
Operations Site
Deduction
Contract
Library
Advertisement
Library
Billback Library
Syndicated
Data Library
Spin Report
Library
Scan Data
Library
Markdown
Funds Library
Repay Library
Markdown
Funds Site
Contract
Advertisement
Billback
Repay
Scan Data
Spin Report
Syndicated
Data
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Deduction Type
Customer
Date Requested
Date Range Start
Date Range End
Contract Documents
Advertisement Documents
Billback Documents
Deduction Number
Repay Documents
Scan Data Documents
Spin Report Documents
Syndicated Data Documents
Product Category
Markdown
Deduction Status
110. Links
SharePoint 2010 SharePoint 2013 SharePoint 2016 SharePoint Online
Resources for IT
Pros
bit.ly/1QrGndM
Features and
Editions
bit.ly/1HLZrfG bit.ly/SPO-Service
Limits and
Boundaries
bit.ly/SP10-Limits bit.ly/SP13-Limits bit.ly/28SJAGy bit.ly/SPO-Limits
Guidance for Modifying Pre-Defined Taxonomy bit.ly/17KHAuw
Discontinued Features and Modified Functionality bit.ly/1bhrLKr
111. Links
My Knowledge Management (KM) Resources Click Here
My Enterprise Content Management (ECM) Resources Click Here
My Web Content Management (WCM) Resources Click Here
My SharePoint Resources Click Here
My Records Management Resources (RM) Click Here
Notas del editor
Good Afternoon…
As you know we’ve got about an hour fifteen or so…
We’re going to do some quick getting-to-know each other,
then I’m going to give you a bit of an orientation.
We’ll get into the nuts and bolts,
attempt a live mini-design exercise using some of what we learned,
and finish up hopefully with some extra time for Q&A
SOUND GOOD?
And I have to end on time because…
VERY BRIEFLY about me…
Currently I’m with a really great company in Boston; we’re also in New York and Chicago and are expanding out west and down south
A little while back we were acquired by a larger company, Insight, but we’re still called BlueMetal
Where I had the pleasure of working a lot with Julie over there
I’m just about four years into this role; I’ve had about seven years of consulting under my belt at this point and previously I’ve been in a corporate role as well
Been working with SharePoint for over ten years now
I’m not a developer!
Major focus is on wrestling with all the acronyms that end in ‘m’… DM, ECM, WCM, KM…
Here’s how to ping me; That’s how you’ll find the slides…
But enough about me…
Let’s get into the challenge we face in trying to talk about SharePoint with users
Let’s find out a little about all y’all.
Just so I get an idea who we’re talking to…
Do we have
Developers?
Administrators?
Business people/end users?
Are we all currently using SharePoint in our organizations?
What do you wanna know?
You may have heard SharePoint does this thing called CM—whatever flavor it may be—on prem, online…
Why are we talking about this?
SharePoint tells us that it can handle a LOT of different things—many more not up here on the screen.
Well…
Do you want to turn all this stuff on and hope for the best?
The goal is to create Pleasantville.
But you’re going to end up in the Wild West if you don’t think carefully about some of the stuff we’re going to talk about.
To start off, we’re going to get into these 2 things, find out what they are, and how they relate to each other.
And… the answer is already up there.
We have this term I just threw out there, CONTENT ARCHITECTURE. What is it?
It’s about Content Management
Here, we’re looking at two parts to the whole
1. A specification. What’s that? It’s an outcome
2. Activities and outputs. We’re talking about a process
It’s part of a process which is going to help you achieve your content strategy and will form the foundation for content management
But let’s get to the ‘big’ word for today…
We’re here to talk about taxonomy…
What is this thing called TAXONOMY?
Simply…
OK so we’re going to be categorizing our stuff. Cool.
Even more simply…
In talking about these big concepts—content architecture and taxonomy--What are the common threads here?
What does taxonomy as part of content architecture look like?
It’s structuring
And organizing
How are we going to get there?
We’re grouping things
To be able to classify and categorize
Why do we work with taxonomy?
Again, findability
And usability
CONTENT
It’s also about your USERS.
It’s about half and half. Some people like to follow a map and street signs along the way to get to where they want to go.
Others like to search for their content and expect it to come up pretty high in the result set.
What kind of person are you?
Think about your email. If you’re a filer and have tons of nested folders that you put your emails into, you’re probably an green ‘navigation’ person.
If you’ve got all your emails in your Inbox and anytime you want to find something you type in a keyword or you group and sort by sender, you’re probably a purple ‘search’ person.
You have to consider both approaches in building out your taxonomy.
Once you’ve located some content…
We want some qualitative data about the content to differentiate it from the sea of other documents
The goals, again, are helping users FIND their stuff and USE it effectively.
To recap…
Taxonomy is part of the bigger picture; shouldn’t be examined in a vacuum.
Other parts of your content architecture will include policies, workflows, etc.
Remember that content architecture is the foundation for CM
Taxonomy is the map; the plan; the blueprint in SharePoint
My major point here is:
You must plan ahead if you want to get all the way there
This stuff is not black and white or one-size-fits-all.
I cannot tell you today an exact process to follow that will work for everyone in every case for all content.
And if you approach your users or whoever you’re working with on this stuff with the same solution every time, you’re doing it wrong.
At the same time, working through this stuff should consist of two complimentary objectives.
We saw this in the definition for Content Architecture…
You’re going to embark on the process because you have a desired outcome.
But, your outcome is going to be influenced by undertaking that process.
Going through the process
Helps people ideate
Can remedy bad things that didn’t work out in the past
Especially with SharePoint projects… Sometimes it’s a therapy session
Gets users to feel a sense of ownership; they’re going to help build it—not just be delivered something they didn’t have a part in shaping
At the end of your process
You should end up with documentation
You should also have some things that aren’t written out in sentences, like spreadsheets and charts that help illustrate the plan
These process elements apply way beyond SharePoint, of course
But… we’re at SharePoint Saturday, so we’re going to stick to that.
I’m currently working with a client that is looking at this exact problem.
They’ve gotten their hands on SharePoint online, Office 365, they’ve played around with it a little, and they have a user community that has been starved for attention for years.
They want to let them in and provide some value as soon as possible, in a largely self-service paradigm.
We had a lot of conversation around drawing up a plan for the foundation before they start building the house and setting up the furniture.
You get the keys to SharePoint.
You’re about to send out the email telling everyone the day has arrived and all their problems will be solved.
STOP.
As easy as it looks, as tempting as it may be…
Don’t do it.
SharePoint comes in a box, you open the box, and you can use it right away, but you shouldn’t.
If you don’t go through this process and plan ahead and communicate across all of the participants, stakeholders, sponsors, etc…
I’m going to be throwing a lot of information at you.
Please, not for my own sake… go read this white paper sometime later on.
It’s a few years old now but is very relevant and takes you through these concepts especially one I’m going to be introducing to you around inheritance
OK here we go!
We have ALL these things to build with in SharePoint, and more…
How do we do it right?
Let’s start off with the basics.
We’re going to review what content types and site columns are
We’re going to put them together to be able to track metadata on our content
We’ve going to have our content types and site columns. Together we’re able to associate metadata appropriately with our content.
We’re going to have our sites, libraries, and lists (a.k.a. our containers in SharePoint)
That’s going to get us context, the logical architecture, for our content.
Deciding where to use all of our tools is what will bring our taxonomy to life.
A single session on a SharePoint Saturday is not really a lot of time to properly train up on all this stuff
We’re going to pretend…
SharePoint has two main constructs that we’re going to focus on at the outset: content types and site columns.
This is Microsoft’s definition right off of TechNet of a content type in SharePoint
Big word here: REUSABLE
Pay attention to the words in purple; these are reasons/qualifiers for why you would consider using a content type and for creating different content types
And notice our key term here about categories of items
A content type is not just a tag
Out-of-the-Box Content Types
They’ve always been there behind the scenes; you may not have realized you’ve been using them the whole time since SharePoint 2007
Some things to notice here…
There is a parent-child relationship model here
These things aren’t just one-offs
All things derive from Item (ultimately System)
Some are super special SharePointy things
Let’s take a look at the common OOTB ones that you interact with all the time.
(I simplified some of the relationships here.)
Notice the parent-child relationship.
CLICK A picture is a further developed kind of document
CLICK A document set is actually a kind of folder
Two major branches—item-based and document-based
Where an item is basically a row in a list
SharePoint content is all stored in lists. Libraries are lists. They’re just designed to store document-based content types.
Document-based content types are designed with the primary element being a file.
An item can have a file attached to it.
Item
Contact
Event
Document
Self-explanatory
Folder
A thing that holds documents
Document Set
A super special ‘binder’ but it’s a folder on steroids
Show the default content types
Show enabling content types in library; show Document content type
PLEASE!
Microsoft expects throughout SharePoint that certain OOTB elements are defined the way they designed them, and especially when it comes time to install an update or service pack, you don’t want to have altered these things.
Content Types have a scope in a site structure within a site collection.
Content Types are only visible downward. CLICK
Let’s take a sample site structure and a few example content types.
I could just define these in the topmost site…
But, instead…
CLICK
I’m going to instantiate the things that everyone uses at the top,
CLICK HR
CLICK Compensation
CLICK Marketing
Content Types inherit properties from parents
This is why you might want to consider what I call an abstraction layer
Let me talk about what I call Transactional vs. Abstraction content types
Let’s use this sample list of content types again
This is perfectly valid.
But it doesn’t follow our directive to plan ahead.
This is going to get unwieldy when the list grows to more than a half-dozen content types.
You’ll want to introduce a level of abstraction.
Here I’ve grouped the documents that have to do with human resources under a parent content type of ‘HR Document’
This is your abstraction layer.
I’m never going to USE this content type transactionally, meaning I won’t enable it in a library and assign this content type to a file.
Thinking ahead, I may want to put even more abstractions in place.
What does this get me?
The Ad is just one content type; why abstract it already?
You can’t insert a level in later on.
In fact I always insert one ultimate abstraction point just below Document so I have that place to influence all my custom content types without modifying the out of the box
Keep in mind the reasons I might want to instantiate another content type.
For example, I may want to isolate a workflow.
Let’s say I have this snippet of my content type hierarchy.
Obviously this inherits downward from the OOTB document or form content type…
These are all transactional content types; I will be using these for real documents or forms.
This is certainly a valid model.
What you want to be careful of when inheriting a transactional content type directly from another transactional content type are any deviations downward that you may have to account for.
CLICK
For example, I could set up a workflow for all shipping requests here.
That will apply downward to all 6 other content types
But let’s say I have a different approval process for expedited shipments.
I could set up a workflow on only that content type. CLICK
BUT, do I want BOTH of those to run?
No.
So I have to remove the other one. CLICK
OK… BUT what happens when I update the shipping approval workflow settings and I need to propagate those downward to the 5 other content types that need it? CLICK
Let’s say I have yet another workflow I need to perform on things that are shipped internationally; I need to get some sort of authorization to export out of the country. CLICK
OK… I can set up a workflow here, and another workflow here.
Do I have to remove the other workflow?
Maybe not because both actually need to run; they’re separate processes.
BUT (depending on how I set this up) these may end up being two copies of the same workflow and that’s extra work to set up and maintain
Not the best way to manage that because I have to make changes twice.
What could be a better way of setting up these content types?
I’ve added several abstraction layers here.
I can now define all three of my workflows in only one place, and all the content types that require them will have them and the ones that don’t won’t.
CLICK
I’ve even thought ahead and split up the standard and non-standard request types because perhaps in the future I can foresee a separate workflow being needed for those.
Now this may not be ideally appropriate for OTHER settings like metadata.
I’ve now lost my inheritance between the 2 air freight content types and the inheritance between the 2 ocean freight content types.
You need to figure out what’s best for the business problems that you’re trying to solve and balance that with the setup and maintenance
Changes that you make at a certain level could be overridden
List/Library content type is linked but is just an instance/copy; they’re not one in the same
This could work to your advantage or your demise
Workflows
This is sometimes a good way to not have duplicate copies of the same document if it is needed in different places.
OK; next we’ve got site columns
Again, we’ve got TechNet to tell us the medical explanation
Again, notice the word REUSABLE
OK; next we’ve got site columns
Again, we’ve got TechNet to tell us the medical explanation
Again, notice the word REUSABLE
There are types of columns in SharePoint; they each have their own unique characteristics and field controls—the way the column is rendered in a newitem or edititem .aspx form
So, like content types, site columns have a scope—downward
Therefore the same rules apply
Where you define it affects where you can use it
Like content types, there are instances/copies of site columns in libraries/lists
UNLIKE content types, you can instantiate a column in a library/list, but that’s not a site column and only has relevance to that container only
Required
One of the decisions you often have to make is when to employ one of these types for giving users a selection of things to pick from
Choice
Easy text
Never updated
Lookup
It does update
Can’t use across site collections
Has a scope
If you need to store additional metadata ABOUT the choices
Can help you with things called projected fields
Not all columns will project
With some extra work, you can set up lookup columns to narrow down choices, for example selecting a country and then getting the list of states or provinces for that country only
Scope applies to lookup columns as well and can be used to your advantage.
CLICK
They depend on where the list you are looking up to is located
Once I create a lookup to it, however, all the sites down the tree now have access to the choices in that list
CLICK
Managed Metadata
Got this in SharePoint 2010
Only way OOTB to use a consistent set of terms across site collections—even web applications and farms
These are great for enterprise-wide groups of terms, it supports synonyms…
You can re-use the same term in different hierarchies
It’s a great assist for navigation within SharePoint, which will help you users find your content and filter it out
Gives your users the chance to contribute a social taxonomy, or folksonomy. Not always advisable in all situations but can be very helpful in some.
What’s altered this decision a bit is SharePoint 2013’s managed metadata extended properties…
Used to be no Document Information Panel support
Used to be no Datasheet View support
Show sample MM hierarchy
You want to track data that will actually be of value.
Just because you can set up a column for your document approver’s shoe size doesn’t mean it’s relevant. You can have too many columns and it will be laborious for users to adopt the practice of providing that data to the system.
If your data has a low likelihood of ever being populated, perhaps because it’s not required, it can lead to bad data and the items that did have the field filled in become less valuable because it wasn’t done consistently.
This is a balancing act.
SharePoint’s going to refer to your column differently depending on how you’re referencing/accessing it
Programmatically
UI
Central Admin - Search
Show column properties
What is METADATA?
Simply…
You’re already using it and may not realize it.
Outlook
iTunes
From your Camera…
In SharePoint…
At the very least:
Created
Created By
Modified
Modified By
And an item always has Title
A document also has a name, which is the filename
We ASSOCIATE the site columns WITH the content types to get metadata
How do we decide where to set up the columns in our hierarchy?
For example…
The same goes for other settings on these content types, by the way.
Remember that we can isolate workflows, for example. We could set a retention policy. The same consideration applies to these.
I want to discuss how the components and concepts we’ve talked about so far progress and feed into your taxonomy.
We’ve got our content types and site columns. Together we’re able to associate metadata appropriately with our content.
Nothing happens with these until we instantiate these in particular containers within SharePoint.
Deciding where to do this with what building blocks is what brings your taxonomy to life.
Why do we care about all of this stuff?
Content Types, Site Columns, Metadata
Our content types and our site columns are building blocks that can be used/instantiated in different places to effect different results and support our goals of finding content and making it usable within SharePoint
Our content types and our site columns are building blocks that can be used/instantiated in different places to effect different results and support our goals of finding content and making it usable within SharePoint
SharePoint gives us several layers to work with from the farm all the way down to individual items.
It’s important to understand what can be configured where and the scope of those decisions.
Line of demarcation
Who is using or thinking of using SharePoint Online/Office 365?
On-Premise vs. the cloud
So in understanding your taxonomy and how it’s going to work and support your business processes, manage your content, comply with your security requirements… you need to understand the holistic view of how all of these things will work together in SharePoint.
To make it very basic…
Work your way up the layers
Again, there’s that line of demarcation.
OOTB we’re given several very different site templates.
OOTB we’re give several different library templates.
OOTB we’re given several different list templates.
These will all accelerate you getting started.
A few words about Content Type Publishing and the Content Type Hub…
This allows you to trump that line of demarcation we just saw, with your content types, and have consistent definitions and settings across site collections, web applications, and even farms.
It is incredibly important to consider and plan out the organization of the content that you’re going to manage.
SharePoint has certain constructs built-in to set you up properly for being able to employ many of its features.
Things are always changing rapidly lately…
Is anyone currently dealing with a hybrid setup or thinking about it?
I want you to understand not only what taxonomy is but that it’s part of a bigger idea.
I want you to understand the tactics for working with your taxonomy.
I want you to understand why it’s important to create these reusable elements in SharePoint in order to support your taxonomy.
I want you to understand the goals for working with your taxonomy.
I want you to think about this stuff BEFORE you let your first user into your site.
Governance can be a whole week’s worth of other sessions and discussion. I encourage you to do a lot of research or call us for help ;-)