Metadata & Organisation

Metadata columns are how SharePoint knows what each file is. Get them right and your library stops being a folder graveyard and starts being a working system.

A metadata column is a piece of structured information you attach to every file in a library — Department, Document Type, Status, Owner, Project. Instead of relying on folder paths or filenames to tell you what a file is, you tell SharePoint directly. Once columns exist, you can filter by them, sort by them, group by them, build views around them, and trigger workflows from them. Copilot can read them too.

Most SharePoint libraries are still set up the way shared drives were: a single ‘Documents’ library with no metadata, just nested folders. This works at small scale (under maybe 200 files) and falls apart fast above that. Without metadata, finding files means clicking through folder trees and hoping. With metadata, finding files means filtering — and that scales to thousands of files without breaking.

Adding a column is a small action with big downstream effects. Every column you add becomes a question SharePoint can answer about your content. Three good columns are usually enough to transform a chaotic library into a navigable one. The hard part isn’t creating the columns — it’s choosing which ones matter most for the way your team actually works.

Why this matters

Metadata columns aren’t just nice-to-have organisation. They’re the structural layer that makes SharePoint scale, supports Copilot, and keeps your team finding what they need:

Columns make filtering possible. ‘Show me all approved policies for Finance’ is a one-click filter when you have Status, Document Type, and Department columns. Without them, it’s an hour of scrolling.

Columns make Copilot accurate. Copilot reads metadata to understand context. A file tagged ‘Document Type: Policy, Status: Approved, Department: HR’ is far more findable than a file with no tags.

Columns force clarity. Adding a ‘Document Type’ column means deciding what types you actually have. That conversation alone is often more valuable than the column.

When you’ll use this

• When you’re setting up a new library and want it to work properly from day one.
• When an existing library has grown beyond what folders can manage.
• When you can’t find files easily and you’re tempted to create more folders to fix it.
• When you’re preparing a library for Copilot and need structured tags it can read.

How to do it

1. Open the SharePoint library where you want to add metadata.
2. Click + Add column in the column header row.
3. Choose the column type (see M-02 for how to pick the right type).
4. Name your column clearly — use plain English (e.g. ‘Department’, not ‘Dept’ or ‘D’).
5. Add a description explaining what the column is for and how to fill it in.
6. Decide if it should be required — if a file can’t function without this tag, make it required.
7. Save. The column appears in your default view immediately.
8. Tag existing files in bulk using Quick Edit / Grid View (see M-44).

Best practices

• Start with three columns: Document Type, Status, Owner. Add more only when the team agrees they’re needed.
• Use plain English names. ‘Department’ beats ‘Dept’. ‘Document Type’ beats ‘DocType’. Search engines (and humans) prefer real words.
• Always fill in the Description field. What does this column mean? When should it be filled in? A 1-line description prevents 100 misuses.
• Make critical columns required. If you can’t function without it, the system shouldn’t let people skip it.

Common mistakes

• Adding 15 columns at once. Users won’t tag any of them properly. Start with 3, prove they work, add more later.
• Naming columns with abbreviations. ‘Dept’ is faster to type but harder to search and harder to understand. Plain English wins.
• Skipping descriptions. Six months later, nobody remembers what the column was for. Two minutes of writing prevents months of confusion.

↑ Back to top ↑ Back to list

Picking the wrong column type means your data won’t filter, sort, or report properly. Picking the right type makes every other thing work.

When you create a column, SharePoint asks what type of data it holds: text, choice, date, person, number, yes/no, hyperlink, lookup, managed metadata, calculated. Each type behaves differently — different inputs, different validation, different sort/filter behaviour, different storage. Choose the wrong type and your column is harder to use, less reliable, and less useful in views and workflows.

The most common mistake is using Single Line of Text for everything. It works in the short term — users can type whatever they want — but the cost shows up later. Filters break because half the team typed ‘HR’ and half typed ‘Human Resources’. Sorting is alphabetical instead of meaningful. There’s no validation, so typos accumulate. And reports built on top of text columns are unreliable forever.

The better approach is to ask: what is this data, really? If it’s a fixed list of options, use Choice or Managed Metadata. If it’s a person, use Person. If it’s a date, use Date. If it’s a yes/no, use Yes/No. Match the type to the data, and SharePoint does the heavy lifting for you.

Why this matters

Column type isn’t just a technical setting — it’s the difference between data you can trust and data that’s forever a bit off:

Structured columns enforce consistency. A Choice column with 5 options means everyone tags from the same list. A text column means everyone types something slightly different.

Structured columns power filtering and views. ‘Show me everything where Status = Approved’ is a clean filter on a Choice column. On a text column, it’s ‘where Status contains approved or Approved or APPROVED or aproved…’

Copilot understands structure. A Person column tells Copilot ‘this is a real human in your tenant’. A text column with someone’s name is just a string of characters.

When you’ll use this

• When you’re about to create a column and choosing what type to use.
• When an existing column isn’t behaving the way you expected.
• When filters and views aren’t returning what they should.
• When you’re auditing a library and finding inconsistent data.

How to do it

1. Identify the data: is it finite (list of options) or open-ended?
2. If finite and local to one library: use Choice.
3. If finite and used across multiple sites: use Managed Metadata (see M-13).
4. If it’s a person: use Person.
5. If it’s a date: use Date and time (Date only if time doesn’t matter).
6. If it’s a yes/no: use Yes/No.
7. If it’s a number with units: use Number or Currency.
8. If you genuinely need free text (like a description): use Single Line or Multiple Lines of Text — but accept that you can’t filter cleanly on it.

Best practices

• Default to structured types. Choice, Date, Person, Yes/No before Text. Always.
• Use Person for ownership and assignment. ‘Owner’ as a Person column gives you ‘Me’ filters and automated notifications for free.
• Reserve Text for genuinely unstructured content. Notes, descriptions, summaries — not categories.
• Don’t change types after the fact. Changing a column type usually loses data. Plan once, build once.

Common mistakes

• Using Text for everything. Easy now, painful forever. Half your team will type slightly differently and your filters will be unreliable.
• Using Lookup when Managed Metadata is the right answer. Lookup only works within a single site. Managed Metadata works across the whole tenant.
• Building calculated columns on text. Fragile, error-prone, hard to maintain.

↑ Back to top ↑ Back to list

A Choice column gives users a fixed list to pick from. It’s the workhorse of clean SharePoint metadata — fast, consistent, and easy to filter.

A Choice column lets you define a fixed set of options (Draft, In Review, Approved, Archived) and forces users to pick from that list rather than typing whatever they want. The result is consistent data: every file tagged with one of the same five options, no typos, no variations, ready to filter and sort cleanly.

Choice columns are perfect when you have a small, stable list of categories specific to one library or site. Document Status, Approval Stage, Priority Level, Phase — all natural Choice columns. They’re not the right tool when the list is shared across the tenant (use Managed Metadata) or when items are people (use Person), but for local categorisation they’re hard to beat.

The setup conversation matters as much as the technical choice. Before adding a Choice column, ask: what are the actual options? Get the team to agree on the list. Six options is a sensible upper limit for most use cases — if you have twelve, you probably have two columns hiding in one. If you have three, you probably have a Yes/No.

When you’ll use this

• When you have a fixed list of options for one library or site.
• For Status, Document Type (within one library), Priority, Phase, Approval Stage.
• When you want users to pick from options rather than typing freely.
• When you want filterable, reportable categories without setting up the term store.

How to do it

1. Open the library and click + Add column.
2. Select Choice.
3. Type your options, one per line.
4. Choose display: drop-down (most common), radio buttons, or checkboxes (for multi-select).
5. Set a default value if it makes sense (e.g. ‘Draft’ for a Status column).
6. Decide whether to allow ‘fill-in’ values — usually no, because it defeats the consistency.
7. Save and apply colour formatting if you want visual cues in views (see M-44).

Best practices

• Keep the list short. 5-8 options is the sweet spot. More than 10 and users start ignoring the column.
• Use a sensible default. ‘Draft’ for Status, ‘Internal’ for Sensitivity. Saves a click for the most common case.
• Apply colour formatting for visual scanning. Red for ‘Blocked’, green for ‘Approved’. Makes views immediately readable.
• Don’t allow fill-in values unless you must. The whole point of Choice is consistency.

Common mistakes

• Long lists of options. If you have 20 choices, you probably need a hierarchy (Managed Metadata) or two columns.
• Allowing fill-ins without a plan. Users add inconsistent values that pollute your reports.
• Using Choice across many libraries. If the same list is used in 5 libraries, use Managed Metadata so it stays in sync.

↑ Back to top ↑ Back to list

Sometimes you need a free-text field — a name, a reference number, a short label. Use Single Line of Text deliberately, not as a default.

A Single Line of Text column lets users type whatever they want, up to a defined character limit. It’s the most flexible column type — and the most dangerous. Flexibility is the enemy of consistency, and Single Line of Text columns are where consistency goes to die. Five users will type the same thing five different ways, and your filters will never quite work the same way twice.

There are legitimate uses. Unique reference numbers (an invoice ID, a contract number) genuinely need to be free-text and unique. Short descriptive labels (a project codename) can work. But for anything that should be a category — department, document type, status — Single Line of Text is almost always the wrong choice.

The tell-tale sign you should have used a different column type: you find yourself filtering with ‘contains’ instead of ‘equals’, or your reports show ‘HR’ and ‘Human Resources’ as separate values, or you’re cleaning up the data manually every quarter. That’s a Choice or Managed Metadata column wearing a Text disguise.

When you’ll use this

• When you need a unique identifier (invoice ID, reference number, customer code).
• When you need a short, free-form label that genuinely varies.
• When you need a brief subtitle or note that doesn’t fit any other column type.
• Never for categories — use Choice or Managed Metadata instead.

How to do it

1. Open the library and click + Add column.
2. Select Single line of text.
3. Set a maximum length if you want to prevent novels.
4. Decide if values should be required.
5. Enable Enforce unique values if it’s an ID field that must be unique.
6. Add a description with examples of acceptable values.
7. Save and test with a couple of files.

Best practices

• Use only when the data is genuinely unstructured. Categories belong in Choice, not Text.
• Enforce unique values for IDs. Prevents accidental duplicates from breaking downstream processes.
• Set a max length. Stops people pasting paragraphs into a label field.
• Add format guidance to the description. ‘Enter the invoice number in format INV-XXXX’ helps users tag consistently.

Common mistakes

• Using Text for departments, statuses, document types. The most common metadata mistake. Choice or Managed Metadata is the answer.
• No validation, no max length, no description. Users will type anything, and the column becomes useless.
• Trying to filter cleanly on text. ‘Contains’ filters are unreliable. Use structured types when filtering matters.

↑ Back to top ↑ Back to list

When you need somewhere to capture longer notes — a summary, a description, history — use Multiple Lines of Text. Just don’t try to filter on it.

Multiple Lines of Text columns hold larger blocks of free-form content: paragraphs of notes, summaries, comments, history, descriptions. They support plain text or rich text (with formatting), and can be configured to append entries (so old entries are preserved when new ones are added) for an audit-style change log.

These are reading columns, not filtering columns. Users add information to them; readers absorb that information; reports rarely use them. That’s fine — sometimes you genuinely need a place for narrative content. The mistake is treating them like searchable categories. They’re not. SharePoint can search inside them via full-text search, but you can’t filter cleanly the way you can with Choice or Managed Metadata.

The ‘Append Changes’ option is the hidden superpower. If you turn it on, every time someone edits the column, their entry is added to a running log with their name and the date. Useful for change history, comment threads, and any field where you want a record of who said what.

When you’ll use this

• When you need a description, summary, or longer notes field.
• When you want a running log of comments or changes (with Append Changes enabled).
• When the field genuinely holds narrative content that doesn’t fit any structured type.
• Almost never as the primary filter for views — it’s for reading, not categorising.

How to do it

1. Click + Add column → Multiple lines of text.
2. Choose plain text, rich text, or enhanced rich text (rich is best for most descriptions).
3. Decide if you want to append changes (preserves history with each edit).
4. Set the number of lines to display in forms.
5. Add a description explaining what should go here.
6. Save and use it for narrative content, not categories.

Best practices

• Enable Append Changes for change logs. Each edit becomes a timestamped entry. Powerful for audit.
• Keep entries focused. Long entries are harder to read. Aim for paragraphs, not essays.
• Use Plain Text unless you need formatting. Rich text is more flexible but creates inconsistent appearance.
• Use sparingly. One Multiple Lines column per library is usually enough.

