The Document Lifecycle

L-02

Create a Document from a Template

Templates save time, enforce consistency, and embed standards by default. Use them well and your team’s documents look professional without effort.

A template is a pre-built starting point — a document with the structure, formatting, branding, and standard sections already in place. Instead of starting from a blank page (or copying yesterday’s document and forgetting to delete the old client’s name), you start from a template that has everything correctly set up.

Most organisations have templates for the documents they produce repeatedly: meeting agendas, project proposals, client reports, policies, procedures, internal memos. The good ones live in a central location where everyone knows to find them. The bad ones live on someone’s desktop and get used twice before being forgotten.

SharePoint can host templates at site level (this site uses these templates) or library level (this library has these starting points). When set up well, users see template options when they click ‘New’ — no hunting required. The template gets copied automatically into a fresh document, and the original stays clean for the next person.

Why this matters

Templates aren’t just about looking professional — they’re about embedding good practice into the path of least resistance:

Templates make standards default. If your client report template has a ‘Risks’ section, every report has one. No reminders required.

Templates speed up routine work. A meeting agenda template saves 5 minutes per meeting. Across an org, that’s hundreds of hours a year.

Templates prevent embarrassing mistakes. No more last year’s pricing accidentally going to a new client. No more wrong logos. No more inconsistent formatting that signals you don’t care.

When you’ll use this

When you create the same kind of document repeatedly (proposals, reports, agendas, policies).
When you want consistent branding and structure across documents.
When you onboard new team members and want them to produce work that fits in.
When you’ve noticed your team copying old documents as starting points and forgetting to remove old content.

How to do it

Open the SharePoint library where templates are stored (or the site’s template gallery).
Click New and select the relevant template type.
A new file is created based on the template — the original stays untouched.
Fill in the required sections first (title, owner, date, version).
Save the file to the correct working location with a descriptive name.
Add any required metadata in the file’s properties (department, document type, etc.).
Share a link with collaborators if you need feedback.

Best practices

Store templates in one well-known location. If templates are scattered across desktops and OneDrives, people will copy old documents instead.
Assign template owners. Every template should have someone responsible for keeping it current.
Review templates quarterly. Branding changes, standards evolve, sections become outdated. A 5-minute review every quarter prevents 5 years of drift.
Include guidance text inside templates. Italicised instructions in [brackets] or commented-out blocks tell users exactly what to fill in.

Common mistakes

Letting users edit the template directly. Lock down the template; users should create new files from it, not edit the original.
Storing templates in someone’s personal folder. When that person leaves, the template’s source of truth vanishes.
Making templates so prescriptive nobody uses them. A 30-page proposal template scares people off. Keep templates lean.

Clean up the mess. Keep it clean.

The File Sanity Kit uses the Container Method™ to audit, restructure, and future-proof SharePoint. Not a naming convention — a thinking system.

Get the File Sanity Kit

L-03

Check Out a File

Check-out locks a document so only you can edit it. It’s a tool for controlled changes, not everyday collaboration — but knowing when to use it matters.

Check-out is a SharePoint feature that lets you ‘reserve’ a file for exclusive editing. While a file is checked out to you, nobody else can change it. They can read it (the last checked-in version), but they can’t make edits until you check it back in. It’s the opposite of co-authoring, where multiple people work on the same file simultaneously.

For most everyday work, you don’t need check-out — co-authoring is faster, smoother, and how Microsoft 365 is designed to work. But check-out has a place: when you’re making sweeping changes, restructuring a document, or working on something where someone else’s parallel edits could cause real problems. Policies being completely rewritten, master templates being updated, controlled documents going through formal review — these are good check-out candidates.

The risk with check-out is forgetting to check the file back in. If you check out a file on Friday and go on leave for two weeks, your colleagues are locked out the whole time. Some libraries enforce automatic check-out for every edit; this almost always causes more friction than it prevents. Use check-out deliberately, not as a default.

When to use check-out vs co-authoring Co-authoring (the default) is right for almost all collaboration: meeting notes, working drafts, team documents, anything where multiple people contributing makes the work better. Check-out is right when one person needs to make significant changes without interruption — and the team needs to know not to edit in parallel.

When you’ll use this

When you’re making major structural changes to an important document.
When you’re working on a controlled document (policy, procedure) and want to prevent parallel edits.
When you’re updating a template that others will use.
When you need to ensure no one else changes a file mid-edit (e.g. critical data updates).

How to do it

Open the SharePoint library where the file lives.
Select the file (don’t open it yet).
Click More options (the three dots) and select Check out.
The file’s icon changes to show a small green arrow — it’s now checked out to you.
Open the file and make your changes.
Save as you go (AutoSave still works for checked-out files).
When done, return to the library, select the file, and choose Check in.
Add a check-in comment describing what you changed, then confirm.

Best practices

Use check-out sparingly. Co-authoring is the default for a reason. Reserve check-out for genuinely controlled situations.
Check files in promptly. Don’t leave files checked out overnight or before leave. Other people need access.
Always add a check-in comment. ‘Updated section 3 with new policy’ is far more useful than no comment.
Communicate when checking out shared files. A quick chat message (‘I’m rewriting the procedure today, please don’t edit’) saves confusion.

Common mistakes

Forgetting to check files back in. Most ‘I can’t edit this’ helpdesk tickets are about a forgotten check-out from last month.
Enforcing check-out on busy collaborative libraries. Forces serial editing where parallel editing would be faster.
Treating check-out as locking for security. It’s not a permission control. Use proper permissions for sensitive content.

L-04

Check In a File

Checking in releases a file back to the team and creates a clean version with a description. It’s also where major vs minor versioning gets decided.

Checking in is the other half of check-out. When you’re done with your changes, you check the file back in — which makes your edits visible to everyone, releases the lock, and creates a new version in the file’s history. It also gives you the chance to add a comment describing what you changed, which becomes part of the audit trail.

Check-in is also where you make a decision: is this a minor version (a small update, still being refined) or a major version (a significant, formally released update)? Minor versions are often labelled 0.1, 0.2, 0.3 — drafts in progress. Major versions are 1.0, 2.0, 3.0 — published or approved versions. Not every library uses major/minor; smaller teams often just have major versions.

The check-in comment matters more than people think. Six months from now, someone (possibly you) will look at version history and try to understand what happened. ‘Updated’ tells them nothing. ‘Replaced section 4 with new policy following Legal review’ tells them everything they need to know.

When you’ll use this

When you’ve finished editing a checked-out file.
When you need to make your changes visible to others.
When you’ve reached a meaningful milestone in a long-running edit.
Before going on leave, so the file isn’t locked while you’re away.

How to do it

Open the SharePoint library where the checked-out file lives.
Select the file (the green arrow shows it’s checked out to you).
Click More options and select Check in.
Choose major version (significant, released change) or minor version (small, still-in-progress update) if the library uses both.
Add a clear check-in comment describing what changed.
Confirm to release the file.
Verify the latest version opens correctly for other users.

Best practices

Always write a meaningful comment. Future you will be grateful. ‘Done’ is not a meaningful comment.
Use major versions for released, approved content. Minor versions for drafts and in-progress work.
Don’t check in partial work as a major version. Save it as minor (or keep it checked out) until it’s actually ready.
Sanity-check after check-in. Open the file once after check-in to make sure formatting and content saved as expected.

Common mistakes

Skipping the comment. Version history without comments is just a list of dates. Useless for audit.
Checking in everything as a major version. Every tiny tweak becomes ‘v.4.0’, ‘v.5.0’, ‘v.6.0’. Major versions lose their meaning.
Forgetting to check in at all. The file stays locked and your colleagues can’t edit. Check the library before you log off.

L-05

Require Document Approval

For controlled content, you need a way to ensure documents are reviewed and approved before going live. Approval workflows make this systematic, not informal.

Some documents are too important to publish casually. Policies, procedures, controlled templates, formal reports — these need to be reviewed by the right people before they become ‘official’. Without a structured approval process, this happens in an unreliable mix of email chains, verbal agreements, and ‘I think Sarah approved it last week’. Document approval makes it formal, auditable, and consistent.

SharePoint’s built-in content approval lets a library require that every new or updated file be approved before it’s visible to most users. While in ‘pending approval’ status, only the document’s author and approvers can see it. Once approved, it becomes the visible ‘live’ version. If rejected, the author gets feedback and tries again.

For more complex needs — multiple approvers, conditional logic, reminders, escalation — Power Automate can build proper approval workflows. But for most teams, the built-in content approval setting on a library covers what’s needed without any custom development.

Why this matters

Document approval isn’t just bureaucracy — it’s how you keep controlled content controlled:

Approval creates an audit trail. ‘Approved by [name] on [date]’ is recorded automatically. No more ‘I’m sure someone signed off on this’.

Approval prevents premature publication. Drafts can’t accidentally become live policies. The system enforces the boundary.

Approval forces clarity about ownership. Who approves what? Who’s accountable? Setting up approval makes you answer these questions explicitly.

When you’ll use this

When documents need formal review before becoming live (policies, procedures).
When you have a small group of approvers and a larger group of authors.
When you need an audit trail showing who approved what and when.
When you’ve inherited a library full of ‘approved’ content with no record of when or by whom.

How to do it

Open the library and go to Library settings.
Open Versioning settings.
Enable Require content approval for submitted items.
Decide who can see drafts pending approval (typically: just authors and approvers).
Set up an approval group — the people who can approve content.
Train authors to submit for approval rather than publishing directly.
Approvers receive notifications and can approve/reject from the document.
For more complex needs, build a Power Automate flow with multiple steps.

Best practices

Keep the approver group small. 1-2 people per document type. More approvers means more delays and unclear ownership.
Use a dedicated ‘controlled documents’ library. Don’t mix controlled content with everyday team work — different rules apply.
Include required metadata in the approval process. Owner, review date, classification — capture them at submission, not later.
Document the approval rules. What does ‘approved’ mean? Reviewed for accuracy? Legally signed off? Make it explicit so approvers know what they’re confirming.

Common mistakes

Setting up approval but not enforcing it. If the rule is ‘documents need approval but anyone can publish without it’, the rule doesn’t exist.
Making everyone an approver. Defeats the purpose. Restricts approval to people accountable for the content.
Approving everything by default. Approvers should actually review. Otherwise, why have approval?

Who owns what. What the rules are.

The Governance Starter Kit gives you a plain-English governance system for real organisations. Roles, library standards, sharing rules, and a monthly routine that takes under 90 minutes.

L-06

Approve or Reject a Document

Approving or rejecting a document is more than clicking a button — it’s a decision that shapes what becomes ‘official’ in your organisation. Doing it well matters.

When a library uses content approval, documents arrive in your queue waiting for a decision: approve (it becomes official and visible to everyone) or reject (it stays hidden, with feedback to the author). This is a real decision, not a rubber stamp — what you approve becomes the published, trusted version that the rest of the organisation will rely on.

Good approvers aren’t gatekeepers — they’re quality assurance. They check that the document is accurate, formatted correctly, has the required metadata, links work, and meets whatever standard the library demands. They reject with specific feedback so the author can fix issues quickly, rather than vague ‘this isn’t quite right’.

The thing approvers underestimate is the long tail. Once a document is approved, it might be referenced for years. A typo in a policy document approved three years ago has caused thousands of cases of confusion. Five minutes of approver attention saves hundreds of hours of downstream rework.

When you’ll use this

When a document is waiting for your approval in a controlled library.
When you’re the named approver for a document type or process.
When someone has submitted a draft for sign-off via Power Automate or built-in approval.
When you need to reject a draft and request changes before approval.

How to do it

Open the document from SharePoint (don’t review a downloaded copy — you might miss the latest changes).
Review the content against your organisation’s standards.
Check required metadata: owner, review date, classification, document type.
Verify links work, formatting is consistent, and version is correct.
Click Approve or Reject from the file menu (or the workflow task).
If approving, add a brief confirmation comment.
If rejecting, add specific, actionable feedback (what to fix, by when).
After approval, confirm the document is visible to its intended audience.

Best practices

Use a checklist. Accuracy, formatting, links, metadata, version. A 60-second checklist catches 90% of issues.
Reject with specifics. ‘Section 3 needs the updated procedure from policy 4.2’ is actionable. ‘Not quite right’ is not.
Don’t approve under time pressure. If you can’t review properly today, say so. Approving without reading is how mistakes ship.
Communicate decisions clearly. The author should know exactly what was approved, when, and what (if anything) needs to happen next.

Common mistakes

Approving everything to clear the queue. The whole point of approval is gating. Skipping the gate makes it ceremony, not control.
Vague rejections. Authors guess what ‘fix it’ means. They guess wrong. They resubmit. You reject again. Specific feedback ends the cycle.
Treating approval as a personal opinion check. Approve against documented standards, not personal preference.

Who owns what. What the rules are.

The Governance Starter Kit gives you a plain-English governance system for real organisations. Roles, library standards, sharing rules, and a monthly routine that takes under 90 minutes.

L-07

Publish a Final Document

Publishing turns a draft into the official, current, trusted version. Done well, it’s clear to everyone what the source of truth is.

Publishing a document means moving it from ‘draft’ status to ‘official’. In SharePoint terms, this often means creating a major version (1.0, 2.0), updating metadata to reflect approved status, possibly moving the file to a ‘Final’ or ‘Published’ library, and notifying the audience that the new version is live.

The reason ‘publishing’ deserves its own card is that it’s where most teams break down. Documents get approved, but no one tells anyone. Or they get moved to a ‘Published’ folder, but the old draft link is still in the team wiki. Or the new version is live, but three people are still emailing around the previous version. Publishing is fundamentally a communication problem, not just a file-moving problem.

A clean publishing process has three components: the document is in the official location with the official metadata, the audience knows where to find it (and trust it), and old/superseded versions are clearly retired. If any one of these is missing, you have not really published — you’ve just saved another file.

When you’ll use this

When a document has been approved and is ready for general use.
When you’re updating a previously published document with significant changes.
When you need to communicate a new policy, procedure, or template to a wide audience.
When you’re finalising a piece of work and need to make it accessible to others.

How to do it

Confirm the document is approved and the latest version is correct.
Update the document’s metadata to reflect ‘final’ status (e.g. Status = Approved, Version = 2.0).
Publish a major version if your library uses major/minor versioning.
Move the file to the official ‘Final’ or ‘Published’ library if your process separates draft and final locations.
Update navigation, links, or wiki entries to point to the new version.
Notify the audience with the link to the published version (Teams post, email, intranet announcement).
Retire or archive the old version so nobody mistakes it for the current one.

Best practices

Publish one source of truth, not multiple copies. The official version lives in one place; everywhere else links to it.
Use clear status metadata. ‘Approved’, ‘Effective from [date]’, ‘Next review [date]’. These are fields, not just words in the filename.
Lock down the published library to read-only for most users. Editors can update, viewers can read. Stops accidental edits to live documents.
Always communicate publishing. A document nobody knows exists isn’t published. It’s a file in a folder.

Common mistakes

Forgetting to retire old versions. Two ‘current’ policies in two locations is worse than no policy at all.
Publishing without notifying anyone. The team keeps using the old version because they don’t know there’s a new one.
Publishing to a folder nobody can find. If the published location isn’t in your standard navigation, it might as well not exist.

Want a clean publish-and-retire process?

The Governance Starter Kit gives you a plain-English governance system for real organisations. Roles, library standards, sharing rules, and a monthly routine that takes under 90 minutes.

L-08

Restore a Previous Version

Mistakes happen. Restore lets you roll back to a previous version of a file in seconds — but only if you know it exists.

Every time you save a file in SharePoint or OneDrive, the previous version is kept. By default, most libraries keep at least the last 500 major versions and a similar number of minor versions if used. This means: if something gets accidentally deleted, overwritten, or otherwise broken, you can almost always recover.

Restoring a previous version is one of the most-asked-about features in Microsoft 365, and one of the least-known. People panic, search frantically, sometimes recreate documents from scratch — and never realise the previous version is two clicks away. Knowing this exists changes how you work: you stop being afraid of changes, because rollback is easy.

Restoring brings back an entire version of the file as it existed at that point in time. If you only need to recover one paragraph, you can open the previous version, copy what you need, and close it without restoring. If you need the whole file rolled back, restore replaces the current version while keeping the (broken) version in history too — so even restore is reversible.

The 30-day grace period Even files in the Recycle Bin can usually be restored for up to 93 days. So when someone says ‘I deleted it last week’, the answer is almost always ‘we can get it back’. Knowing this changes how confidently your team can work.

When you’ll use this

When someone has overwritten content that shouldn’t have been changed.
When you’ve accidentally deleted important content from a file.
When you need to revert to an earlier draft to recover content.
When a formatting change has broken a document and you need to roll back.

How to do it

Open the file in SharePoint or OneDrive.
Click More options (the three dots) on the file in the library, or open the file menu.
Select Version history.
Review the list of versions, dates, authors, and check-in comments.
Click a version to open it (this opens it in read mode without affecting the current version).
If it’s the right version, click Restore to make it the current version.
Confirm the restore.
Notify your team if the restore affects content others are using.

Best practices

Restore is non-destructive. The current version becomes a ‘previous version’ too — you can always restore again if needed.
Use check-in comments so version history is meaningful. Without comments, you’re just guessing which version had the right content.
For controlled documents, restore to draft and re-approve. Don’t bypass the approval process just because you’re rolling back.
Train your team to restore instead of recreate. ‘I’ll just rewrite it’ is the wrong answer when the previous version is one click away.

Common mistakes

Recreating content from scratch. Almost always unnecessary. Check version history first.
Downloading old versions and saving them as new files. Breaks version history. Restore in place instead.
Not knowing the feature exists. Train your team. This single feature prevents huge amounts of stress.

L-09

View Version History

Version history is the audit trail of every file. Knowing how to read it gives you confidence in what changed, when, and by whom.

Every time someone saves a file in SharePoint or OneDrive, the system records a new version. The version list shows the version number, date and time, author, and (if added) a check-in comment. You can open any version to see what the file looked like at that point, restore it, or compare it to the current version.

For controlled documents, version history is essential — it’s your audit trail. Auditors will ask ‘who approved this on what date?’ and version history (combined with check-in comments and approval records) is how you answer. Even for everyday work, version history is your safety net: you can always recover, always check what changed, always understand the file’s evolution.

The quality of version history is entirely shaped by how people use the system. Files saved without comments produce useless history. Files with meaningful check-in comments produce a real audit trail. This is why ‘always add a check-in comment’ isn’t just a tip — it’s the difference between version history that works and version history that’s there in name only.

When you’ll use this

When you need to audit who changed what and when.
When you’re investigating an issue and need to understand a file’s history.
When you want to find a specific change and possibly restore it.
When you’re doing a quarterly review of a controlled document set.

How to do it

Open the SharePoint library or OneDrive folder.
Select the file (don’t open it yet).
Click More options and select Version history.
Review the list: version number, date, author, comments.
Hover over a version to see a preview, or click to open in read mode.
Use comments to understand what each version contained.
Restore, copy, or just review — version history doesn’t change the current file.

Best practices

Turn on versioning in every important library. Default settings often only keep major versions; consider enabling minor versions for active drafts.
Insist on check-in comments. Without them, version history is just a list of dates.
Use version history before recreating content. ‘I’ll start over’ is almost always the wrong answer.
For audit, export version metadata. If your auditor wants a record, screenshot or export the version history table.

Common mistakes

Disabling versioning to save storage. Storage is cheap; data loss is expensive.
Saving ‘final v2’ files instead of using versioning. Defeats the purpose. Save in place, let SharePoint handle versions.
Not training users to add check-in comments. Without comments, version history exists but is unusable.

L-10

Delete Old Versions

Sometimes you need to clean up version history — but most of the time, you shouldn’t. Deletion is permanent and removes audit trail.

Version history can grow large for actively-edited files. A document edited daily for two years might have hundreds of versions. Each version uses storage (though often small), and the long history can be hard to navigate. Some teams want to clean this up — and SharePoint allows it, but it’s worth pausing before you do.

The trade-off is straightforward: deleting old versions reduces clutter and storage, but removes audit trail. For everyday working files, that’s probably fine. For controlled documents (policies, procedures, regulated records), it’s almost certainly not — and may be a compliance violation depending on your industry.

A better approach in most cases is to set version limits at the library level, so SharePoint automatically keeps the most recent N versions and removes older ones. This is consistent, predictable, and doesn’t require manual intervention. Manual deletion of specific versions should be rare and deliberate — and never done on regulated content without checking retention policies first.

When you’ll use this

When a library has unnecessarily large version history slowing things down.
When you need to free up storage on a heavy-use library.
When you’re cleaning up a library after a major restructure.
Almost never, for regulated or controlled content — check retention policies first.

How to do it

First, confirm the library has versioning enabled and review your retention requirements.
Open the file’s Version history.
If you have permission, you’ll see a delete option next to older versions.
Confirm exactly which versions you’re deleting.
Keep at least one approved/published version even when cleaning up.
For systematic cleanup, prefer setting version limits at library level over manual deletion.
Document any deletions if your governance requires it.

Best practices

Use version limits, not manual deletion. Set the library to keep e.g. 50 major versions and SharePoint handles cleanup automatically.
Never delete versions of regulated content without checking retention. Some industries require keeping every version for years.
Keep approved/published versions. Even in a cleanup, the official versions should remain.
Restrict who can delete versions. Most users shouldn’t have this permission.

Common mistakes

Deleting versions to ‘tidy up’ regulated content. Could create compliance violations. Check first.
Deleting all versions including approved ones. Destroys audit trail entirely.
Manual deletion when version limits would do the job. Inefficient and error-prone.

Who owns what. What the rules are.

The Governance Starter Kit gives you a plain-English governance system for real organisations. Roles, library standards, sharing rules, and a monthly routine that takes under 90 minutes.

L-11

Set Version Limits

Version limits let SharePoint automatically manage version history at scale. Set them once and version cleanup becomes invisible.

Version limits are a library-level setting that tells SharePoint: ‘keep the last N major versions and the last M minor versions’. Once a file goes beyond those limits, the oldest versions are automatically removed. This is the right way to manage version cleanup in most libraries — predictable, consistent, no manual intervention.

Default version limits are typically generous (often 500 major versions). For most libraries, this is fine — storage isn’t usually the bottleneck. But for very high-churn libraries, or libraries with legitimate compliance constraints, you might want to tighten the limits, or in some cases, loosen them.

The decision is about balancing storage, audit trail needs, and what level of history is actually useful. A meeting notes library might be fine with 20 versions per file. A controlled policy library might need 100 majors with no automatic deletion at all. Set them once, document the choice, and move on.

When you’ll use this

When you’re setting up a new library and want to lock in version behaviour.
When a library’s version history is growing faster than expected.
When you’re aligning a library with retention or compliance requirements.
When you want predictable, automated version management instead of manual cleanup.

How to do it

Open the library and go to Library settings.
Open Versioning settings.
Set how many major versions to keep (e.g. 50, 100).
If using minor versions, set how many to keep per major version.
Save the settings.
Test on a non-critical library first if you’re tightening from generous defaults.
Communicate the change to library owners and authors.
Review storage and version behaviour after a few weeks.

Best practices

Match limits to library purpose. Working drafts: tight limits. Controlled documents: generous limits.
Document the limits in your governance. ‘This library keeps last 50 majors’ should be written down somewhere people can find.
Don’t set limits below your retention requirement. If you’re required to keep 7 years of versions, the library has to support that.
Combine limits with approvals for controlled libraries. Approval ensures only meaningful versions are major; limits keep the count manageable.

Common mistakes

Setting too-tight limits on important content. You might lose history before you realise the limit was too low.
Setting different limits in libraries that should match. Inconsistency confuses users and complicates governance.
Forgetting to set limits at all. Defaults work for most cases but might not suit your specific workload.

Who owns what. What the rules are.

The Governance Starter Kit gives you a plain-English governance system for real organisations. Roles, library standards, sharing rules, and a monthly routine that takes under 90 minutes.

L-12

Convert to PDF

PDFs are the format for read-only, fixed-layout, distribution-ready documents. Knowing when (and when not) to convert matters.

PDF (Portable Document Format) is a fixed-layout file format designed to look the same on every device, regardless of what software opened it. It’s the standard for documents you want to share without inviting edits — proposals, reports, signed contracts, brochures, anything you want to display rather than collaborate on.

Microsoft 365 makes converting to PDF easy. Word, Excel, and PowerPoint all have ‘Export as PDF’ or ‘Save as PDF’ built in. The result is a self-contained file that anyone can open in a browser, mobile device, or PDF reader. The trade-off is that PDFs aren’t designed for editing — they’re designed for distribution. Editing a PDF is possible but clunky compared to editing the original Word or PowerPoint file.

The most common mistake is converting too early. People create a Word document, immediately save as PDF, and then have no editable source when they need to make changes. Keep both: the editable Word/Excel/PowerPoint file as the source of truth, and the PDF as the distribution copy. When you need to update, edit the source and re-export.

When you’ll use this

When you’re distributing a final document and want to discourage editing.
When you’re sharing externally with people who may not have Office.
When the document needs to look exactly the same on every device.
When you need to digitally sign or stamp the document.

How to do it

Open the document in Word, Excel, or PowerPoint.
Choose File → Export → Create PDF/XPS Document (or Save As → PDF).
Check options: include markup, page range, image quality, accessibility tags.
Save the PDF to the appropriate library — usually alongside or near the source file.
Verify the PDF looks correct on multiple devices before distributing.
Share the PDF link with viewers (don’t email the file as an attachment).
Keep the editable source file accessible for future updates.