Common mistakes

• Using it as a category replacement. Filtering ‘contains HR’ is brittle. Use Choice instead.
• Letting it become a dumping ground. If users put everything in ‘Notes’, nothing is findable.
• Forgetting Append Changes when you’d benefit from it. Without it, every edit overwrites the previous entry.

↑ Back to top ↑ Back to list

Person columns connect SharePoint to your real Microsoft 365 directory. Use them for ownership, accountability, and automation.

A Person column lets users pick from your organisation’s directory — real Microsoft 365 accounts, with profile photos, hover cards, and live presence. Instead of typing ‘sarah.smith@example.com’ as text, you select Sarah Smith from a picker and SharePoint stores the connection to her real account. This unlocks a host of capabilities that text columns simply can’t provide.

The most powerful uses of Person columns are around ownership and assignment. A ‘Document Owner’ Person column means you can build a ‘My Documents’ view with a single filter: where Owner equals [Me]. The same filter works for every person in the organisation. You can build automated reminders that email the document owner before a review date. You can audit which owners have left the organisation and need their content reassigned.

Person columns also give you proper attribution. When Sarah leaves the team, her name doesn’t just sit in a text column — SharePoint knows she’s the assigned owner of these specific files, and you can systematically reassign them. Without Person columns, that exercise is much harder and much more manual.

When you’ll use this

• For Document Owner, Reviewer, Approver, Project Lead, Client Contact.
• When you want to filter views by ‘Me’ (e.g. ‘show only my documents’).
• When you want to send automated reminders to the right person.
• When ownership matters and needs to follow people through role and name changes.

How to do it

1. Click + Add column → Person or Group.
2. Choose ‘People only’ (most common) or ‘People and Groups’.
3. Decide if multiple selections are allowed (usually no — one owner per file).
4. Optionally limit to a specific Microsoft 365 group (e.g. only members of the HR Owners group can be selected).
5. Save and assign people to existing files.
6. Build a view filtered by [Me] for personalised experiences.
7. Use the column in Power Automate flows for automated notifications.

Best practices

• Use Person for ownership, never text. Connection to the real account is the whole point.
• Default to single-person ownership. ‘One throat to choke’ beats ‘shared accountability’ for most purposes.
• Build [Me] views for every Person column. Lets users see what’s theirs in one click.
• Pair with Date columns. ‘Documents I own due in the next 30 days’ is the killer combination.

Common mistakes

• Using text instead of Person. Loses everything: filtering, notifications, hover cards, automated reminders.
• Allowing multiple people without a clear primary. Diffuses responsibility. Pick one main owner.
• Not auditing for departed staff. When Sarah leaves, do her files become orphaned? Plan for it.

↑ Back to top ↑ Back to list

Dates are how SharePoint understands time. Use Date columns for review dates, expiry, deadlines, and milestones — and your library starts running on rails.

A Date column captures a date (and optionally a time) in a structured format. Unlike text, dates can be sorted chronologically, filtered by ranges (‘this month’, ‘next 30 days’), used in calculated columns (e.g. ‘expiry = created date + 365’), and consumed by Power Automate for time-based triggers (send a reminder 7 days before the date).

The classic uses are Review Date and Expiry Date. Every document with a review date can power a ‘documents due for review next month’ view, or trigger automated emails to owners. Add Created and Modified to that and your library has a full time-based dimension that powers reporting, governance, and alerts without manual intervention.

The decision between Date Only and Date and Time depends on whether the time of day matters. For most business uses (reviews, deadlines, expiries), Date Only is fine — and saves users the irritation of typing 12:00 AM into every entry. Reserve Date and Time for events that genuinely have a specific hour (meetings, scheduled publishes, time-bound approvals).

When you’ll use this

• For Review Date, Expiry Date, Effective From, Effective To, Created Date.
• For Project Start, Project End, Milestone dates.
• For Due Date, Submission Deadline, Approval Deadline.
• Any time you need to filter by time ranges or trigger reminders.

How to do it

1. Click + Add column → Date and time.
2. Choose Date Only (most common) or Date and Time.
3. Set a default value if useful — ‘Today’s date’ is common for Created columns.
4. Make required if files need a date to function (e.g. all policies must have a Review Date).
5. Save and apply conditional formatting for overdue items.
6. Build views filtered by date ranges (this week, this month, next 30 days).
7. Set up Power Automate reminders if dates drive action.

Best practices

• Use ISO date format wherever you can. YYYY-MM-DD sorts correctly without ambiguity.
• Pair Date with Person. ‘Documents I own that expire in the next 30 days’ is gold.
• Apply conditional formatting for overdue. Red text on dates in the past makes problems visible.
• Set defaults sparingly. ‘Today’ as a default for a Review Date is wrong — make users think.

Common mistakes

• Storing dates as text. Breaks sorting, breaks filtering, breaks reminders. Always use Date columns.
• Date and Time when Date Only would do. Forces users to enter times that don’t matter.
• No conditional formatting for overdue. Overdue items disappear into the noise.

↑ Back to top ↑ Back to list

When the question has only two answers, Yes/No is the column. Fast to fill in, easy to filter, perfect for triggers and checklists.

A Yes/No column is a single checkbox: true or false, yes or no. It’s the simplest column type, and that’s its strength — fast for users to fill in, perfectly clean to filter on, and trivial for automation to react to.

Yes/No columns are everywhere in well-designed libraries. Confidential? Approved? Reviewed? Audit complete? External access allowed? Personal data? GDPR review needed? Each is a yes/no question that, in aggregate, gives you a clean structural picture of your content. Multiple Yes/No columns combined make excellent simple checklists.

The unsung use of Yes/No columns is in Power Automate triggers. ‘When Confidential changes from No to Yes, move the file to a secured library and notify Compliance.’ That’s a clean automation that wouldn’t work nearly as well with a Choice column or a text field. Yes/No is unambiguous for both humans and code.

When you’ll use this

• For Confidential, Approved, Reviewed, Audit Complete, Compliance Reviewed.
• For external sharing flags, GDPR markers, sensitive content indicators.
• For checklists where each step is a separate Yes/No.
• Whenever the answer is genuinely binary.

How to do it

1. Click + Add column → Yes/No.
2. Set a default value (usually No — Yes makes everything look approved by default).
3. Add a clear description explaining what the question is.
4. Add to default view if you want it visible.
5. Use in filters: ‘where Confidential is Yes’.
6. Use in Power Automate to trigger actions when value changes.

Best practices

• Use Yes/No for genuinely binary states. If there’s a third option (Maybe, In Progress), use Choice instead.
• Default to No. Approved-by-default is dangerous. Confidential-by-default is paranoid. Pick the safe default.
• Make labels clear. ‘Confidential’ is clear. ‘Status’ as a Yes/No is not.
• Combine multiple for simple checklists. Five Yes/No columns can replace a complex form.

Common mistakes

• Using Yes/No for three-state data. If your column needs Yes, No, and Pending, you need a Choice column.
• Approved-by-default. Confused users tick a box without thinking, and content is suddenly ‘approved’. Default to No.
• Vague labels. ‘Reviewed’ — by whom? When? For what? Be specific in the description.

↑ Back to top ↑ Back to list

Numbers are for counting, calculating, and aggregating. Use Number columns for anything you might want to sum, average, or do maths on.

A Number column stores numeric values — integers, decimals, percentages — and prevents users from accidentally entering letters or symbols that would break calculations. The big advantage over text is mathematics: you can sum, average, calculate min/max, and aggregate cleanly across views.

Common uses include quantities (how many?), scores (out of 10), priority levels (1-5), percentages (completion %, satisfaction score), and ratings. Where Currency is more appropriate (financial values with a symbol), use that instead — but for everything else numeric, Number is the clean choice.

The ‘Show as percentage’ option is a quiet timesaver. Enter 0.75 and SharePoint shows 75%. Enter 1.0 and it shows 100%. Saves users from typing the % symbol every time and keeps the underlying data clean as a decimal — perfect for calculations and reports.

When you’ll use this

• For quantities, counts, scores, ratings, percentages.
• For priority levels, severity scores, complexity ratings.
• Whenever you might want to sum or average across a view.
• Not for currency — use Currency column for financial values.

How to do it

1. Click + Add column → Number.
2. Set decimal places (0 for counts, 2 for percentages).
3. Optionally set min/max values to prevent invalid entries.
4. Choose ‘Show as percentage’ if appropriate.
5. Save and enable Totals in your view (sum, average, max, min).
6. Use in calculated columns for derived values.

Best practices

• Use Number for anything mathematical. Even a count column should be Number, not text.
• Set min/max constraints. Prevents typos like ‘12345’ instead of ‘5’.
• Use percentage display where it fits. Cleaner than asking users to type %.
• Enable Totals in views. Free reporting at the bottom of every column.

Common mistakes

• Storing numbers as text. Breaks sorting (10 sorts before 2), breaks calculations, breaks averages.
• Too many decimal places. ‘Project complete: 73.4521%’ is false precision. Round to 1 or 2 decimals.
• No min/max validation. Users will type 100 instead of 1 and break your reports.

↑ Back to top ↑ Back to list

When the data is money, use a Currency column. It handles symbols, decimals, and totals correctly — and prevents the embarrassing ‘is that dollars or pounds?’ moment.

A Currency column is a specialised Number column for financial data. It enforces a fixed number of decimal places (usually 2), shows a currency symbol (configurable per column or per organisation), and behaves correctly for sums, averages, and reporting. Where a Number column would store 1500, a Currency column shows $1,500.00 — making the value instantly readable.

Currency columns are essential for invoice trackers, project budget logs, expense registers, contract value libraries, and any list where money matters. The format is consistent across all entries (no users typing ‘$’ before some values and not others), the decimal handling is correct (no rounding errors), and the totals at the bottom of views are immediately useful.

For multi-currency organisations, the picture gets more complex — SharePoint Currency columns are single-currency by default. If your organisation deals in multiple currencies, you’ll typically have a separate column for the currency code (USD, GBP, EUR) and use the Currency column purely for the numeric value, formatted as your default currency. For more sophisticated multi-currency handling, Lists or a dedicated finance system is usually a better fit.

When you’ll use this

• For invoices, budgets, expenses, contract values, fees, costs.
• Anywhere you need money values displayed cleanly.
• When totals or averages of money matter (budget tracking, expense reporting).
• Not for percentages or non-financial numbers.

How to do it

1. Click + Add column → Currency.
2. Choose the currency format (e.g. $ for USD, £ for GBP).
3. Set decimal places (almost always 2).
4. Decide if it’s required.
5. Save and enable Totals in views to see sums.
6. For multi-currency orgs, add a separate Choice column for currency code.

Best practices

• Match the format to your local currency. Don’t display USD if everything is in AUD.
• Enable Totals at view level. Sum at the bottom of the column for instant budget visibility.
• Pair with a Date column for time-bound reports. ‘Total spend this quarter’ is a one-click view.
• For multi-currency, add a separate currency code column. Don’t try to mix currencies in one Currency field.

Common mistakes

• Storing money in a Text or Number column. Loses formatting, complicates reporting.
• Mixed-currency in one column. $1000 and £1000 are not the same. Separate the value from the currency code.
• Wrong decimal places. Three decimals on currency is unusual. Stick with 2 unless you have a real reason.

↑ Back to top ↑ Back to list

Sometimes a column needs to point at a URL — a related website, a reference document, or display an image. Hyperlink/Picture columns handle both.

A Hyperlink column stores a URL plus a display name. Users see the friendly text (‘Project SharePoint Site’ or ‘ISO 9001 Standard’) and clicking takes them to the underlying URL. A Picture column stores an image URL and renders the image directly in the view — useful for product galleries, asset catalogues, or anywhere visual identification helps.

Hyperlink columns are great for external references: a related Confluence page, a regulator’s site, a training video on Stream, a Microsoft Learn article. They’re also useful for cross-library navigation — a ‘Related project site’ link on every project document, for example.

Picture columns are less common but powerful where they fit. A products library can show actual product images. A people register can show photos. An assets register can show equipment photos. The visual reinforcement makes browsing much faster than reading filenames.

When you’ll use this