Best practices

Always keep the editable source. The PDF is the output. The Word/Excel/PowerPoint file is the source. Don’t lose the source.
Check accessibility before publishing. Headings, alt text, reading order. PDFs that aren’t accessible exclude users.
Use consistent file naming. If your source is ‘Q3_Strategy.docx’, your PDF should be ‘Q3_Strategy.pdf’. Same root, different extension.
Replace, don’t accumulate. When you publish a new version, retire the old PDF — don’t let multiple versions float around.

Common mistakes

Losing the source file. ‘Where’s the editable Word doc?’ is the most common file-recovery question. Keep both.
Distributing PDFs with sensitive metadata. Author name, comments, tracked changes, version history — PDFs can leak more than you think. Check before publishing.
Treating PDF as a permanent format. PDFs are great for distribution but harder to update. Plan your editing workflow around the source file.

L-13

Password Protect a Document

Sometimes a document needs an extra lock — a password that recipients need to open it. Use sparingly, never as a substitute for proper permissions.

Password protection is a feature in Word, Excel, PowerPoint, and PDFs that requires recipients to enter a password before they can open the file. It adds a layer of access control independent of SharePoint permissions — useful when a file might travel outside your normal access controls (downloaded, emailed, copied).

The right use case for password protection is narrow. Imagine a sensitive HR document that has to be emailed to an external lawyer. The recipient won’t have access to your SharePoint, so SharePoint permissions don’t help. A password gives you a basic gate: only someone with the password can open the file.

What password protection is not good for is everyday access control inside your organisation. SharePoint permissions are far better — they’re enforceable, auditable, easy to manage, and don’t require anyone to remember a password. If you find yourself password-protecting files for internal sharing, you’re working around a permissions problem instead of solving it.

Never email the password with the file If a sensitive file needs a password, the password must travel through a different channel. Email the file. Text the password. Or: phone the recipient with the password. Sending the password in the same email as the file defeats the protection entirely — anyone who intercepts the email gets both.

When you’ll use this

When you need to email a sensitive file to someone outside your SharePoint permissions.
When you’re sharing a document that might be forwarded and you want a basic gate on access.
When your tenant’s policies require password protection for certain content classifications.
Almost never for internal sharing — use SharePoint permissions instead.

How to do it

Open the file in the desktop app (Word, Excel, PowerPoint).
Go to File → Info → Protect Document → Encrypt with Password.
Set a strong password (long, random, not reused from other systems).
Save the file. The password is now required to open it.
Save the file back to SharePoint or send the protected copy.
Communicate the password through a different channel (text, phone, separate email).
Remember: if you forget the password, the file is essentially lost.

Best practices

Prefer SharePoint permissions over passwords for internal sharing. Permissions are easier to manage and audit.
Use strong, unique passwords. A weak password is barely a deterrent.
Never put passwords in the same email or message as the file. Defeats the protection.
Document who has the password (but not the password itself). So you can revoke access if needed.

Common mistakes

Using passwords for internal access control. SharePoint permissions are better for everything inside your org.
Reusing passwords across files. One leaked password compromises every file with that password.
Forgetting the password. There’s no ‘forgot password’ link. Lost passwords = lost files.

L-14

Mark as Final

‘Mark as Final’ is a soft signal that a document is complete. It’s a status, not a security measure — but it’s still useful when used consistently.

Microsoft Office has a ‘Mark as Final’ feature that puts a document into read-only mode and shows a banner saying ‘this document is final’. It’s a hint to the reader: don’t edit this casually. It can be overridden with one click — so it’s not real protection — but as a soft signal, it works fine.

More important than the feature itself is the underlying concept: documents need clear status. A document that’s been marked as final, moved to a final library, given a ‘Status: Approved’ tag, and published with a major version is unambiguously final. A document called ‘final_v3_REVIEWED.docx’ floating around in someone’s email is not final, regardless of its name.

In a well-governed SharePoint environment, ‘final’ is multiple signals working together: the file is in the right library, has the right metadata, has been approved, has a major version number, and (optionally) is marked as final in Word. Any one of these alone is weak. Together, they make the file’s status obvious to everyone.

When you’ll use this

When you’ve completed a document and want to discourage further editing.
When you’re publishing a final version and want a soft ‘this is done’ signal in the file itself.
When the document has been approved and is now the source of truth.
When you want a visible cue in Word that the document is complete.

How to do it

Open the file in the desktop app (Word, Excel, PowerPoint).
Go to File → Info → Protect Document → Mark as Final.
Save and close the document.
When reopened, Word shows a banner: ‘This document is final’.
To edit, the user clicks ‘Edit Anyway’ (so this isn’t real protection).
Save the file back to SharePoint.
Pair with library-level status (Approved metadata, major version, correct location) for full effect.

Best practices

Use ‘Mark as Final’ as a status signal, not as security. One click overrides it.
Pair with proper governance. Final = right location + right metadata + approved + major version. Not just a banner.
Be consistent. If ‘Mark as Final’ is part of your process, use it on every approved doc — not randomly.
Use library-level read-only permissions for real protection. Allows reading but not editing.

Common mistakes

Treating ‘Mark as Final’ as security. It’s not. Use SharePoint permissions for actual restriction.
Marking everything as final, even drafts. Devalues the signal. Use it deliberately.
Forgetting to remove the marking when the document gets a new edit cycle. Leaves a confusing ‘final’ banner on a working draft.

L-15

Add a Watermark

A watermark visually labels a document — DRAFT, CONFIDENTIAL, INTERNAL. Used well, it prevents the wrong document from being mistaken for the right one.

A watermark is a faded label that appears on every page of a document — text like ‘DRAFT’, ‘CONFIDENTIAL’, ‘INTERNAL ONLY’, or ‘COPY’. It’s purely visual; it doesn’t restrict anything technically. But the visual cue does its job: someone who picks up a printed copy or scrolls through a PDF immediately knows what kind of document they’re looking at.

Watermarks matter most when documents leave their context. A draft that’s been printed and left on a desk should still say ‘DRAFT’. A confidential report that’s been emailed externally should still say ‘CONFIDENTIAL’. The watermark is a fail-safe for the inevitable moment when a document is seen outside its intended setting.

Increasingly, organisations use sensitivity labels instead of (or alongside) watermarks. Sensitivity labels are tied to Microsoft 365 Information Protection — they apply watermarks automatically, control encryption, restrict access, and travel with the file. If your tenant supports them, they’re the better option. Watermarks alone are still useful for low-sensitivity content where you just need a visible status cue.

When you’ll use this

When a document is in draft and you want to make sure it isn’t mistaken for a final version.
When a document contains confidential information and might travel.
When your organisation requires watermarks on certain document classifications.
When you want a visible ‘do not redistribute’ signal on internal-only content.

How to do it

Open the file in Word.
Go to Design → Watermark.
Choose a built-in option (DRAFT, CONFIDENTIAL, etc.) or create a custom one.
For PDFs and other formats, watermarks are added differently — check the relevant tool.
If your tenant supports sensitivity labels, use them instead — they apply watermarks automatically.
Save the document and verify the watermark appears on every page.
Update the document’s metadata to match (e.g. Status = Draft, Classification = Confidential).
Remove the watermark when the document is finalised or declassified.

Best practices

Use sensitivity labels if available. They’re more powerful, travel with the file, and are auditable.
Match watermark to status metadata. A ‘DRAFT’ watermark on an ‘Approved’ document confuses everyone.
Remove watermarks when status changes. Approved drafts shouldn’t say ‘DRAFT’ anymore.
Standardise wording. ‘DRAFT’, ‘CONFIDENTIAL’, ‘INTERNAL ONLY’ — pick a consistent set across the org.

Common mistakes

Treating watermarks as security. They’re visual cues, not protection. Use sensitivity labels and permissions for real control.
Forgetting to remove drafts watermarks. Leaves an approved document looking like a draft forever.
Inconsistent wording. ‘Draft’ vs ‘DRAFT’ vs ‘Working Draft’ across documents looks unprofessional and confusing.

L-16

Track Document Changes

Track Changes shows every edit, insertion, and deletion. It’s the standard tool for formal review when accountability matters.

Track Changes is one of Word’s oldest and most useful features. Turn it on, and every edit you (or anyone else) make is recorded visibly in the document — insertions appear underlined, deletions appear struck-through, formatting changes are flagged, and every change is attributed to the person who made it. The document becomes both the work and the record of how it got there.