• For links to external regulations, training, reference websites.
• For cross-library navigation (related sites, related libraries).
• For product, asset, or people registers where images aid identification.
• Anywhere a URL or image is genuinely part of the file’s metadata.

How to do it

1. Click + Add column → Hyperlink or Picture.
2. Choose Hyperlink (URL with display text) or Picture (image rendered in views).
3. Save the column.
4. On each item, enter the URL plus a friendly display name (or image URL).
5. For tile views, Picture columns make excellent visual identifiers.

Best practices

• Use display names, not raw URLs. ‘ISO 27001 Standard’ is more readable than ‘https://www.iso.org/standard/…’.
• Verify URLs periodically. External links rot. Set up a quarterly check.
• Picture columns work best in Tile View. Lists with pictures look better with tiles than with rows.
• Don’t use for primary linking — use built-in Sharing instead. Hyperlink columns aren’t replacements for SharePoint links.

Common mistakes

• Storing internal SharePoint links in Hyperlink columns. Use Lookup or built-in linking — Hyperlink is for external URLs.
• Display names that don’t match the URL. Confuses users when the link goes somewhere different from what’s labelled.
• Picture URLs that break. If the source image moves, the column shows a broken image. Test stability.

↑ Back to top ↑ Back to list

Lookup columns connect lists together — pick a value from another list rather than typing it. Maintain data once, use it everywhere.

A Lookup column lets users pick a value from another SharePoint list (within the same site). For example, you might have a master ‘Clients’ list with 200 client records, and a ‘Projects’ library where each project has a ‘Client’ column that’s a Lookup pointing at that Clients list. Users pick the client from a dropdown; SharePoint stores the connection. Update a client’s name in the master list, and every project that references it shows the updated name automatically.

Lookups are the right tool when you have shared reference data within a site — Clients, Projects, Departments, Categories — and you want one canonical source of truth. Without lookups, that data ends up duplicated across libraries with all the inconsistencies that come with manual entry.

The big constraint is that Lookups only work within the same site. If your reference data needs to be used across multiple sites, you need Managed Metadata instead (see M-13). For most use cases inside a single site, Lookups are simpler to set up and easier to maintain than Managed Metadata.

When you’ll use this

• When you have a master list of reference data (Clients, Projects, Codes, Categories) used in multiple libraries on the same site.
• When you want users to pick from a list rather than type freely.
• When you need centralised maintenance — update once, reflect everywhere.
• Not when the reference data is shared across multiple sites — use Managed Metadata for that.

How to do it

1. Create the master list first (e.g. a ‘Clients’ list with name, contact, etc.).
2. Open the library where you want the Lookup column.
3. Click + Add column → Lookup.
4. Choose the source list and the column to display.
5. Optionally include extra columns for richer data (e.g. show client name and contact email).
6. Decide if multiple values are allowed.
7. Save and start tagging items.

Best practices

• Use one master list per concept. One ‘Clients’ list, referenced by every library that needs clients.
• Enable Cascading Deletes carefully. Protects integrity but can have surprising side effects.
• Show extra columns for context. ‘Acme Corp (Sarah Smith)’ beats just ‘Acme Corp’ when there are similar names.
• Plan for cross-site needs. If reference data will eventually be needed in other sites, start with Managed Metadata instead.

Common mistakes

• Recreating the same master list in multiple sites. Defeats the purpose. Use Managed Metadata for cross-site lookups.
• Leaving the master list ungoverned. If anyone can edit it, the data quality drops fast.
• Using Lookup for stable global reference data. Departments, locations, document types belong in Managed Metadata.

↑ Back to top ↑ Back to list

Managed Metadata is your tenant-wide vocabulary. Use it when terms must be consistent across every site, library, and team in the organisation.

Managed Metadata columns connect to the Term Store — a centrally-managed taxonomy maintained by your SharePoint admins. Departments, document types, locations, product lines, project codes — anything that should mean the same thing across the entire organisation lives in the Term Store, and any library can have a Managed Metadata column that pulls from it.

The advantage over Choice columns is enormous when you operate at scale. With Choice, every library has its own list of departments — and every list drifts. Some libraries say ‘HR’; others say ‘Human Resources’. Reports across libraries become impossible. With Managed Metadata, every library uses the same source. Update the term in one place and every library that references it updates automatically.

The Term Store also supports synonyms (typing ‘HR’ tags as ‘Human Resources’), translations (different languages), and hierarchies (parent-child relationships, e.g. ‘Australia’ under ‘APAC’). For any organisation managing content at scale, Managed Metadata is the foundation of consistent classification — and the foundation of accurate Copilot search.

When you’ll use this

• For tenant-wide terms: Departments, Document Types, Locations, Product Lines.
• When the same vocabulary needs to appear in many sites and libraries.
• When you want central governance of categories — not library owners inventing their own.
• When you’re preparing for Copilot and need consistent, structured tags.

How to do it

1. Have your admin set up the term group and term set in the Term Store first (see M-14).
2. In your library, click + Add column → Managed Metadata.
3. Select the relevant term set.
4. Decide: multiple values allowed? Display the entire path? Allow fill-in?
5. Save and start tagging files.
6. Users get type-ahead suggestions from the term set.

Best practices

• Reserve Managed Metadata for genuinely tenant-wide terms. Don’t put every list in the Term Store.
• Plan governance before rolling out. Who owns each term set? Who can add new terms? Document this.
• Use synonyms for natural language. If everyone says ‘HR’ but the official term is ‘Human Resources’, a synonym lets both work.
• Combine with Choice columns where appropriate. Tenant-wide terms = Managed Metadata. Library-specific lists = Choice.

Common mistakes

• Putting everything in the Term Store. Some lists belong locally as Choice columns. Don’t over-centralise.
• No governance. If anyone can add terms, the taxonomy drifts and quality crumbles.
• Allowing fill-in values without a plan. Defeats the consistency purpose. Use sparingly with monitoring.

↑ Back to top ↑ Back to list

The Term Store is the central brain of your tenant’s metadata. Get it right and your whole organisation works from a shared vocabulary. Get it wrong and you have multiple competing taxonomies.

The Term Store is a centrally-managed location in the SharePoint Admin Center where official organisational vocabularies live. It’s where your departments, locations, document types, and other shared terms are defined — once — and then made available to every library that wants to use them via Managed Metadata columns.

Inside the Term Store you have Term Groups (top-level containers, often by domain — ‘Corporate’, ‘Operations’, ‘Compliance’), Term Sets (lists of terms within a group — ‘Departments’, ‘Locations’), and Terms (the actual values — ‘Human Resources’, ‘Marketing’, ‘Finance’). Terms can have children, synonyms, descriptions, and translations.

The Term Store is admin-territory, not user territory. Most users never see it — they just see the dropdown lists in their Managed Metadata columns. But the design choices made in the Term Store shape every classification across the tenant. A well-designed Term Store makes the rest of SharePoint sing. A poorly-designed one creates years of friction.

When you’ll use this

• When your organisation needs shared vocabularies across many sites.
• When you’re consolidating multiple competing department/location/type lists.
• When you’re preparing the foundation for Copilot rollout.
• Almost always for any organisation above ~100 users — the cost of not having it grows with scale.

How to do it

1. Open the SharePoint Admin Center.
2. Navigate to More features → Term store.
3. Create or select a term group (organising container, e.g. ‘Corporate Vocabularies’).
4. Add term sets within the group (e.g. ‘Departments’, ‘Locations’).
5. Add terms within each set (the actual values).
6. Set governance: who owns each term set? Who can add new terms?
7. Make terms ‘available for tagging’ so libraries can use them.

Best practices

• Assign Term Store Administrators. Limit who can edit global terms. Most users should not.
• Use hierarchies thoughtfully. ‘Australia’ under ‘APAC’ under ‘Region’ creates useful structure — but don’t overdo nesting.
• Document the governance for each term set. Who owns it? How often is it reviewed? What’s the change process?
• Don’t put everything in the Term Store. Library-local lists should stay as Choice columns. Only true cross-tenant vocabularies belong here.

Common mistakes

• No governance — anyone can add terms. The taxonomy quickly drifts and quality crashes.
• Trying to model everything in the Term Store from day one. Start small. Add as you understand needs.
• Treating the Term Store as a database. It’s a vocabulary system, not a relational database. Don’t try to make it both.

↑ Back to top ↑ Back to list

Most term additions are one or two at a time, added manually as the organisation evolves. Knowing the manual flow keeps your Term Store healthy.

Terms are added to the Term Store one at a time through the SharePoint Admin Center. You navigate to the relevant term set, click ‘Add term’, type the name, optionally add a description, synonyms, and translations, and save. The term becomes immediately available to any Managed Metadata column that references that set.

Manual addition is the right approach for small, ongoing changes — a new department, a new product line, a renamed location. It’s not the right approach when you’re loading hundreds of terms (use the bulk CSV import for that — see M-16). For day-to-day evolution of the taxonomy, manual is fine and gives you the chance to think about each term as you add it.

What separates good term management from bad is the discipline around it. Every term added should have a description (so users understand when to use it), synonyms (so users can search by common abbreviations), and a clear placement in the hierarchy if one exists. Adding a term named ‘HR’ with no description is a future support ticket waiting to happen.

When you’ll use this

• When new departments, locations, or categories are introduced.
• When small changes are needed to the existing taxonomy.
• When you’re refining an existing term set with synonyms or descriptions.
• Not for bulk imports — use M-16 for that.

How to do it

1. Open the SharePoint Admin Center → Term store.
2. Find your term set.
3. Click Add term.
4. Type the term name (the official, canonical version).
5. Add a description so users know when to use it.
6. Add synonyms (common abbreviations, alternative names).
7. Add translations if you operate in multiple languages.
8. Mark the term as ‘Available for tagging’ so libraries can use it.
9. Save.

Best practices

• Always write a description. ‘When to use this term’ is a 1-line answer that prevents 100 misuses.
• Use synonyms for common variations. ‘HR’ as a synonym for ‘Human Resources’ lets users find the right term whichever they search for.
• Keep names canonical and consistent. ‘Marketing’ or ‘Marketing & Communications’ — pick one and stick with it.
• Mark Available for Tagging. Forgetting this step means the term exists but can’t be used yet.

Common mistakes

• No description. Future users won’t know if this term applies to their situation.
• No synonyms. Users search ‘HR’ and don’t find ‘Human Resources’. Add the synonym.
• Adding terms without governance. Anyone with permission adds anything they want — taxonomy drifts.

↑ Back to top ↑ Back to list

When you need to populate a term set with hundreds of values, manual entry isn’t practical. CSV import handles bulk loading in one go.

The Term Store accepts a CSV import that lets you load an entire taxonomy in one operation. You download a template, populate it (one row per term, with hierarchy, descriptions, and synonyms), and import. SharePoint reads the CSV, validates the structure, and creates the terms in bulk. Hundreds or even thousands of terms become a five-minute job instead of a five-day one.

This is the right approach when you’re migrating a taxonomy from somewhere else (an Excel spreadsheet of product codes, an existing SharePoint site, a legacy system), or when you’re seeding a new term set that already has a defined structure. Use cases include client lists, project codes, industry classifications, location hierarchies, and product catalogues.

The CSV format is unforgiving. Headers must be exact, hierarchy is implied by the order and indentation of rows, and special characters in term names will cause silent failures. Test with a small sample first — five or ten terms — and verify the import worked before loading thousands.

When you’ll use this

• When migrating an existing taxonomy from another system into the Term Store.
• When seeding a new term set with hundreds of values.
• When loading client lists, product catalogues, code tables, or industry classifications.
• Not for ongoing maintenance — manual entry is fine for ones and twos.

How to do it

1. Open the Term Store and navigate to the target term set (or create a new one).
2. Download the CSV template.
3. Populate the CSV: one row per term, with columns for name, description, synonyms, hierarchy.
4. Validate in Excel — check for typos, special characters, duplicate names.
5. Test with a small sample (10 rows) first.
6. Import the full CSV through the Term Store interface.
7. Verify the terms appear correctly in the hierarchy.
8. Mark them ‘available for tagging’ if not done by the import.

Best practices

• Strictly follow the template format. The Term Store is unforgiving about column headers and row structure.
• Test small before going big. 10 rows first. Verify. Then load 1000.
• Keep the source CSV as a backup. Your taxonomy is now in two places — Term Store and CSV.
• Document the import. Date, source, who did it, what was added.

Common mistakes

• Special characters that break the CSV. Apostrophes, quotation marks, ampersands. Test carefully.
• Duplicate names within a set. The Term Store rejects duplicates silently — some rows just don’t import.
• No backup of the original CSV. If the taxonomy gets corrupted, you have no source of truth to reload from.

↑ Back to top ↑ Back to list

Once the Term Store has your vocabulary, you connect it to libraries via Managed Metadata columns. This is where the central work pays off in every library.

Connecting a term set to a column is what makes Managed Metadata real for users. A library administrator adds a Managed Metadata column to their library, points it at the term set, and from that moment forward users tagging files in that library see the term set’s values as suggestions and dropdowns. The taxonomy is suddenly usable.

The connection is one-way: the column references the term set, but doesn’t copy it. If the term set changes (a term is renamed, archived, or added), the column reflects those changes immediately, in every library that uses it. This is the whole point of central management — change once, propagate everywhere.

Configuration choices matter. Allow multiple values? (Sometimes a document genuinely belongs to two departments.) Display the entire path? (Useful for hierarchies, where ‘APAC > Australia’ is more meaningful than just ‘Australia’.) Allow fill-in? (Risky — defeats the consistency.) Each toggle has trade-offs. Default to single-value, no fill-in, and only enable path display when hierarchy is meaningful.

When you’ll use this

• When you have a term set in the Term Store and want to use it in a library.
• When a library currently uses Choice columns that should be tenant-wide instead.
• When you want a column whose values stay synchronised with central governance.
• When you’re standardising tagging across multiple libraries that should use the same vocabulary.

How to do it

1. Confirm the term set exists in the Term Store and is marked ‘available for tagging’.
2. Open the library and click + Add column → Managed Metadata.
3. Select the relevant term group, then term set.
4. Decide: multiple values allowed? (Usually no.)
5. Decide: display entire path? (Yes for hierarchies, no for flat lists.)
6. Decide: allow fill-in? (Almost always no.)
7. Save and start tagging items.
8. Users get type-ahead suggestions from the term set as they tag.

Best practices

• Default to single value, no fill-in. Multi-value and fill-in are exceptions, not defaults.
• Show path for hierarchies. Helps users disambiguate (e.g. ‘Sales > Australia’ vs ‘Sales > UK’).
• Use the same column name across libraries. ‘Department’ everywhere beats ‘Dept’ in some libraries and ‘Department’ in others.
• Combine with required. If a department tag is essential, make the column required so files can’t be uploaded untagged.

Common mistakes

• Allowing fill-in casually. Users add ad-hoc values that pollute the central taxonomy.
• Different column names for the same concept. ‘Department’ and ‘Dept’ as the same meaning in different libraries — breaks reporting.
• Multi-value where single is needed. Confuses filtering (‘show me Marketing’ includes everything tagged with multiple departments).

↑ Back to top ↑ Back to list

Choice and Managed Metadata both give users a list to pick from. Knowing which to use, when, is the difference between scalable structure and fragmented chaos.

Both Choice and Managed Metadata columns offer users a fixed set of values. They look similar to end users — pick from a list. But under the hood they’re very different, and choosing the right one matters for long-term scalability.

Choice is local — its values are defined and stored within a single library or content type. Cheap and fast to set up. Perfect for library-specific lists like ‘Approval Stage’ or ‘Priority’ that don’t apply elsewhere. The downside: every library that wants the same list has to recreate it independently, and they drift over time.

Managed Metadata is central — its values come from the Term Store, shared across the whole tenant. More effort to set up (admin involvement required), but the values are consistent everywhere they’re used. Perfect for tenant-wide lists like ‘Department’ or ‘Document Type’ that need to mean the same thing across many libraries and sites.

Why this matters

Choosing wrong has compounding costs as the organisation grows:

Choice in 50 libraries = 50 versions of ‘department’. One says ‘HR’, another ‘Human Resources’, a third ‘People & Culture’. Reports across libraries become impossible.

Managed Metadata for everything = bottleneck. Every small list has to go through admin governance. Frustrating for library owners with reasonable local needs.

The right answer depends on scope. Local list = Choice. Tenant-wide list = Managed Metadata. The decision rules are simple once you ask the right question.

When you’ll use this

• Choice: for local, library-specific lists (Status, Approval Stage, Priority).
• Managed Metadata: for tenant-wide lists (Department, Location, Document Type).
• Choice: when you need to set it up immediately, alone, without admin involvement.
• Managed Metadata: when consistency across many libraries matters more than speed of setup.

Best practices

• Default to Choice for local lists. Don’t burden the Term Store with everything.
• Default to Managed Metadata for shared concepts. Department, location, document type — these belong in the Term Store.
• Don’t mix the two for the same concept. If ‘Department’ is Managed Metadata in one library, it should be Managed Metadata everywhere.
• Migrate Choice to Managed Metadata when scope expands. When a Choice list becomes used in 3+ libraries, it’s time to centralise.

Common mistakes

• Choice for everything. Easier short-term, but creates fragmented vocabularies that never align.
• Managed Metadata for everything. Bottlenecks the admin team and frustrates library owners with simple local needs.
• Mixing the two for the same concept. ‘Department’ as Choice in some libraries and Managed Metadata in others is the worst of both worlds.

↑ Back to top ↑ Back to list

Calculated columns derive values from other columns automatically. Used wisely, they reduce manual entry and create powerful summary fields.

A Calculated column uses a formula (Excel-style) to compute its value from other columns in the same row. Common uses include automatic review dates (‘Modified date + 365 days’), summary strings (combine document type + department + status into a searchable label), and conditional flags (‘Yes’ if Status equals Approved). The user never types into a Calculated column directly — SharePoint computes the value automatically whenever the underlying data changes.

Calculated columns are powerful because they remove duplicate work. Instead of asking users to manually type the review date when they create a file, a calculated column generates it from the creation date plus a standard offset. Instead of asking users to remember to update a status flag, a calculated column derives it from other fields.

The constraints matter. Calculated columns can’t reference Person or Managed Metadata columns directly (you can work around this with secondary fields). They can’t be used in some workflow scenarios. And complex formulas become brittle and hard to maintain. Use Calculated columns for simple, well-defined derivations — not as a substitute for Power Automate or proper data modelling.

When you’ll use this

• When one column’s value can be derived reliably from others.
• For automatic review dates, expiry dates, summary fields, conditional labels.
• For combining fields into a searchable composite (e.g. ‘CONTRACT-Marketing-2026’).
• Not for complex business logic — use Power Automate for anything beyond simple derivations.

How to do it

1. Click + Add column → Calculated.
2. Type the formula using existing column names in square brackets, e.g. <code>=[Modified]+365</code>.
3. Set the data type for the result (text, number, date, currency).
4. Save and test on existing items to confirm the formula works.
5. Adjust if results aren’t what you expected.
6. Verify the column updates correctly when the source columns change.

Best practices

• Test formulas in Excel first. The syntax is identical, and Excel gives clearer error messages.
• Keep formulas simple. Complex multi-condition formulas become unmaintainable. If it’s complex, use Power Automate.
• Document the formula. In the column description, explain what it does so future admins understand.
• Be aware of the constraints. Person columns and Managed Metadata can’t be referenced directly — plan around this.

Common mistakes

• Complex business logic in a calculated column. Becomes brittle, hard to maintain, easy to break. Use Power Automate.
• Trying to reference Person or Managed Metadata columns directly. Won’t work. Use intermediate columns or different approaches.
• No documentation. Six months later, nobody remembers what the formula does or why.

↑ Back to top ↑ Back to list

Location columns capture real-world addresses with structured map data. Useful for site visits, project locations, and any data that has a ‘where’.

A Location column is a specialised column powered by Bing Maps. Users type a location and select from address suggestions; SharePoint stores not just the text but structured fields — street, city, state, country, postcode, latitude, longitude. You can display any of these as separate columns in views, filter by city, or feed them into reports.

The classic uses are field operations: site inspections, project addresses, asset locations, client offices, regional reporting. Anywhere your data has a real-world location component and you want consistent, structured address data.

The thing to verify is that Bing Maps recognises your locations correctly. Most named addresses work fine; complex industrial sites or rural locations sometimes don’t. Always check the map preview when adding a location, and don’t trust it blindly for compliance-critical addresses (regulatory filings, insurance reporting). For most uses, it’s accurate enough to be very useful.

When you’ll use this

• For site inspections, project addresses, asset registers, regional reporting.
• For tracking client office locations, supplier addresses, branch offices.
• When you want city/state/country to appear as separate filterable columns.
• When a ‘where’ is genuinely part of the file’s metadata.

How to do it

1. Click + Add column → Location.
2. Save the column.
3. On each item, search for the address — Bing Maps suggests options.
4. Pick the correct suggestion to populate structured fields automatically.
5. Add separate display columns for City, State, Country if you want them visible.
6. Build views grouped by city, region, or country.

Best practices

• Verify each address. Bing Maps is good but not perfect. Check before saving for important records.
• Display separate fields in views. ‘City’ as its own column lets you group and filter regionally.
• Use with calculated columns for region grouping. ‘Region’ = APAC if Country is Australia or NZ or Singapore.
• Don’t rely on for compliance addresses. Regulatory filings need verified addresses, not Bing-Maps-suggested ones.

Common mistakes

• Trusting Bing’s first suggestion blindly. Always check the map preview matches the intended location.
• No separate city/region columns. The structured data is wasted if you can’t filter or group by it.
• Using for free-text address data. Location columns are for verified addresses, not ‘somewhere in Sydney’.

↑ Back to top ↑ Back to list

Document Type tells SharePoint what kind of file each one is. It’s the single most important metadata column — and the one most libraries are missing.

A Document Type column captures the nature of the document — Policy, Procedure, Invoice, Contract, Meeting Minutes, Report, Presentation, Template, Job Description. It’s a simple categorisation, but it’s the column that does the most work. If you only have one metadata column, this is the one to have.

Why? Because Document Type is the answer to the question users actually ask when looking for files: ‘show me all the policies’, ‘show me all the contracts’. Without it, that question becomes ‘show me everything in this library and I’ll figure it out from filenames’. With it, the answer is a one-click filter.

Document Type is also where Copilot earns its keep. When Copilot is asked ‘find our remote work policy’, a tagged ‘Document Type: Policy’ column gives it a strong, structured signal. Without it, Copilot is doing fuzzy text matching and crossing its fingers. Add Document Type to every library you care about, and Copilot’s accuracy improves immediately.

When you’ll use this

• On every library that holds more than one type of content.
• When users frequently ask ‘show me all the [type]’.
• When you’re preparing a library for Copilot.
• When you’re standardising metadata across a department or organisation.

How to do it

1. Decide your list of document types — keep it short (5-15 types).
2. Choose the column type: Choice (library-specific) or Managed Metadata (tenant-wide).
3. Click + Add column and create it.
4. Add the values.
5. Make required and set a default if there’s an obvious one.
6. Tag existing files in bulk via Quick Edit / Grid View.
7. Build a ‘Group by Document Type’ view (see M-32) for natural folder-style navigation.

Best practices

• Use Managed Metadata for tenant-wide consistency. ‘Policy’ should mean the same thing in every library.
• Keep the list short. 5-15 types is the sweet spot. More than 20 and users start ignoring the column.
• Make it required. Files without Document Type are invisible to filters and Copilot.
• Build views around it. Group by Document Type replaces the need for folder structure.

Common mistakes

• No Document Type column. The single biggest missed opportunity in most SharePoint libraries.
• Too many types (50+). Users freeze, stop tagging, defeat the purpose.
• Different types per library for the same concept. Inconsistency between libraries makes cross-library reporting impossible.

↑ Back to top ↑ Back to list

Department tells SharePoint which part of the business owns or relates to the content. It’s the second-most-important metadata column after Document Type.

A Department (or Function) column captures which business unit a document belongs to — Finance, HR, Marketing, Operations, IT, Legal, Sales. Combined with Document Type, it answers most of the routing and ownership questions a library has to handle. ‘Show me all HR policies’, ‘show me all Finance contracts’, ‘who owns the IT procedures’ — all become one-click queries.

The right place for Department in most organisations is in the Term Store as Managed Metadata. Departments are a tenant-wide concept that should mean the same thing everywhere. Marketing is Marketing whether you’re tagging a contract, a meeting minute, or a budget — and changes (mergers, renames, splits) happen centrally instead of in every library independently.