For everyday collaboration, Track Changes is overkill — co-authoring and comments handle most needs. But for formal review processes — contracts, policies, controlled documents, anything where accountability matters — Track Changes is the standard. It gives reviewers a clear view of what’s being proposed, lets them accept or reject changes individually, and produces a clean final version that captures every approved edit.

The thing to know about Track Changes: it works best when everyone agrees to use it. If half the team has it on and half doesn’t, you get a messy document where some changes are tracked and others silently overwrite. Agree on the workflow before the review starts.

When you’ll use this

When a document is going through formal review (contracts, policies, procedures).
When multiple reviewers will edit the same document and you need to see who proposed what.
When you need an audit trail of every edit, not just version-level history.
When you’re working with external lawyers, auditors, or reviewers who expect Track Changes.

How to do it

Open the document in Word.
Go to the Review tab.
Click Track Changes (it’s a toggle — it stays on until turned off).
Make edits as normal — every change is recorded.
Use Comments alongside changes for context and discussion.
Switch view between Simple Markup (clean view) and All Markup (every change visible).
When ready, save and share the document — recipients see your changes.
Accept or reject changes (see L-17) when the review is complete.

Best practices

Turn it on before edits start. Edits made before Track Changes is on aren’t tracked.
Use Comments for discussion, Track Changes for edits. Different tools, different jobs.
Agree on the workflow upfront. Who reviews, who accepts, who finalises.
Save a clean final version. Once changes are accepted, save a version with all markup removed.

Common mistakes

Sending a document with Track Changes left on accidentally. Recipients see your editing history, including changes you might not want exposed. Always check before sending.
Half the team using Track Changes, half not. Confuses the audit trail.
Accepting all changes blindly. The whole point of Track Changes is review. Read each one.

L-17

Accept or Reject Changes

Tracked changes accumulate during review. Knowing how to accept, reject, and finalise them is the difference between a clean final document and a markup nightmare.

When a document goes through review with Track Changes on, it accumulates dozens (sometimes hundreds) of edits. At some point — usually when one person is taking responsibility for finalising the document — those changes need to be reviewed and either accepted (incorporated into the document) or rejected (discarded). What’s left after that process is the clean, final version.

Word makes this straightforward: a Review tab with Accept/Reject buttons, and a ‘Next’ button that walks you through every change in order. You can accept individual changes, reject individual changes, accept all changes from a particular reviewer, or accept everything in one go. The right approach depends on the document and your level of trust in the reviewers.

The key principle is intentionality. Don’t ‘Accept All’ without reading — that’s not review, that’s rubber-stamping. Walk through each change, decide whether it improves the document, and act accordingly. For controlled documents, the person doing this should be the named owner or an approver — not whoever happens to open the file last.

When you’ll use this

When a tracked-changes review is complete and you need to finalise the document.
When you’re the named approver finalising controlled content.
When the document has accumulated too many tracked changes and is becoming hard to read.
When you need to produce a clean final version with no markup.

How to do it

Open the document in Word.
Go to the Review tab.
Set view to All Markup so you can see every change.
Use Next to step through changes one at a time.
Click Accept to incorporate a change, or Reject to discard it.
Use Comments to confirm intent before rejecting if you’re unsure.
Once all changes are processed, turn Track Changes off.
Save a clean final version (no markup, no comments) for distribution.

Best practices

One person owns the accept/reject pass. Distributed responsibility leads to inconsistent decisions.
Walk through every change. ‘Accept All’ is laziness, not review.
Save before finalising. So you can roll back if needed.
Remove markup before publishing. Final documents should be clean — no track changes, no comments visible.

Common mistakes

‘Accept All’ without reading. Defeats the whole point of having a review.
Leaving comments in the published version. Looks unfinished and exposes internal commentary.
Multiple people accepting/rejecting in parallel. Creates conflicts. One owner, one pass.

L-18

Archive Documents

Archive is where documents go when they’re no longer active but might still be needed. Done well, it keeps your live libraries clean without losing history.

Archiving is the middle ground between ‘in active use’ and ‘delete forever’. A document that’s no longer relevant to current work but might still be needed for reference, audit, or compliance — that’s an archive candidate. Project documents from a closed project. Old policy versions superseded by newer ones. Reports from previous years. They shouldn’t clutter the active library, but they shouldn’t be deleted either.

There are several ways to archive in SharePoint: a separate ‘Archive’ library on the same site, a dedicated archive site for the whole organisation, applying an ‘Archived’ label or status, or moving to long-term retention. Each has trade-offs. The right approach depends on how often archived content needs to be accessed, who needs access, and what compliance rules apply.

What matters most is consistency. Whatever your archive process is, apply it predictably. Documents either follow the archive workflow or they don’t. Halfway-archived libraries — where some old content is in archive, some is still in the active library, some has been deleted, and nobody knows which is which — are worse than no archiving at all.

Archive ≠ Delete Archive means keeping, just not in active circulation. Delete means gone (after recycle bin retention expires). The two are completely different decisions, with different implications for compliance, audit, and your team’s ability to find old content. Don’t conflate them.

When you’ll use this

When a document is no longer actively used but might still be needed for reference.
When a project closes and you need to clean up the active site.
When old versions of policies have been superseded but still need to be retained.
When you’re cleaning up a library that’s grown too large to navigate.

How to do it

Define what ‘archive’ means for your organisation (separate library, label, retention class).
Identify documents that meet archive criteria (no longer active, still needed for reference).
Move documents to the archive location, or apply the archive label/status.
Set permissions on the archive to read-only for most users.
Update navigation and links so users find current versions, not archived ones.
Capture metadata (when archived, why, owner) so the archive isn’t a mystery.
Set up a retention schedule for how long archived content stays before disposal.

Best practices

Make archive read-only. Archived content shouldn’t be edited — it’s a snapshot.
Keep archive separate from active. Mixing the two confuses users and breaks search.
Archive systematically, not casually. Set criteria, apply consistently.
Plan archive disposal. Archive isn’t ‘forever’ for most content. Set retention rules.

Common mistakes

Treating archive as ‘storage in case we need it’. Archive needs structure and rules, not just a folder called ‘Old’.
Archiving content that should be deleted. Not everything needs to be kept. Some content has reached end of life.
Making archive too hard to find. If users can’t find archived content when they need it, they’ll create new copies of what they’re looking for.

Already a mess? Start here.

Fix the Mess Lite — a step-by-step 30-day plan to identify owners, remove duplicates, archive old content, and apply structure. The lowest-cost entry point if your SharePoint is already chaos.

L-19

Delete a Document Permanently

Permanent deletion is final. Used appropriately, it keeps libraries clean. Used carelessly, it destroys evidence and creates compliance problems.

Permanent deletion in SharePoint isn’t quite as immediate as it sounds. When you delete a file, it goes to the site Recycle Bin (where it can be recovered for ~93 days), then to a second-stage Recycle Bin (admin-recoverable for another period), then it’s gone. So ‘permanent’ usually means ‘after recycle bin retention’. But the path leads to the same place: gone, unrecoverable, irreversible.

There are legitimate reasons to permanently delete content: end-of-life data, content that’s reached the end of its retention period, content that was created in error, content that’s a confirmed duplicate. There are also illegitimate reasons — hiding evidence, working around compliance, ‘tidying up’ regulated content without authority. The line between the two matters.

Before permanently deleting anything, check three things: is this under any retention or legal hold? Has the document been linked, referenced, or required by any process? Does anyone else need to approve this? If you’re unsure on any of these, archive instead. Archive is reversible. Permanent deletion isn’t.

When you’ll use this

When a document is genuinely no longer needed and isn’t subject to retention.
When you’re cleaning up duplicates and confirmed unnecessary content.
When content has reached the end of its retention period.
When you’ve imported content in error and need to remove it before it propagates.
Almost never for regulated content without explicit authority.

How to do it

Confirm the document isn’t under retention or legal hold (check with admin or compliance if unsure).
Check that the document isn’t referenced anywhere important (links, processes, audit trails).
Delete the file from the library (it goes to the Recycle Bin first).
If your governance requires it, empty the Recycle Bin to remove the second-stage copy.
Document the deletion if your governance or compliance requires.
Verify the file is no longer accessible or discoverable.

Best practices

Default to archive, not delete. Archive is reversible. Delete is not.
Check retention before deleting. Some industries require keeping content for years.
Restrict who can delete. Not every user needs the ability to permanently remove content.
Use retention policies for systematic disposal. Manual deletion at scale is slow and error-prone.

Common mistakes

Deleting regulated content without checking retention. Could be a compliance violation. Always check.
Emptying the recycle bin to ‘free space’ on managed content. Sometimes it’s required to recover content; don’t pre-empt that.
Treating delete as a default cleanup mechanism. Most cleanup should be archive, not delete.