The column also has governance implications. When a department restructures, the Term Store can be updated centrally, and every file tagged with that department updates automatically. When someone leaves a department, you can audit which files were owned by that department and reassign appropriately. This kind of structural management is what scales SharePoint to enterprise size.

When you’ll use this

• On every library that holds content from or about specific business units.
• When ownership crosses team boundaries and you need to track it.
• For department-specific reporting and filtering.
• When you want to align library access with organisational structure.

How to do it

1. Confirm the official list of departments (often from HR or your org chart).
2. Add as Managed Metadata in the Term Store (preferred) or Choice (for single-site use).
3. Add the column to the library: + Add column → choose your type.
4. Set values to match the official department list.
5. Make required if every file should be classified.
6. Set a default if 90% of files belong to one department.
7. Use to filter and create department-specific views and Power Automate flows.

Best practices

• Use Managed Metadata for cross-tenant consistency. Departments shouldn’t drift between libraries.
• Match to your HR org structure. If HR says it’s ‘People & Culture’, so should SharePoint.
• Update when the org changes. Mergers, splits, renames — keep the Term Store current.
• Combine with Document Type. Together they answer ‘what is this and who does it belong to?’ for almost every file.

Common mistakes

• Different department lists in different libraries. Cross-library reporting becomes impossible.
• Stale lists after org changes. Six-month-old department names confuse users and break process.
• No Department column at all. Half your filtering needs become unanswerable.

↑ Back to top ↑ Back to list

Status tells you where a document is in its lifecycle: Draft, Review, Approved, Published, Archived. Done well, it makes the lifecycle visible.

A Status column tracks where a document is in its lifecycle — typically values like Draft, In Review, Approved, Published, Superseded, Archived. It’s a simple Choice column most of the time, but its impact is significant: it makes the document’s lifecycle visible at a glance, lets you filter views (‘show me all drafts’), and powers Power Automate flows that act when status changes.

Status is also the column that turns a flat library into a managed lifecycle. With status colour-coded (‘Draft’ in red, ‘Approved’ in green, ‘Archived’ in grey), a library view becomes a dashboard. With status driving Power Automate flows, status changes can trigger notifications, file moves, retention rules, or approval workflows. Without status, the lifecycle is invisible and unmanaged.

The choice of status values depends on your process. Simpler libraries might have just three: Draft, Approved, Archived. More controlled libraries might have six or seven, mapped to a formal review and approval workflow. Match the values to your actual process — don’t invent statuses you’ll never use, and don’t omit statuses your team relies on.

When you’ll use this

• On any library where documents move through stages (drafts, reviews, approvals).
• When you want lifecycle visibility at a glance.
• When Power Automate flows should trigger on status changes.
• When auditors want to see the journey from draft to approval.

How to do it

1. Decide your status values to match your process (typically 4-6 values).
2. Add as a Choice column.
3. Set ‘Draft’ as the default for new files.
4. Apply colour formatting in views — red for Draft, green for Approved, etc.
5. Build views filtered by status (e.g. ‘My drafts’, ‘Pending review’, ‘Approved this month’).
6. Use Power Automate to react to status changes (notify, move, archive).

Best practices

• Apply colour formatting. Visual scanning beats reading. Red drafts and green approvals make views instantly readable.
• Default to ‘Draft’. Approved-by-default is dangerous. Always start as Draft.
• Match values to your actual process. Don’t invent statuses you won’t use.
• Trigger automation from status changes. Status moving to Approved can trigger notifications, file moves, retention.

Common mistakes

• Too many statuses. ‘Initial Draft’, ‘Working Draft’, ‘Refined Draft’ is one status (Draft) overcomplicated.
• No default value. Files appear with blank status, which breaks filters.
• Status that doesn’t match the process. If you have ‘Published’ but no one publishes, the value is dead weight.

↑ Back to top ↑ Back to list

Topic columns group documents by subject matter. When content crosses departments, a topic tag is what makes it findable.

A Topic (or Category) column groups documents by what they’re about rather than where they came from. A document about Health & Safety might be authored by HR but referenced by Operations, Compliance, and Facilities — Topic captures the subject matter, separate from departmental ownership. Topics are usually multi-value (a single document can cover several topics) and form the basis for cross-departmental knowledge hubs.

Topics work best when the categorisation is broad and stable. ‘Compliance’, ‘Cyber Security’, ‘Health & Safety’, ‘Sustainability’, ‘Customer Experience’ — these are durable categories that survive org restructures. Avoid topics that are too narrow (‘Q3 2026 Marketing Campaign’) — those are projects, not topics.

Topics shine when combined with Document Type and Department. A user can ask ‘show me all Health & Safety policies from Operations’ and get a precise answer — three structural columns combining to filter the entire library down to the specific subset they need. This is the sort of multi-dimensional view metadata enables that folders simply cannot.

When you’ll use this

• When documents cover topics that cross departmental boundaries.
• When you’re building knowledge hubs by subject area.
• For broad themes (Health & Safety, Compliance, Sustainability, Wellbeing).
• When users search by what content is about, not who owns it.

How to do it

1. Define your list of topics — broad, stable categories (5-15 typically).
2. Add as Managed Metadata (preferred for cross-site consistency) or Choice.
3. Allow multiple values — documents can cover several topics.
4. Save and tag existing content.
5. Build views grouped by topic for cross-departmental knowledge browsing.
6. Use in search and Copilot prompts to find topical content.

Best practices

• Allow multiple selections. Documents legitimately cover multiple topics.
• Keep topics broad. ‘Health & Safety’ is a topic. ‘Q3 2026 H&S Campaign’ is a project.
• Use Managed Metadata for cross-site reuse. Topics defined once, used in every relevant library.
• Review periodically. Retire stale topics, add emerging ones.

Common mistakes

• Topics too narrow. Becomes a project tracker by another name. Topics should outlive specific initiatives.
• Single-value topic columns. Forces users to pick one when documents genuinely cover several.
• Inconsistent topics across libraries. If ‘Compliance’ means different things in different places, reporting breaks.

↑ Back to top ↑ Back to list

When work is organised by project, a Project Name column connects every related file. Done well, it lets you see all of a project’s content in one query.

A Project Name column tags each document with the project it belongs to. Combined with Document Type (‘all the contracts for Project Acme’), Status (‘all the approved deliverables for Project Acme’), or Date (‘Project Acme documents from this week’), it creates a project-level view of content that spans normal departmental and document-type boundaries.

The right way to implement Project Name is usually as a Lookup column pointing to a master Projects list (within the same site) or as Managed Metadata if projects are tracked centrally across the tenant. Either way, the goal is the same: one canonical list of projects, and every relevant document tagged with the right one. Free-text project name columns inevitably drift (‘Project Alpha’, ‘Alpha Project’, ‘project-alpha-2026’) and break reporting.

Projects also have lifecycles. They start, progress through phases, and close. Combined with a Project Phase column (M-26) and a Project Lead column (M-27), Project Name becomes the centre of a small project information system within SharePoint — without any need for a separate project management tool.

When you’ll use this

• When work is organised by projects with multiple deliverables.
• When you need to see all documents for a specific project across types and stages.
• For project archives, post-project reviews, lessons learned.
• When projects span multiple departments and you want unified visibility.

How to do it

1. Create a master Projects list (in the same site) — name, code, status, lead, dates.
2. In your library, click + Add column → Lookup.
3. Choose the source list (Projects) and the column to display (Project Name).
4. Optionally include extra columns (Project Code, Lead) for richer display.
5. Make required for project-related libraries.
6. Use in views to group, filter, and report by project.

Best practices

• Use a Lookup or Managed Metadata, never free text. Free-text project names drift uncontrollably.
• Maintain one master Projects list. Update names, status, leads in one place; every library reflects it.
• Show project codes alongside names. ‘Acme Migration (PRJ-2026-014)’ beats just ‘Acme Migration’ when names are similar.
• Combine with Project Phase and Project Lead. Three columns turn the library into a project information system.

Common mistakes

• Free-text project names. The single biggest cause of broken project reporting.
• No central master list. Each library invents project names independently.
• Project Name as a single text column. Loses Lookup’s central management benefits.

↑ Back to top ↑ Back to list

Phase shows where a project is in its lifecycle. Combined with Project Name, it lets you slice content by ‘all the planning documents for all active projects’.

A Project Phase column tracks where a project is in its lifecycle — Initiation, Planning, Execution, Monitoring, Closure (or whatever phase model your organisation uses). At the document level, this means you can see not just which project a document belongs to, but which phase of that project it relates to.

Phase is most useful when filtering across many projects. ‘Show me all the Closure phase documents’ across an entire portfolio gives you a view of what’s wrapping up. ‘Show me all Planning phase documents this month’ shows what’s starting. Combined with Project Name, you get a full matrix view of project activity.

Match the phase values to your organisation’s project methodology. PRINCE2 has different phases from PMI which has different phases from Agile. Use whatever your team actually uses — don’t invent a phase model that doesn’t match your real practice.

When you’ll use this

• When projects move through formal phases and document content varies by phase.
• When you want phase-level reporting across a portfolio of projects.
• When auditors or governance need to see what’s been completed at each phase.
• When you’re aligning SharePoint with a project management methodology.

How to do it

1. Confirm the phase model your organisation uses (PRINCE2, PMI, Agile, custom).
2. Add as a Choice column with phase values.
3. Set Initiation (or Planning) as the default for new files.
4. Apply colour formatting if useful (early phases blue, closure green).
5. Build views grouped by Project Name and Phase for portfolio visibility.
6. Update phase as the project progresses.

Best practices

• Match to your real methodology. PRINCE2 phases for PRINCE2 shops. Don’t invent phases.
• Update phase as work moves. A document tagged ‘Planning’ three months after closure is misleading.
• Pair with Project Name. Phase alone isn’t enough; combined with project, it’s powerful.
• Use for portfolio reporting. ‘How many projects are in Execution right now?’ becomes a one-click query.

Common mistakes

• Phase values that don’t match your method. Confusing for project managers, useless for reporting.
• Static phases that don’t get updated. Stale phase data is worse than no phase data.
• No default value. Files appear with blank phase, which breaks filters.

↑ Back to top ↑ Back to list

Every project needs an owner. A Project Lead column connects the project — and all its documents — to the person responsible.

A Project Lead column captures the named person responsible for a project. As a Person column, it connects to the real Microsoft 365 directory — meaning you get profile photos, hover cards, presence, and the ability to filter by ‘Me’ to see all projects where the current user is lead. It also enables Power Automate flows that notify the lead when project documents change, deadlines approach, or status flips.

For project-heavy organisations, this column does enormous work. A ‘My Projects’ view (filtered where Lead = [Me]) becomes the project manager’s daily workspace. A scheduled report can email each lead a weekly digest of their projects’ status. Project handovers become trivial — just reassign the Person field, and all the linked filtering and notifications follow automatically.

Keep it single-person. Distributed leadership (‘co-leads’, ‘committee’, ‘shared accountability’) sounds collaborative but in practice diffuses responsibility. One named lead per project — even if other people contribute heavily — gives you clear accountability and clean filtering. Co-leadership belongs in a separate column or in the project description, not as multi-value Project Lead.

When you’ll use this

• When projects have a clear primary owner who is accountable.
• When you want ‘My Projects’ views and personalised filtering.
• When automated notifications should go to the project lead.
• When you’re handing over projects and need to reassign clean ownership.

How to do it

1. Add as a Person column (not text).
2. Choose ‘People only’, not Groups.
3. Single-person, not multi-person.
4. Make required for project libraries — every project needs a named lead.
5. Build a ‘My Projects’ view filtered where Lead = [Me].
6. Set up Power Automate flows for lead notifications.

Best practices

• Always Person, never text. Loses everything that makes Person columns useful.
• Single-person primary accountability. Co-leads and committees diffuse responsibility.
• Build [Me] views. Project leads should have a one-click view of all their projects.
• Audit when leads leave. Reassign promptly so projects don’t go orphaned.

Common mistakes

• Text column for lead name. Loses presence, photos, [Me] filtering, automated notifications.
• Multi-person leads. Confused responsibility. Pick a primary; capture others elsewhere.
• Stale leads after staff changes. Departed staff still listed as project leads months later.

↑ Back to top ↑ Back to list

Due dates turn documents into actionable items. Combined with Person and Status columns, they power deadlines, reminders, and proactive management.

A Due Date column captures when an action on a document is required — review by, approval deadline, submission due, expiry. As a Date column, it sorts chronologically, filters by date range (‘this week’, ‘overdue’), and feeds Power Automate flows that send reminders before deadlines hit.

Where Due Date earns its keep is in active management. A view filtered to ‘Due in the next 30 days’ sorted by date gives you a daily snapshot of what’s coming. Conditional formatting that turns overdue dates red makes problems immediately visible. Power Automate flows that email owners three days before their due dates create a proactive culture instead of a reactive one.

Combine Due Date with Person columns and you have a personal task system inside SharePoint. ‘Show me documents I own with a due date in the next 30 days’ is a column-level query that doesn’t need any external tool. For organisations that want to keep their workflow inside SharePoint, this combination is a hidden superpower.

When you’ll use this

• For Review By, Approval Deadline, Submission Due, Expiry Date.
• When documents have time-bound actions.
• When you want to prevent overdue items by notifying owners ahead of time.
• When auditors need to see what’s compliant and what’s overdue.

How to do it

1. Add as Date and time column (Date Only is usually fine).
2. Set required if every relevant document needs a date.
3. Apply conditional formatting — red for overdue, amber for upcoming.
4. Build views: ‘Overdue’, ‘Due this week’, ‘Due next 30 days’.
5. Combine with Person column for [Me] views: ‘My documents due soon’.
6. Set up Power Automate flow: email the owner 7 days before due date.

Best practices

• Combine with Person columns. Due dates without owners aren’t actionable.
• Apply conditional formatting for overdue. Red dates draw the eye to problems.
• Send proactive reminders. Don’t wait for things to be overdue — notify in advance.
• Use ISO date format wherever you can. Sorts correctly without ambiguity.

Common mistakes

• Due dates without owners. Who’s supposed to act? Combine with Person columns.
• No reminders. Due dates that no one watches are ceremony, not management.
• Stale due dates that aren’t updated. Last year’s deadline shouldn’t show as overdue forever.

↑ Back to top ↑ Back to list

Views are saved configurations of how data is displayed — what’s shown, how it’s sorted, how it’s filtered. Done well, they make a single library serve many purposes.

A View in SharePoint is a saved combination of column visibility, sort order, filters, and grouping. The same library can have many views, each optimised for a different use case. The default view might show everything in alphabetical order; a ‘My documents’ view filters to where Owner = Me; a ‘Recently modified’ view sorts by Modified date descending; a ‘Group by Document Type’ view replaces folder navigation with metadata-based browsing.

Views are how libraries scale beyond simple lists. A library with 5,000 files is unnavigable as a single flat list — but with 6 well-designed views, each surfaces the right slice of content for the right user. Power users get the full library; everyday users get streamlined views; managers get summary views; auditors get compliance views.

The skill in view design is restraint. Three to five well-designed public views are far more useful than 20 one-off views nobody understands. Build views around real user tasks, not theoretical possibilities. Make each view’s purpose clear from its name. Retire views that aren’t used.

When you’ll use this

• When the default view doesn’t show what users need at a glance.
• When different user groups need different perspectives on the same content.
• When you want to make filtering and sorting persistent rather than one-off.
• When users keep applying the same filters manually — that’s a view waiting to be created.

How to do it

1. Sort, filter, and arrange the library to show what you want.
2. Click the View menu (top-right of the library) → Save view as.
3. Name it clearly — ‘My Open Items’, ‘Pending Review’, ‘Recently Modified’.
4. Choose Public (everyone) or Personal (just you).
5. Save. The view appears in the View menu for selection.
6. Edit the view later via View settings to add more refinement.

Best practices

• Keep the default view simple. It’s the first thing users see. Don’t make it complicated.
• Make useful views Public. If it helps you, it’ll probably help the team.
• Use clear, action-oriented names. ‘My Open Items’ beats ‘View 3’.
• Limit to 3-5 views per library. More than that and users can’t find the right one.

Common mistakes

• Too many views. 20 views that nobody understands is worse than 3 well-designed ones.
• Personal views that should be public. If five people have built the same personal view, make it public.
• No clear naming. ‘View Sarah 2’ tells nobody what it does.

↑ Back to top ↑ Back to list

A flat view ignores folder structure and shows every file in the library. Combined with grouping and filtering, it makes folders almost unnecessary.

By default, a SharePoint library view shows folders, and you click into them to see the files inside. A flat view turns that off — every file appears at the top level regardless of which folder it’s in. The folder structure still exists in the data; it’s just hidden from this view.

Why bother? Because folders hide things. A library with 200 files in 20 folders looks tidy in folder view but means users have to know which folder to open to find what they need. In flat view, all 200 files are visible — and combined with grouping (by Document Type, Department, Status) and filtering, the user can find anything in two clicks: filter to ‘Policies’ and ‘HR’ and the 12 relevant files appear, regardless of which folder they were filed in.

This is the fundamental shift from folder-thinking to metadata-thinking. Folders organise once, fixed. Metadata-driven views organise dynamically — the same files can be ‘organised’ six different ways via six different views. The structure adapts to the question, instead of the user adapting to the structure.

When you’ll use this

• When folders are hiding files that should be findable from the top level.
• When you’re auditing a library and need to see everything at once.
• When you’ve added metadata to existing folder structures and want to surface the metadata.
• When you’re moving from folder-based organisation to metadata-driven organisation.

How to do it

1. Edit the view (click Edit current view or create a new view).
2. Open the Folders section.
3. Choose Show all items without folders.
4. Save the view.
5. Pair with Group By a meaningful column (Document Type, Department) to give structure without folders.
6. Apply filters to narrow further.
7. Make this the default view if metadata-driven navigation is your goal.

Best practices

• Always pair flat view with Group By. Otherwise it’s just a long list.
• Use as the default view in metadata-driven libraries. Sets the expectation that folders are less important.
• Combine with filters for precise navigation. Filter to current year, then group by Document Type — instant overview.
• Educate users gradually. Folder users won’t switch overnight. Show them the benefits.

Common mistakes

• Flat view with no grouping. Just a long unsorted list. Add Group By.
• Forcing flat view on libraries with no metadata. Without metadata, flat is useless. Add columns first.
• Removing all folders abruptly. Existing folder paths in links and bookmarks break. Migrate gradually.

↑ Back to top ↑ Back to list

A ‘My Documents’ view filters the library to just the current user’s content. One filter, infinite personalisation.

A ‘My Documents’ view uses the [Me] token in a filter — typically ‘where Created By is equal to [Me]’ or ‘where Owner is equal to [Me]’ — to show only files relevant to the current user. The clever thing is that [Me] resolves dynamically. The same view shows different content for every user; everyone sees their own files automatically.

This single technique transforms how users experience a library. Instead of a library being a shared space full of everyone’s content, it becomes a personalised workspace. Users land on the page and see immediately what’s theirs, what needs attention, what’s overdue. No clicking, no filtering manually, no searching.

You can build many [Me] views: ‘My drafts’ (where Owner = Me and Status = Draft), ‘My approvals waiting’ (where Approver = Me and Status = Pending), ‘My documents due soon’ (where Owner = Me and Due Date is within the next 30 days). Each one becomes a personal task list inside the library, no extra tools required.

When you’ll use this

• On any library where individual users have specific responsibilities for their own files.
• When the library is shared but users want personalised entry points.
• For project management, document management, content authoring, approval queues.
• Whenever a Person column captures ownership or assignment.

How to do it

1. Edit the view or create a new one.
2. In the Filter section, set Created By (or Owner, or Assigned To) is equal to [Me].
3. Save the view as ‘My Documents’ (or ‘My Tasks’, ‘My Drafts’).
4. Make it Public so all users get the same experience.
5. Optionally combine with status: ‘My drafts’, ‘My approved’, ‘My overdue’.
6. Build similar views for other Person columns (Approver, Reviewer, Project Lead).

Best practices

• Use [Me] in views, never typed names. [Me] adapts; typed names don’t.
• Build multiple [Me] views. Different filters serve different needs.
• Make [Me] views Public. Every user sees their own content automatically.
• Combine with sort by Modified. Most recent at the top — natural to scan.

Common mistakes

• Using typed names instead of [Me]. Hard-codes the view to one person; not reusable.
• Not promoting [Me] views to Public. Each user has to recreate the same view themselves.
• No corresponding Person column. [Me] only works against Person columns. Adding it on a text field doesn’t work.

↑ Back to top ↑ Back to list

Group By turns a flat list into a structured outline organised by metadata. It replaces folder navigation with something more flexible.

Group By is one of the most powerful (and underused) view features. Instead of a flat list, the library shows files organised under expandable headers — one per unique value in a chosen column. Group by Document Type, and you see ‘Policies (12)’, ‘Procedures (8)’, ‘Templates (5)’, each expandable to show the files inside.

The effect is folder-like, but driven by metadata instead of file location. Users get the navigational comfort of seeing categories — but the underlying data isn’t actually fragmented into folders. The same file can appear under ‘Policies’ in one view, ‘HR’ in a Group-by-Department view, ‘Approved’ in a Group-by-Status view, and ‘Sarah Smith’ in a Group-by-Owner view. One file, four organisational frames.

Set group default to Collapsed for the cleanest experience. The user lands on the page and sees just the headers (‘Policies, Procedures, Templates…’), expanding only the categories they care about. This dramatically reduces visual clutter and guides users to the right slice of content quickly.

When you’ll use this

• When users navigate by category (document type, department, status).
• As a replacement for folder structure in metadata-driven libraries.
• When the library has many files but a small number of meaningful categories.
• When you want users to see ‘how much of each’ at a glance.

How to do it

1. Edit the view (or create a new one).
2. In the Group By section, choose the column to group on (e.g. Document Type).
3. Set Show grouping default to Collapsed.
4. Optionally add a second-level grouping (e.g. group by Document Type, then by Department).
5. Save the view.
6. Make Public — this is the kind of view the whole team benefits from.

Best practices

• Set default to Collapsed. Cleanest landing experience. Users expand what they need.
• Group on the right column. Document Type is the most common; Department, Status, Owner all work.
• Replace folder structure with Group By. Often gives the same navigational feel without the rigidity.
• Combine with sort. Group by Document Type, sort by Modified date — see latest by category.

Common mistakes

• Grouping on a high-cardinality column. 500 unique values means 500 groups — useless. Group on broader categories.
• Default expanded. All groups expanded means a very long page. Default to collapsed.
• Group by columns with too few values. Group by Yes/No is just two groups — barely worth it.

↑ Back to top ↑ Back to list

A view sorted by Modified date shows what’s changed recently. Useful for awareness, audits, and ‘what’s been happening?’ updates.

A Recently Modified view sorts the library by the Modified date in descending order, so the most recently updated files appear at the top. It’s not a sophisticated view — but it’s enormously useful as a ‘what’s new’ lens. Managers checking activity, auditors reviewing recent changes, team members catching up after time off — all benefit from an at-a-glance view of recent work.

Combined with filters, the view gets sharper. ‘Modified in the last 7 days’ filters out everything older. ‘Modified by [Me]’ shows your own recent activity. ‘Modified in the last 30 days, grouped by Document Type’ gives you a category-level view of what’s been changing.

For status meetings and team check-ins, a Recently Modified view is often more useful than the agenda. Open the library, see what’s been touched in the last week, walk through the highlights. No prep required — the view is the agenda.

When you’ll use this

• When you want to see what’s changed recently in a library.
• For status meetings, team check-ins, audit reviews.
• When users come back from leave and want to catch up on activity.
• For managers monitoring activity in libraries they oversee.

How to do it

1. Create a new view or edit an existing one.
2. Sort by Modified date, descending (newest first).
3. Optionally filter to last 30 days, or last 7 days.
4. Optionally combine with Group By Modified-By or Document Type.
5. Save as ‘Recently Modified’ or ‘This Week’s Activity’.
6. Make Public if the team will use it.

Best practices

• Combine with date-range filters. ‘Last 30 days’ is more useful than ‘all time, sorted by date’.
• Group by Modified-By for activity reports. See who’s been doing what, at a glance.
• Use for status meetings. Replace the agenda with the view itself.
• Don’t make this the default view. Useful as a secondary view, not the primary one.

Common mistakes