Already a mess? Start here.

Fix the Mess Lite — a step-by-step 30-day plan to identify owners, remove duplicates, archive old content, and apply structure. The lowest-cost entry point if your SharePoint is already chaos.

L-20

Recover a Deleted File

Files deleted from SharePoint or OneDrive almost always live in the Recycle Bin for a while. Knowing how to recover them turns panic into a 30-second fix.

When you delete a file in SharePoint or OneDrive, it goes to the site Recycle Bin (or your personal OneDrive Recycle Bin). It stays there for around 93 days by default. During that time, any user with the right permissions can restore it with a couple of clicks — back to its original location, with all its metadata, version history, and permissions intact.

After the first 93 days, the file moves to the second-stage Recycle Bin, where only site collection administrators can recover it. The file stays here for a similar period before being permanently removed. Most everyday recovery happens at the first stage; very occasionally, an admin restores from the second.

The most common reason files don’t get recovered isn’t that they’re really gone — it’s that the user doesn’t know the Recycle Bin exists, or doesn’t realise files end up there. Spend 5 minutes telling your team about Recycle Bin recovery and you’ll prevent dozens of ‘I lost the file’ panics.

When you’ll use this

When a file has been deleted by mistake.
When you can’t find a file you know existed last week.
When someone says ‘I deleted it’ — recovery is usually fast.
When you need to undo a bulk-delete that went wrong.

How to do it

Open the SharePoint site (or OneDrive) where the file lived.
In the navigation, click Recycle Bin.
Find the file — sort by date or use search if there are many items.
Select the file and click Restore.
The file returns to its original location with version history intact.
If not found, check the second-stage Recycle Bin (admin access required).
If still not found, contact your SharePoint admin — they may have access to deeper recovery.

Best practices

Check the Recycle Bin first, panic second. Most ‘lost’ files are recoverable in seconds.
Train your team about the Recycle Bin. Saves a huge amount of helpdesk time.
Restore quickly when needed. Items pass beyond user-recoverable after ~93 days.
Use versioning for resilience. Even if a file isn’t deleted but content was lost, version history can recover it.

Common mistakes

Recreating content from scratch. Almost always unnecessary. Check Recycle Bin first.
Assuming files are ‘really gone’ too quickly. Even after the first Recycle Bin, admins can often recover for several more weeks.
Not checking version history when content is lost. Version restore is often faster than file recovery.

L-21

Set Retention Policies

Retention policies tell SharePoint how long to keep content and what to do when that time is up. Set well, they handle compliance automatically.

Retention policies are rules that govern how long content is kept and what happens when it reaches the end of its life. Set up at the tenant level by an admin, applied to libraries, sites, or specific content types, retention policies enforce keeping content for a defined period — and (depending on configuration) automatically deleting it afterwards, or marking it for review.

Retention is fundamentally a compliance tool. Different industries have different requirements: financial records often need to be kept 7+ years; medical records, much longer; HR records, varying by jurisdiction. Retention policies make this systematic — instead of relying on individual users to remember ‘don’t delete this for 7 years’, the system enforces it.

For end users, retention is mostly invisible. You create and edit content normally; the policies work in the background. Where it does become visible is when retention prevents deletion (‘You can’t delete this — it’s under retention until 2031’), or when retention triggers a review or auto-delete after the retention period ends. Knowing retention exists helps you understand why some content can’t be deleted casually.

When you’ll use this

When you need to comply with industry regulations on document retention.
When you want to systematically manage content lifecycle at scale.
When you’ve inherited a tenant with no retention rules and need to fix it.
When you’re setting up a new site or library for regulated content.

How to do it

Identify the content types and retention periods required (often via your compliance team).
Work with your SharePoint admin to set up retention labels in the Microsoft Purview compliance centre.
Apply retention labels to libraries, sites, or content types.
Test with sample content to confirm the policy behaves as expected.
Document the retention scheme for users and admins.
Communicate to users when retention prevents normal deletion (so they understand it’s deliberate).
Review the retention scheme periodically as regulations and business needs change.

Best practices

Centralise retention decisions. Don’t let individual library owners invent their own retention rules.
Document the rationale. ‘Why do we keep this for 7 years?’ should have a written answer.
Use labels consistently. Different content types may have different retention, but the labels should be standard.
Audit retention coverage. Content without retention labels is content not under management.

Common mistakes

Setting retention without compliance input. Guessing retention periods can create real legal risk.
Letting retention conflict with business needs. Aggressive auto-delete on active content disrupts work.
Applying retention inconsistently. Some libraries have it, some don’t — chaos at audit time.

Who owns what. What the rules are.

The Governance Starter Kit gives you a plain-English governance system for real organisations. Roles, library standards, sharing rules, and a monthly routine that takes under 90 minutes.

L-22

Create an Approval Workflow

Approval workflows automate the review and sign-off process. Built well, they save time, create audit trails, and keep approvers from drowning in email.

An approval workflow is an automated process that routes a document (or item) through one or more reviewers, captures their decision, and acts on the result. The simplest approval workflow has one approver who says yes or no. The most complex have conditional logic, multiple approvers, deadlines, escalation, and integration with other systems. Most teams need something in between.

Microsoft 365 offers two main paths. SharePoint’s built-in content approval covers basic ‘document needs to be approved before publishing’ use cases without any setup beyond a library configuration. Power Automate handles everything more sophisticated — approval flows triggered by file uploads, multi-step approvals, conditional routing, integration with Teams notifications, the lot.

The trap with approval workflows is over-engineering. Teams build elaborate flows with five approvers, complex routing, and conditional logic — then nobody uses them because they’re too slow. Start simple: one approver, clear criteria, a target turnaround. Make it complex only when you’ve proven you need to.

When you’ll use this

When documents need formal approval before publication.
When you have a clear approval rule that’s currently happening informally over email.
When you need an audit trail of who approved what and when.
When approvals are getting lost or delayed because there’s no system tracking them.

How to do it

Decide your approach: built-in content approval (simple) or Power Automate (flexible).
Define the approver(s) — keep this small, ideally one person per document type.
Set up the trigger (e.g. when a file is added or modified in a specific library).
Configure the approval action with a clear description and deadline.
Add a notification step so approvers get pinged in Teams or email.
Add the post-approval action (publish, move file, update status, notify author).
Test the workflow end-to-end before rolling it out.
Train authors and approvers on the new process.

Best practices

Start simple. Single approver, clear criteria, fast turnaround. Add complexity only when needed.
Set deadlines. Approvals that sit in inboxes forever defeat the purpose.
Notify in Teams, not just email. Approvers see Teams notifications faster.
Capture rejection reasons. ‘Rejected’ alone tells the author nothing. ‘Rejected because section 3 references outdated policy’ is actionable.

Common mistakes

Five-approver chains. Slows everything down. Most documents need one approver, not a committee.
No deadline. Approvals stall indefinitely. Always set a target turnaround.
No fallback if approver is unavailable. What happens when the approver is on leave? Plan for it.
Building a workflow with no audit output. The whole point is the trail. Make sure it’s captured.

Who owns what. What the rules are.

The Governance Starter Kit gives you a plain-English governance system for real organisations. Roles, library standards, sharing rules, and a monthly routine that takes under 90 minutes.

L-23

Notify on Document Updates

Sometimes you need to know when a document changes — not check it daily. Notifications make change visible without becoming noise.

Microsoft 365 has multiple ways to be notified about document changes: SharePoint alerts (the classic, slightly dated tool), Teams channel notifications, OneDrive’s activity feed, and Power Automate flows that can send anything to anyone. The right tool depends on what you’re trying to do and how much noise you can tolerate.

The temptation is to alert on everything. The reality is that alerts you ignore become invisible. The most useful notification setup is the one where every alert that arrives is actually meaningful — because something significant changed, on a document you care about, in a way that requires action or attention.

For most teams, the best notification setup is: Teams notifications for active project channels (so you see relevant changes in your normal workflow), Power Automate for high-importance documents (specific people get pinged when specific files change), and basically nothing else. Less is more.

When you’ll use this

When you need to know about changes to specific high-importance documents.
When you’ve inherited a document set and want to monitor activity.
When you’re handing over content and want to be notified if changes happen during transition.
When approvals or reviews depend on knowing when content updates.

How to do it

Decide what you actually need to be notified about (usually fewer files than you think).
For Teams files: make sure you’re following the channel — Teams will surface activity.
For SharePoint files: open the file and look for an ‘Alert me’ option in older interfaces, or set up a Power Automate flow for newer experience.
Build a Power Automate flow with a clear trigger (specific file, specific change type) and a clear notification action (Teams message, email).
Test by making a small change and confirming the notification arrives.
Tune frequency: instant for critical content, daily summary for everything else.
Review notifications periodically — turn off alerts you ignore.