• No filter, just sort. Becomes a list of every file ever, in date order. Filter to last 30 days at minimum.
• Confusing Modified with Created. Modified = last edit; Created = when it was first uploaded.
• Using as the default view. Recent ≠ relevant. Default views should serve the primary use case.

↑ Back to top ↑ Back to list

A ‘Missing Metadata’ view shows files that haven’t been properly tagged. Used regularly, it keeps a library clean automatically.

A Missing Metadata view filters the library to show only files where one or more required columns are blank. The list shows you exactly which files need attention — a five-minute weekly cleanup task, instead of a six-month-long ‘we should really sort the library out’ project.

The most useful version filters on multiple columns: ‘where Document Type is empty OR Department is empty OR Owner is empty’. This catches files that snuck in without proper tagging — a common occurrence when users drag-and-drop multiple files at once or upload via sync. Your weekly cleanup target: this view should be empty.

Combined with Grid View / Quick Edit, fixing missing metadata is fast. Open the Missing Metadata view, switch to Grid View, fill in the blank cells like a spreadsheet, save. Five minutes of weekly attention prevents the library from drifting into chaos.

When you’ll use this

• When you have required metadata columns and want to monitor compliance.
• As part of a weekly or monthly library hygiene routine.
• When you’re cleaning up a library that’s accumulated untagged files.
• After bulk uploads when you need to verify everything got tagged.

How to do it

1. Edit a view (or create a new one called ‘Missing Metadata’).
2. Add a filter: Document Type is equal to (leave blank).
3. Add additional filters with OR logic: Department is empty OR Owner is empty.
4. Save as ‘Missing Metadata’.
5. Use weekly: open the view, switch to Grid View, fill in the blanks.
6. Goal: this view stays empty.

Best practices

• Schedule weekly checks. 5 minutes a week prevents huge cleanup later.
• Use Grid View for fast bulk editing. Spreadsheet-style data entry is much faster than per-file editing.
• Make required columns truly required. If files can be uploaded without a tag, this view will never be empty.
• Empty view = healthy library. Use this as a clean signal of metadata health.

Common mistakes

• Building the view but never checking it. Pointless if nobody uses it.
• Required columns that aren’t actually required. Make ‘required’ real at the column level.
• Filtering on too few columns. Files might pass one filter but fail another. Check all critical columns.

↑ Back to top ↑ Back to list

Filtering, sorting, and views all change how data is displayed. Knowing which to use saves time and avoids unnecessary view sprawl.

All three change how the library is displayed, but they differ in scope. Sorting reorders the list temporarily (until you refresh). Filtering hides items temporarily. Both are quick, ad-hoc, single-session tools. Views are saved combinations of sort + filter + columns + grouping that persist and can be shared with the team.

The right tool depends on whether you’ll need the same answer again. If you’re doing a one-off search (‘what files did I touch yesterday?’), sort and filter manually. If you’ll do that same search every week, save it as a view. If five people are doing it independently, make the view Public.

The most common mistake is building views for one-off needs. The library accumulates dozens of views over the years — most of them unused, most of them confusing. Discipline: filter first, save second, only when patterns emerge. Three good views are better than thirty mediocre ones.

When you’ll use this

• Filter and sort: when you need a quick, one-off answer.
• Save as view: when you’ll need that same answer repeatedly.
• Make view Public: when others on the team will benefit from the same view.
• Personal view: when the configuration is genuinely just for you.

How to do it

1. To filter: Click the column header arrow → choose values to filter by. Lasts until refresh.
2. To sort: Click the column header → ascending or descending. Lasts until refresh.
3. To save as a view: Apply your sort and filter, then click View → Save view as.
4. Decide Public (visible to everyone) or Personal (just you).
5. Name the view clearly so its purpose is obvious.

Best practices

• Filter first, save second. Don’t create a view until you know you’ll use it repeatedly.
• Limit views per library to ~5. More than that and users can’t find the right one.
• Public views need clear names. ‘Engineering — Open Items’ beats ‘Test View 3’.
• Audit views quarterly. Retire views nobody uses.

Common mistakes

• Saving a view for every one-off question. Library bloats with unused views.
• Personal views that should be public. If five people built the same personal view, make it Public.
• Vague view names. ‘My View 2’ tells nobody what it does.

↑ Back to top ↑ Back to list

How files are named affects how findable they are — by humans, search, and Copilot. Naming conventions turn random into intentional.

A naming convention is a written rule about how files should be named. The same convention applied across a team means files are predictable: same format, same date style, same component order. The difference between a library that’s a pleasure to navigate and one that’s a horror show often comes down to whether anyone agreed on naming.

What goes in a good convention? Usually a combination of: relevant date (in YYYY-MM-DD format so it sorts correctly), document type or category, distinctive label (project name, client, subject), and version notation (though SharePoint version history makes this less important). The exact components depend on the library — what works for project files won’t work for invoices.

The biggest single rule: dates first, in YYYY-MM-DD format. This single decision means files sort chronologically without any extra effort. Add document type after the date, distinctive label after that, and you have a consistent, sortable, scannable library that users actually enjoy navigating.

When you’ll use this

• Whenever you set up a new library and want it to scale.
• When existing libraries are filling with inconsistent filenames.
• When new team members need clear guidance on how to name files.
• When you’re preparing libraries for Copilot — clean names improve accuracy.

How to do it

1. Decide what info should be in the name (date, project, type, version).
2. Choose a separator (underscore _ or hyphen -, pick one and stick with it).
3. Use YYYY-MM-DD for dates so they sort chronologically.
4. Document the convention in the library’s description or in a one-page guide.
5. Train your team on the convention.
6. Audit existing files and rename where practical.
7. Make adherence visible — flag non-conforming names.

Best practices

• Always use YYYY-MM-DD for dates. Sorts correctly, no ambiguity, works internationally.
• Avoid generic names. ‘Document1.docx’, ‘Scan_001.pdf’, ‘Untitled.docx’ tell nobody anything.
• The name should describe what the file is without opening it. If you have to open it to know what it is, the name failed.
• Combine naming with metadata. Don’t rely on names alone — pair with Document Type, Department, Status columns.

Common mistakes

• No agreed convention. Every user names files differently. Library becomes unfindable.
• DD-MM-YY or MM-DD-YY dates. Don’t sort correctly. Use YYYY-MM-DD always.
• Names that include version numbers. SharePoint version history handles versioning. Don’t put ‘v3’ in filenames.

↑ Back to top ↑ Back to list

Theory matters less than examples. Concrete before-and-after pairs show what good naming looks like in practice.

The fastest way to teach a naming convention is to show it. A few before-and-after pairs makes the difference between abstract rules and intuitive practice. The bad examples should look familiar — they’re what most libraries actually contain. The good examples should feel obviously better, even without explanation.

Show examples for the document types your team actually produces. Project files, meeting minutes, invoices, reports, contracts — each has its own naming pattern. A one-page reference with three or four bad/good pairs per category gives users something to refer to without memorising rules.

The pattern that emerges across all examples is the same: information at the start, sortable elements first (dates), distinctive labels next, version/status info last (or omitted entirely if metadata handles it). Good filenames are scannable left-to-right.

When you’ll use this

• When training your team on naming conventions.
• When auditing an existing library and showing users what to fix.
• When onboarding new team members.
• When you’re refining a convention and need real examples to anchor the discussion.

Best practices

• Bad: ‘MeetingNotes_Final_v2.docx’ — no date, version in name, no context.
• Good: ‘2026-04-12_BoardMeeting_Minutes.docx’ — sortable date, clear context.
• Bad: ‘Copy of Invoice.pdf’ — no client, no period, no ID.
• Good: ‘INV-8821_Microsoft_2026-04.pdf’ — invoice ID, client, period.
• Bad: ‘Project Update.pptx’ — which project, when?
• Good: ‘2026-04-15_AcmeMigration_StatusUpdate.pptx’ — date, project, type.

Common mistakes

• Spaces in filenames. Some systems handle them poorly. Use hyphens or underscores.
• Special characters (& % # * etc.). Cause sync issues. Avoid.
• Names that change context. ‘Final’, ‘Latest’, ‘Current’ become meaningless once the next version exists.

↑ Back to top ↑ Back to list

Beyond style preferences, there are technical rules that filenames must follow. Knowing them prevents broken links, sync errors, and unhappy users.

SharePoint and OneDrive have technical constraints on filenames that, if violated, cause real problems — broken sync, failed downloads, file paths that exceed length limits, errors in URLs. Most users never encounter these (the system mostly accepts what they type), but for important content and bulk uploads, knowing the rules prevents pain.

The forbidden characters list is short but important: ~ ” # % &amp; * : &lt; &gt; ? / \ { | }. Avoid these in filenames. Apostrophes and accented characters mostly work but can cause edge-case issues with some integrations. Length limits matter too — the full path (server + library + folders + filename) has a maximum, and very deep folder structures with long filenames hit it.

The rules don’t matter for most everyday work. But when you’re preparing files for bulk upload, planning a migration, building integrations, or troubleshooting sync errors, the rules matter a lot. A few minutes of cleanup before upload prevents hours of investigation later.

When you’ll use this

• Before bulk uploading files into SharePoint.
• When troubleshooting sync errors or broken links.
• When designing a folder structure that will hold many files.
• When you’re planning a migration from another system.

Best practices

• Avoid forbidden characters: ~ ” # % &amp; * : &lt; &gt; ? / \ { | }
• Avoid leading or trailing spaces. Hard to see, easy to break things.
• Use underscores or hyphens instead of spaces. Cleaner URLs, better cross-system compatibility.
• Keep total path length under 200 characters. Server + folders + filename adds up faster than you think.
• Test sync with a sample of weird filenames. Confirms behaviour before you scale.

Common mistakes

• Special characters in filenames. Causes sync errors, broken links, URL encoding issues.
• Very deep folder structures with long names. Hits path length limits silently.
• Mixing case inconsistently. ‘Policy.docx’ and ‘policy.docx’ are technically different on some systems. Pick a case style.

↑ Back to top ↑ Back to list

Practical, opinionated guidance to keep names clean over time. Print this card and stick it next to the team’s monitors.

After the rules and the examples, the most useful naming guidance is the simple list of dos and don’ts. Things that are easy to remember, easy to apply, and easy to enforce in a few minutes of training. This is the printable cheat-sheet version.

The biggest don’ts come from old habits: putting your initials in filenames, including version numbers when SharePoint already does versioning, naming files ‘Final’ (knowing full well there’ll be a ‘Final v2’ next week). The biggest dos come from clarity: descriptive but concise, dates first, consistent abbreviations, rename on upload not later.

Print this card. Make it part of onboarding. Refer to it when reviewing a library that’s drifted. It won’t solve everything, but the small amount of repetition keeps the team honest.

Best practices

• Do: Use consistent abbreviations. ‘MKT’ or ‘Marketing’, ‘HR’ or ‘Human Resources’ — pick one and stick with it across all files.
• Do: Keep names descriptive but concise. Aim for 30-60 characters. More than 80 and you’re hurting readability.
• Do: Rename files immediately after upload. Not later. Later never comes.
• Don’t: Include your initials. SharePoint tracks Modified-By automatically.
• Don’t: Include version numbers in the filename. Use SharePoint version history.
• Don’t: Use ‘Final’, ‘Latest’, ‘Current’ in names. They become meaningless instantly.
• Don’t: Use spaces or special characters when alternatives exist. Underscores and hyphens are safer.

Common mistakes

• Treating naming as cosmetic. It’s structural. Names affect search, sort, Copilot accuracy, and team productivity.
• Inconsistency across team members. Five users naming files five ways defeats the convention.
• Renaming retroactively without a plan. Big bulk renames break links and bookmarks if not communicated.

↑ Back to top ↑ Back to list

SharePoint handles versioning automatically. Use that, instead of putting v1, v2, v3 in filenames — it’s cleaner and more reliable.

Every save in SharePoint creates a version automatically. The version number, timestamp, author, and (if added) check-in comment are all recorded. You can view version history, compare versions, restore previous versions — all without any manual versioning in the filename.

SharePoint supports two version types: major versions (1.0, 2.0, 3.0) for significant or published versions, and minor versions (1.1, 1.2, 1.3) for drafts or work-in-progress. Some libraries use both; others use only major versions. The choice depends on whether your workflow has a meaningful ‘draft vs published’ distinction.

The most common naming mistake is keeping version numbers in filenames anyway — ‘Marketing-Strategy-v3.docx’, ‘Marketing-Strategy-v4.docx’, ‘Marketing-Strategy-v5-FINAL.docx’. Now you have two versioning systems running in parallel: the filename version and SharePoint’s actual version history. They drift, contradict, and confuse. Pick one. SharePoint’s is better.

When you’ll use this

• On any library where you save documents repeatedly.
• When the team is currently using filename-based versioning.
• When you want to enable Compare and Restore features.
• When you need an audit trail of changes.

How to do it

1. Open the library and go to Library settings → Versioning settings.
2. Enable major versions at minimum.
3. Decide if you want minor versions (drafts in progress).
4. Set version limits (see L-11) so storage doesn’t grow indefinitely.
5. Train users to save in place, not ‘save as’ a new file with a version number.
6. Use Check-in comments to describe what changed in each version.

Best practices

• Use major versions for published; minor for drafts. Provides natural lifecycle distinction.
• Add Check-in comments. Version history without comments is just timestamps.
• Save in place, never ‘save as’ for a new version. Defeats version history.
• Pair with Document Status column. Major version + Status = Approved is clearer than version alone.

Common mistakes

• Version numbers in filenames AND in SharePoint history. Two systems drift; users get confused.
• ‘Save As’ creating duplicate files. Each is its own version-history-less orphan. Save in place.
• No Check-in comments. Version history is just dates. Useless for audit.

↑ Back to top ↑ Back to list

The most common naming sin: files named ‘Final’, ‘Final-v2’, ‘Final-FINAL’. They’re a sign the team isn’t trusting the system. Time to stop.

Every team has them. ‘Marketing-Strategy-Final.docx’. ‘Marketing-Strategy-Final-v2.docx’. ‘Marketing-Strategy-Final-REVIEWED.docx’. ‘Marketing-Strategy-Final-USE-THIS-ONE.docx’. The names tell the whole story: nobody trusts version history, so they encode status and sequence in the filename instead. The result is chaos.

The cure is twofold. First, trust SharePoint’s version history — it captures every change automatically, and Restore brings any version back in seconds. Second, use a Status column to mark documents as Draft, Approved, or Published. The status lives in metadata, not in the filename. Every user can see at a glance which documents are which, and search/Copilot can filter on it cleanly.

This one habit change — eliminating ‘Final’ from filenames — has outsized impact. It declutters libraries, makes search results readable, and stops users from second-guessing which copy is the real one. Even better, it’s contagious. When the team sees a clean, version-controlled library, they stop adding ‘Final’ themselves.

When you’ll use this

• When auditing a library full of ‘Final’, ‘Final-v2’, ‘FINAL-FINAL’ filenames.
• When training the team on Version History.
• When introducing a Document Status column.
• When refreshing a library that’s drifted into chaos.

How to do it

1. Audit: search the library for filenames containing ‘final’, ‘latest’, ‘v2’, ‘NEW’.
2. Show the team how Version History captures every change automatically.
3. Add a Document Status column (Draft, In Review, Approved, Published).
4. Rename files using the standard convention — strip out version markers.
5. Tag the renamed files with the right status.
6. Demonstrate Restore from version history so the team trusts it.
7. Make it culture — call it out gently when ‘Final’ creeps back in.

Best practices

• Trust the system. SharePoint records every save. You don’t need ‘v3’ in the name.
• Use a Status column to mark documents as Final. Status is metadata; the filename is identity.
• If two files have the same content, one is wrong. Pick the source of truth, archive the rest.
• Educate, don’t just rename. A bulk rename without behavioural change just creates a new layer of ‘Final’ files in six months.

Common mistakes

• Bulk renaming without changing behaviour. The team adds ‘Final’ back within months.
• No Status column. Without an alternative way to mark ‘this is the approved one’, users default to filenames.
• Treating ‘Final’ files as a naming problem. They’re a trust problem. Fix the root cause.

↑ Back to top ↑ Back to list

If you’re starting from scratch and don’t know what columns to add, this is the answer. The Core Five works for almost any library.

Most libraries don’t need 30 columns. They need 5 well-chosen ones. After years of building and rebuilding metadata schemas, the same five columns keep emerging as the foundation: Document Type, Department, Status, Owner, Keywords. Together, they answer the questions users actually ask: what is this, who does it belong to, where is it in its lifecycle, who owns it, and what is it about.

The Core Five works for almost every library — policies, procedures, project files, contracts, reports. You can add more columns for specific needs (Project Name, Phase, Due Date, Confidentiality), but start with the foundation. Master these five, and you’ve covered 80% of what most libraries ever need.

The biggest mistake is starting bigger. Libraries that launch with 15 columns from day one usually end up with 15 mostly-empty columns and frustrated users who stop tagging anything. Start with five, prove the value, add more only when the team agrees they’re needed. Less is more.

When you’ll use this

• When setting up any new SharePoint library.
• When you don’t know where to start with metadata.
• When standardising libraries across an organisation.
• When you want a defensible ‘this is what we always do’ metadata baseline.

How to do it

1. Add a Document Type column (Choice or Managed Metadata).
2. Add a Department column (Managed Metadata preferred for cross-site consistency).
3. Add a Status column (Choice with default ‘Draft’).
4. Add an Owner column (Person, single value).
5. Add a Keywords or Tags column (Multiple lines of text or Managed Metadata).
6. Make Document Type required at minimum.
7. Save and document the standard for the team.

Best practices

• Make Document Type required. Without it, half the value of the Core Five evaporates.
• Use the same column names everywhere. ‘Department’ across all libraries beats ‘Department’ here and ‘Dept’ there.
• Add to site templates. Every new library starts with the Core Five automatically.
• Refine after a few weeks of use. If the team asks for additional columns, add them. If columns aren’t being used, consider removing.

Common mistakes

• Starting with 15 columns instead of 5. Users get overwhelmed and stop tagging anything.
• Different starter sets for different libraries. Inconsistency now becomes inconsistency forever.
• Skipping Owner. The single most useful column for ongoing accountability.

↑ Back to top ↑ Back to list

Some users won’t stop using folders. Folder Default Values make peace: keep folders, but get metadata for free.

Folder Default Values is a feature that lets you assign automatic metadata values to a folder. Drop a file into the ‘HR Policies’ folder, and SharePoint automatically tags it with ‘Document Type: Policy’ and ‘Department: HR’ — no user action required. The folder becomes a bridge between old folder-thinking and new metadata-thinking.

This is the right tool for teams transitioning from a folder-heavy mindset to a metadata-driven library. You don’t have to fight the habit; you embrace it and use it. Users keep dropping files into folders the way they always have, and the library gains structured metadata automatically.

It’s also useful for high-volume bulk uploads. Set up the right folders with the right defaults, drop in 500 files, and they’re all properly tagged in seconds. Combined with Quick Edit / Grid View for any corrections, this is one of the fastest ways to migrate a folder-heavy shared drive into a metadata-rich SharePoint library.

When you’ll use this

• When users insist on using folders and you want metadata anyway.
• When migrating from a folder-heavy shared drive to SharePoint.
• When bulk uploading files where the folder structure carries meaning.
• When you want to reduce the manual tagging burden on users.

How to do it

1. Open the library and go to Library settings.
2. Open Column default value settings.
3. Pick a folder.
4. Set default values for one or more columns (e.g. Document Type = Policy, Department = HR).
5. Save.
6. Test by uploading a file to that folder and confirming metadata is applied.
7. Repeat for other folders with their respective defaults.

Best practices

• Best ‘bridge’ for users who refuse to stop using folders. Don’t fight the habit; channel it.
• Speed up bulk uploads. Folder defaults turn 500 file uploads into 500 properly-tagged files.
• Document the folder defaults. Future admins need to understand why files in ‘HR Policies’ all show ‘Policy’ tag.
• Combine with required columns and grid view. Defaults set the values; required columns enforce them; grid view fixes anomalies.

Common mistakes

• Setting up defaults but not telling anyone. Users wonder why some files have tags and others don’t.
• Defaults that contradict reality. If users put non-policies in ‘HR Policies’, the default tags them wrong.
• Relying on defaults instead of teaching metadata. Defaults are a transition tool, not a permanent substitute.

↑ Back to top ↑ Back to list

Grid View turns the library into a spreadsheet for fast bulk metadata editing. The single biggest time-saver for library cleanup.

Grid View (sometimes called Quick Edit) displays the library as an editable spreadsheet. Click cells to edit values directly, drag to fill, copy and paste — exactly like Excel. Compared to opening each file’s properties one at a time, Grid View is 10x faster for bulk metadata updates.

The classic use case is library cleanup. Combine Grid View with a ‘Missing Metadata’ view (M-34) and you can fill in blanks across hundreds of files in minutes. Filter to files needing updates, switch to Grid View, edit cells like a spreadsheet, save. Pair this with copy-paste for repeated values and drag-fill for sequences, and what looked like a multi-day cleanup becomes a 30-minute task.

Grid View also makes onboarding new metadata easier. When you add a new column to a library, you can switch to Grid View and tag every existing file with the right value in one editing session. Without Grid View, you’d need to open each file individually — for libraries with thousands of files, this is the difference between feasible and infeasible.

When you’ll use this

• When you have many files needing metadata updates.
• After bulk uploads that need tagging.
• When cleaning up a library with missing metadata.
• When adding a new column and backfilling existing files.

How to do it

1. Open the library.
2. Switch to Grid View (or click Edit in grid view in the toolbar).
3. Click any cell to edit its value directly.
4. Use Tab and Enter to move between cells like a spreadsheet.
5. Use copy-paste for repeated values, or drag the fill handle to fill down.
6. Click Exit grid view when done — changes save automatically.
7. For best results, pair with a ‘Missing Metadata’ view first to focus on what needs work.

Best practices

• Use drag-to-fill for repetitive values. 5 seconds beats 5 minutes.
• Pair with Missing Metadata view. Focus the editing on what actually needs fixing.
• Use keyboard shortcuts (Tab, Enter). Faster than mouse for sequential editing.
• Test on a small batch first. Confirm changes look right before mass-updating.

Common mistakes

• Editing one file at a time. Grid View is 10x faster for any bulk task.
• Exiting Grid View without saving. Changes do save, but always verify before closing.
• Mass updates without checking results. Mistakes propagate. Test a few rows, verify, then scale.

↑ Back to top ↑ Back to list

The Property Pane lets you edit one file’s metadata without leaving the library view. Quick changes without losing context.

When you click a file in a library and look to the right, you see the Property Pane (sometimes called the Details pane) — a panel showing the file’s metadata, recent activity, and editable properties. Unlike Grid View, which is for bulk editing, the Property Pane is for single-file edits where you want to keep the rest of the library visible.

The classic use case is targeted updates. You’re scanning the library, notice one file missing a Status tag, and want to fix it without losing your place. Click the file, open the Property Pane, update the Status, close the pane. The file is fixed; you didn’t navigate away from your view.

It’s also useful for quick reference. Hovering over the file shows the Property Pane with a preview, file details, and recent activity (who edited, when). Useful for verifying a file’s identity before opening it, or checking who last touched it. A small feature that quietly adds up to a lot of saved time.

When you’ll use this

• When you need to update one file’s metadata without losing context.
• When verifying a file’s properties or recent activity.
• When you want a preview without opening the file.
• For quick spot-check edits during a library review.

How to do it

1. Click a file once to select it (don’t double-click — that opens the file).
2. Click the i icon in the top-right of the library, or look at the right-hand pane that appears.
3. Edit any visible column value directly in the pane.
4. Click outside the pane or press the i icon again to close.
5. Use the pane for previews — a thumbnail/preview appears for many file types.

Best practices

• Use Property Pane for one-off fixes. Quicker than opening the file’s full edit form.
• Use Grid View for bulk edits. Wrong tool for one — but right tool for many.
• Pair the pane with views. Property Pane shows file details while you stay in your filtered view context.
• Preview before opening. Saves you from opening the wrong file.

Common mistakes

• Using Property Pane for bulk edits. Slow. Use Grid View for anything more than 5 files.
• Forgetting the pane exists. Many users never realise quick metadata edits are right there.
• Mass-edits one-by-one. 50 single edits via Property Pane is 50 minutes; Grid View is 5.

↑ Back to top ↑ Back to list