Best practices

Less is more. Three meaningful alerts a week is useful. Thirty alerts a day is invisible.
Use Power Automate for structured alerts. Built-in alerts are limited; Power Automate is flexible.
Notify the owner, not the universe. One named person should care about each notification.
Audit your alerts quarterly. Disable alerts you no longer need.

Common mistakes

Alerting on everything. Becomes noise, gets ignored, defeats the point.
Sending alerts to inboxes that nobody monitors. The alert lives, the recipient doesn’t see it.
Building elaborate notification flows nobody asked for. Build for actual user needs, not theoretical ones.

L-24

Compare Document Versions

Sometimes you need to see exactly what changed between two versions of a document. Compare is the tool for that — faster than reading both versions side by side.

Word has a built-in Compare feature that takes two versions of a document and produces a third document showing exactly what’s different — additions, deletions, formatting changes, all colour-coded and attributed. It’s the same tool you’d use for a Track Changes review, but applied to two existing documents that don’t have tracked changes.

This is enormously useful when you’ve received an updated version of a document and need to know what changed without trusting someone’s summary. It’s also useful when you have two drafts that diverged and you need to reconcile them. Compare doesn’t change either of the original documents — it produces a new diff document that you can review and use to guide your decisions.

Where Compare is less useful is for very large or heavily-formatted documents where the diff becomes overwhelming. For those, sometimes a focused review of specific sections is faster. Use Compare for surgical analysis of what changed; use direct review for big-picture understanding.

When you’ll use this

When you’ve received a revised document and need to know what changed.
When two drafts have diverged and you need to merge them.
When you’re auditing changes made to a controlled document.
When you need to understand version-to-version differences for compliance.

How to do it

Open Word.
Go to Review → Compare → Compare.
Select the Original document (the older version).
Select the Revised document (the newer version).
Choose the comparison settings (most defaults are fine).
Click OK — Word generates a third document showing all differences.
Review the differences — accept, reject, or use them to inform a manual reconciliation.
Save the result if needed for audit purposes.

Best practices

Compare against the source of truth. If SharePoint has the master version, compare against that one.
Save the comparison for audit. If approvals are required, the comparison output is good evidence.
Use Compare alongside version history. Version history shows when; Compare shows what.
For controlled docs, prefer Track Changes. Track Changes captures intent at the time of editing; Compare reconstructs after the fact.

Common mistakes

Trusting a summary instead of comparing. Summaries miss things; Compare doesn’t.
Forgetting which document is original vs revised. Easy to invert and read the diff backwards.
Trying to use Compare on heavily-formatted documents. Becomes overwhelming. Sometimes a focused manual review is better.

L-25

Merge Document Changes

When two people edit a document separately, you eventually need to merge their changes into one clean version. Done well, this is structured. Done badly, it’s chaos.

Document merging happens when collaboration breaks the co-authoring model. Maybe two people edited offline, two versions diverged because someone downloaded a copy, or two contributors worked on different sections of the same document independently. Whatever the cause, you end up with two (or more) versions and need to combine them into one.

Word’s Compare feature can help with this: produce a diff, then manually reconcile differences. For more structured merging, Word also has a Combine option specifically for merging tracked-changes versions from multiple reviewers. For complex documents with many divergences, sometimes the cleanest solution is to identify a primary version and manually port changes from the other version into it.

The real lesson, though, is that merging is a symptom of a broken collaboration workflow. If you’re merging documents regularly, the team is working in parallel when they should be co-authoring. The best fix isn’t getting better at merging — it’s making sure everyone works from one shared cloud version with co-authoring on, so divergence never happens in the first place.

When you’ll use this

When two people have edited the same document offline and you need to combine their changes.
When a document was downloaded by mistake and edited locally, and the cloud version has also been updated.
When you’re consolidating tracked-changes reviews from multiple reviewers.
When you’ve inherited a project with several divergent draft versions.

How to do it

Identify all the versions that need merging and the source of truth.
Use Word’s Compare tool to see differences between versions.
For tracked-changes merging, use Review → Compare → Combine.
Walk through each difference and decide: keep, replace, or merge.
Resolve conflicts where the same section has been changed differently in both versions.
Save the merged document as the latest version in the official location.
Add a check-in comment describing the merge.
Notify contributors that the merged version is the source of truth from now on.

Best practices

Prevent merging by enforcing co-authoring. One cloud file, multiple editors. No download-edit-upload cycles.
One person owns the merge. Distributed merging causes new divergence.
Use comments to capture decisions. ‘Kept Sarah’s version of section 3 because it reflects updated policy.’
After merge, retire the divergent versions. One source of truth from this point forward.

Common mistakes

Merging in parallel. Two people independently merging the same documents creates a third divergent version.
Not communicating after merge. Contributors keep editing their old versions because they don’t know there’s a merged source of truth.
Skipping documentation. Six months later, nobody remembers why a particular merge decision was made.

L-26

Create a Document Library

Document libraries are where files actually live in SharePoint. A well-designed library is the foundation of everything else. A badly-designed one creates years of mess.

A document library is SharePoint’s container for files. Every SharePoint site has at least one (typically called ‘Documents’); most sites have several. Inside a library, you have files and folders, but you also have metadata columns, views, permissions, versioning settings, approvals, and lifecycle rules. A library isn’t just a folder — it’s a structured space with its own policies.

Most users only ever see the default ‘Documents’ library that comes with a new site. That’s fine for very simple cases, but it’s also where most SharePoint mess accumulates. Multiple libraries — one per major content type or process — give you cleaner organisation, better permissions control, and the ability to apply different rules to different content.

Creating a library is straightforward in the interface. The hard part isn’t the technical creation — it’s designing the library well. Good libraries have a clear purpose, sensible metadata columns, useful views, considered permissions, and a maintenance owner. Bad libraries have none of these and become ‘a place where files go to die’.

When you’ll use this

When you’re setting up a new site and need to plan its content structure.
When you’ve outgrown a single ‘Documents’ library and need to split content.
When you have a specific document type that needs its own metadata and rules.
When you’re separating draft, review, and published content into different libraries.

How to do it

Open the SharePoint site.
Click + New → Document library.
Name it clearly (e.g. ‘Policies’ not ‘Documents 2’).
Add a description so users know what belongs there.
Configure versioning settings (major/minor, version limits, content approval if needed).
Set permissions if they should differ from the site (e.g. read-only for most users).
Add metadata columns for the structure you need (document type, owner, status).
Create useful views (default view, group-by-type, missing-metadata, etc.).
Document the library’s purpose for users and future admins.

Best practices

One library per content type or major process. Don’t try to fit everything in ‘Documents’.
Plan metadata before uploading content. Adding columns later requires backfilling.
Set permissions at library level. Avoid file-level permissions where possible.
Assign a library owner. Someone accountable for keeping it organised.

Common mistakes

Creating libraries as if they were folders. Library = significant content type. Folder = organisation within a library.
Library sprawl. Creating new libraries for every minor variation. Often a content type or metadata column is the right answer.
Forgetting governance. Library settings (versioning, retention, permissions) need to match the content’s importance.

Stop using folders. Start using metadata.

The Metadata & Structure Planning Guide covers the 3-level rule, the 3 core columns, real library examples, and why metadata is the foundation for Copilot.

Get the Metadata Guide

L-27

Prevent Accidental Deletion

Most data loss in SharePoint is accidental — someone deletes the wrong file, doesn’t notice, and time runs out. A few simple settings prevent most of this.

Accidental deletion is depressingly common. Someone selects the wrong file, hits delete, and moves on. By the time anyone notices, the file is in the recycle bin (still recoverable). After 93 days, it’s in the second-stage recycle bin (admin-recoverable). Beyond that, it’s gone. Most data loss happens because the file slipped through both stages without anyone realising it was missing.

Prevention is much cheaper than recovery. A combination of versioning (so accidental overwrites can be rolled back), retention policies (so deletes don’t actually remove the file for a defined period), restricted delete permissions (so most users can’t delete at all), and good library navigation (so users find files quickly without doing ‘cleanup’ to make things easier to find) prevents most accidental loss.

The other piece is culture. Train your team that ‘tidy up’ isn’t a value — keeping content findable through metadata and views is. The most damaging file deletions usually come from someone trying to be helpful by ‘cleaning up old stuff’. Channel that energy into archive workflows, not delete buttons.

When you’ll use this

When you’re setting up a new important library and want to lock it down.
When you’ve experienced data loss and want to prevent recurrence.
When critical content is being managed by users who don’t understand the consequences of deletion.
When you want to align with best-practice governance for important content.

How to do it

Enable versioning at library level (major versions at minimum, ideally minor versions too).
Apply retention policies if your tenant supports Microsoft Purview retention.
Restrict delete permissions in critical libraries — most users can read/edit but not delete.
Enable content approval for libraries where content shouldn’t change without sign-off.
Test recovery (restore from version history, restore from recycle bin) so you trust the setup.
Train users on archive vs delete — encourage archive for cleanup.
Audit recycle bins periodically to catch anything important that was deleted accidentally.

Best practices

Treat deletion protection as governance, not paranoia. Important content deserves the rules.
Limit delete permissions in critical libraries. Most users don’t need delete; reading and editing is enough.
Use retention to enforce ‘unable to delete’ on regulated content. Hard constraint, not just a guideline.
Educate, don’t just block. Users should understand recycle bin and recovery so they don’t panic when something goes wrong.

Common mistakes

Giving every user full delete permissions. One mistake removes content for everyone.
No versioning on important libraries. When something gets overwritten, you can’t recover.
Ignoring the recycle bin. Items pass beyond user-recoverable in 93 days. Audit before then.

Who owns what. What the rules are.

The Governance Starter Kit gives you a plain-English governance system for real organisations. Roles, library standards, sharing rules, and a monthly routine that takes under 90 minutes.

L-28

Bulk Upload Documents

Sometimes you need to move a lot of files into SharePoint at once. Done right, it’s painless. Done wrong, it produces a mess that takes years to clean up.

Bulk upload is the moment when most SharePoint messes are born. Someone has a folder structure on a shared drive, an old SharePoint site, or a personal OneDrive — and they upload the lot. The good intent is real; the result is a library full of files with the same problems the old structure had, plus some new ones (broken paths, duplicate filenames, no metadata, no governance).

The right approach to bulk upload is to do less of it, more deliberately. Cleanse before you upload: remove duplicates, fix obviously bad filenames, archive content that’s no longer relevant. Plan the destination: which library? what folder structure? what metadata columns do they need? Upload in batches, verify, classify, repeat.

For very large migrations (thousands of files, multiple sources), bulk upload through the browser usually isn’t the right tool. Tools like the SharePoint Migration Tool (SPMT), ShareGate, or Metalogix exist precisely because browser upload doesn’t scale and doesn’t capture metadata reliably. For everyday bulk upload (a few hundred files), the browser works fine — but cleansing and metadata are still the actual work.

When you’ll use this

When you’re migrating content from a shared drive or old SharePoint site.
When you’ve inherited a folder of project files that need to live in SharePoint going forward.
When you’re consolidating content from multiple personal OneDrives into a team library.
When you’re populating a new library with reference content.

How to do it

Cleanse the source: remove duplicates, fix obviously broken filenames, archive truly old content.
Plan the destination: which library, which folder structure, which metadata.
Open the target library in the browser.
Drag and drop files (or use Upload → Files / Folder) — SharePoint handles the upload.
Wait for upload to complete; resolve errors (filename conflicts, special characters).
Apply metadata in bulk using Quick Edit / Grid View — much faster than editing each file individually.
Verify with a sample of files: are they findable, taggable, accessible?
Repeat for additional batches if the migration is large.

Best practices

Cleanse before you upload. Don’t move bad data into a clean library.
Plan metadata up front. Adding columns after upload means backfilling — much harder than tagging during upload.
Test with a small batch. 50 files to start. Confirm everything works. Then scale.
Use Grid View for bulk metadata. Tagging 500 files individually will break your spirit. Grid View is 10x faster.

Common mistakes

Lift-and-shift. Uploading the messy folder structure as-is. You end up with the same mess in a new location.
No metadata after upload. Files exist but can’t be filtered, sorted, or found via Copilot. Wasted effort.
Browser upload for 10,000 files. Wrong tool. Use the SharePoint Migration Tool or a third-party migration tool.

Already a mess? Start here.

Fix the Mess Lite — a step-by-step 30-day plan to identify owners, remove duplicates, archive old content, and apply structure. The lowest-cost entry point if your SharePoint is already chaos.

L-29

Download Multiple Documents

Sometimes you need to grab a set of files for offline use, a handover, or a backup. Knowing how to do it cleanly avoids version confusion later.

SharePoint and OneDrive let you download multiple files at once — select them, click Download, and SharePoint zips them into a single archive that downloads to your computer. Useful for offline access, handovers, sharing with people who don’t have access, or making local backups.

The thing to watch with bulk download is what happens next. Once files are off SharePoint, they’re disconnected from the version history, permissions, and metadata. Edits made to the downloaded copies aren’t synced back unless someone manually re-uploads. That’s how ‘Final_FINAL_v3.docx’ files happen — someone downloaded them, edited offline, and re-uploaded without realising the original had also been updated in the meantime.

For most use cases, downloading is the wrong solution. If someone needs offline access, OneDrive sync is better — it keeps a connection back to the source. If someone needs to receive content, sharing a link is better — they always see the latest version. Download is best for one-off purposes (handover packs, archives, point-in-time snapshots) where the disconnect is intentional.

When you’ll use this

When you need files for a one-off purpose (handover, archive, presentation backup).
When you’re providing files to someone who can’t access SharePoint.
When you need to take content into a different system entirely.
Almost never for active collaboration — use links instead.

How to do it

Open the SharePoint library.
Select multiple files (use the checkbox column on the left of each row).
Click Download in the top toolbar.
SharePoint zips the files into a single archive and downloads to your browser.
Extract the zip to use the files locally.
If you make changes, plan how to re-upload — versioning won’t be preserved automatically.
Consider whether OneDrive sync would be a better solution for your need.

Best practices

Use links for collaboration, downloads for one-off purposes. Different tools for different needs.
Don’t edit and re-upload casually. You break version history every time.
Use OneDrive sync for ongoing offline access. Keeps the link to source intact.
Be careful with sensitive content. Downloaded files are off SharePoint — they’re not protected by SharePoint permissions anymore.

Common mistakes

Bulk-downloading collaborative files for editing. Creates version chaos when you re-upload.
Downloading from a library for sharing. Just send the SharePoint link — recipients always see the current version.
Forgetting that downloaded files lose all metadata. Document type, status, owner — all gone outside SharePoint.

L-30

Move Documents Between Libraries

Reorganising content is sometimes necessary. Moving files between libraries (correctly) preserves history and keeps the team functional.

Moving documents between libraries — or between sites — happens for legitimate reasons: a project closes and content moves to archive; content was uploaded to the wrong library and needs to relocate; an org restructure means a department’s content moves to a new site. SharePoint has built-in move and copy functions that handle this without losing version history (in most cases) or breaking permissions structurally.

The catch is that moving content can break things downstream: links in emails, references in documents, bookmarks people have saved, integrations with other systems. The move itself is fine; the broken connections are the problem. Plan moves carefully and communicate them clearly.

For small moves (a few files), use the built-in Move to command. For larger moves (hundreds or thousands of files), consider migration tools that handle metadata and links more reliably. Avoid drag-and-drop between libraries when you can — it sometimes copies rather than moves, and the resulting orphan copies cause confusion.

When you’ll use this

When content was uploaded to the wrong library and needs to be in the right place.
When a project closes and you’re moving content to an archive library.
When you’re reorganising a site and content needs to redistribute.
When merging or splitting libraries to align with a new structure.

How to do it

Confirm the target library exists and is configured (permissions, versioning, metadata).
Select the file(s) in the source library.
Use Move to in the toolbar.
Choose the destination (different library, folder, or site).
Confirm the move — SharePoint preserves version history when moving within the same site.
Check that metadata is intact — some columns may not exist in the destination.
Update any external references (links in emails, wiki entries, bookmarks).
Notify users of the new location.

Best practices

Prefer Move over Copy. Move keeps version history; copy creates duplicates.
Update navigation and links after moving. Broken links are the most common post-move complaint.
Move in batches and verify. 50 files, check results, repeat. Don’t move 5,000 in one go without testing.
Document the move. Record what moved where and when, so you can answer ‘what happened to that file?’ later.

Common mistakes

Drag-and-drop between libraries. Sometimes copies, sometimes moves. Use the Move To command instead — it’s deterministic.
Moving content without warning users. Their bookmarks break, they panic, they recreate copies. Communicate first.
Constant reshuffling. If you’re moving content every quarter, your structure is the problem, not the content.

Already a mess? Start here.

Fix the Mess Lite — a step-by-step 30-day plan to identify owners, remove duplicates, archive old content, and apply structure. The lowest-cost entry point if your SharePoint is already chaos.