Collaborating in Microsoft 365

Multiple people can build one PowerPoint deck together — at the same time, without emailing versions back and forth. This is what Microsoft 365 was built for.

Building a presentation alone is fine for short decks. For anything longer or more important, you usually want input from someone else — a colleague who knows the data, a designer who can fix your slides, a manager who needs to approve the framing. The traditional way to do this is to email a copy back and forth, watch versions multiply, and end up with ‘final_v3_REVIEWED_use_this_one.pptx’ three days later. There’s a better way.

Co-authoring in PowerPoint is genuinely transformative once you start using it properly. Save the file in OneDrive (for personal drafts) or SharePoint/Teams (for shared work), turn AutoSave on, and click Share. Now you and your colleague can both have the file open at the same time. You see each other’s cursors. Edits appear in real time. Comments stay in the deck instead of in email. There is one file, one source of truth, one version history — and it just works.

The mental shift takes a moment but it’s worth it. The instinct to download, edit, and re-upload is from the era of file servers. In Microsoft 365, you stay in the cloud file. You stay in the same document the other person is in. Versions take care of themselves. Most of the work that used to be coordination becomes invisible — because the system is doing it for you.

Why this matters

Co-authoring isn’t just convenient — it changes the economics of collaboration:

It eliminates version chaos. One file, one truth. No more emailing ‘the latest version’ to people who already had a different latest version.

It enables faster review cycles. Comments and edits happen in context, not in email replies that lose half the meaning.

It makes asynchronous work easier. Your colleague edits in their morning, you review in yours. The file moves forward without scheduling.

When you’ll use this

• When two or more people need to edit the same presentation.
• When you want feedback in context, not as comments in email.
• When you’d otherwise be emailing a deck back and forth.
• When you need a single source of truth for a team-owned presentation.

How to do it

1. Save the presentation in OneDrive (for personal drafts) or a Team/SharePoint library (for shared work).
2. Open it in PowerPoint and confirm AutoSave is on (top-left corner).
3. Click Share and invite your colleague (or copy a sharing link with the right permission).
4. Both of you open the same file — you’ll see each other’s presence indicators while editing.
5. Use Comments for feedback rather than rewriting each other’s content silently.
6. Save and close as normal — version history captures everything automatically.

Best practices

• Keep the file in one location. Don’t download and re-upload different copies — co-authoring breaks the moment you do.
• Agree roles before you start. One person on structure, one on content avoids editing collisions.
• Use slide titles consistently. Makes navigation, review, and recap dramatically easier.
• Use Comments and @mentions for changes that affect meaning. Don’t rewrite someone’s argument silently.
• Set a clear status when you’re done. Draft / For Review / Final removes ambiguity.

Common mistakes

• Downloading the file to ‘work on it locally’. The moment you do this, you’ve started a parallel version. Stay in the cloud file.
• Emailing ‘the latest version’. The latest version is the one in SharePoint. Send a link.
• Editing without communicating. Two people rewriting the same slide simultaneously creates conflict. Coordinate, even briefly.

↑ Back to top ↑ Back to list

Word’s co-authoring is the most common reason people stop emailing attachments. Once you use it once, you don’t go back.

Word documents are where most workplaces still produce reports, proposals, policies, and procedures. They’re also where most version chaos lives. The traditional pattern is broken: someone drafts, emails it for review, gets back six different versions with conflicting edits, manually merges them while losing some changes, and produces a ‘final’ document that’s actually just one person’s interpretation of what others said.

Co-authoring fixes this completely. Save the document in OneDrive (personal) or SharePoint/Teams (shared). Click Share. Invite reviewers. Now everyone edits the same file. Comments live in the document. Track Changes (when used) shows who proposed what. Version history captures every save. The document evolves through one shared process instead of through six parallel ones.

The most common objection is ‘but what if two people edit the same paragraph?’ Word handles this gracefully — you see the other person’s cursor, edits appear as they happen, and conflicts (rare in practice) are flagged for resolution. The fear of collision is much bigger than the actual problem. The real problem — the one co-authoring solves — is the version chaos that happens when people don’t co-author.

When you’ll use this

• When multiple people need to draft, review, or refine a document.
• When you’d otherwise be emailing ‘review the attached and send your changes’.
• When the document has formal review requirements and needs Track Changes.
• When you want feedback to live with the document, not in email.

How to do it

1. Save the document in OneDrive (personal) or a Team/SharePoint library (shared work).
2. Open in Word and confirm AutoSave is on.
3. Click Share and invite the team with edit access (or send a sharing link).
4. Everyone opens the same file — edits appear live with presence indicators.
5. Use Comments for discussion and questions; use Track Changes for formal review.
6. Resolve comments as they’re addressed; accept or reject changes when finalising.
7. Set a status (Draft / Final) when complete and store in the right location.

Best practices

• Use Comments for discussion, not for rewriting wording. Comments preserve context; silent rewrites lose it.
• Turn on Track Changes for formal documents. Policies, procedures, contracts — anywhere accountability matters.
• Stop emailing attachments once collaboration starts. Send the link. Always the link.
• Store final documents in a governed location. SharePoint with proper metadata, not someone’s OneDrive.

Common mistakes

• Downloading to edit, then re-uploading. Defeats the entire system. Stay in the cloud.
• Emailing the document for review. Five people will send you five different files. Use one shared link instead.
• Skipping the status step. Without a clear ‘this is final’, everyone keeps editing forever.

↑ Back to top ↑ Back to list

Excel co-authoring lets multiple people update the same workbook in real time — perfect for trackers, registers, and any data that’s currently living in twelve different copies.

Excel co-authoring is one of the quieter superpowers of Microsoft 365. The same spreadsheet can be edited by multiple people simultaneously, with everyone seeing changes as they happen. This makes Excel a genuine collaborative tool instead of a passing-around-the-office tool. Trackers stop having seventeen versions. Registers stay current. Budget files don’t get out of date the moment they’re emailed.

Co-authoring in Excel is most powerful when paired with structure. Use Tables (Insert → Table) to give your data structure that behaves well during co-authoring — sorts, filters, and formulas all work correctly when multiple editors are active. Avoid major structural changes (moving sheets, deleting columns) while others are editing. And use Data Validation to keep entries consistent across editors.

Where Excel collaboration has limits is when the spreadsheet outgrows what Excel is for. If your team is using a multi-tab Excel file as the authoritative tracker for projects, requests, or assets — and several people update it daily — consider Microsoft Lists instead. Lists is purpose-built for this kind of structured tracking, and handles concurrent editing far better than even Excel co-authoring does.

When you’ll use this

• When multiple people need to update a tracker, register, or workbook.
• When you want one current spreadsheet instead of twelve emailed versions.
• When data is being collected from several contributors.
• When live updates matter — financial models, real-time dashboards, project trackers.

How to do it

1. Save the workbook to OneDrive or SharePoint.
2. Open in Excel and confirm AutoSave is enabled (top-left corner).
3. Click Share and grant edit access.
4. Multiple editors can now work on different areas at the same time.
5. Use Version History if a change goes wrong — full restore in seconds.
6. Avoid structural changes (moving sheets, deleting rows) while others are editing.

Best practices

• Use Excel Tables for lists. They behave dramatically better during co-authoring than raw cell ranges.
• Use Data Validation to enforce consistency. Drop-downs and rules keep multiple editors aligned.
• Avoid structural changes during active collaboration. Schedule them, communicate them, then make them.
• Consider Microsoft Lists for long-term trackers. Excel is for analysis; Lists is for shared, structured data.

Common mistakes

• Storing the ‘real’ tracker in someone’s OneDrive. When they’re on leave, the team is stuck.
• Major formatting changes during a busy edit window. Disrupts everyone else’s editing flow.
• Letting Excel become a database. If your spreadsheet has 5,000 rows and 20 contributors, Excel isn’t the right tool anymore.

↑ Back to top ↑ Back to list

Knowing who else is in a document right now lets you coordinate edits, avoid collisions, and ask quick questions instead of guessing.

When you open a co-authored document, Microsoft 365 quietly shows you who else is in it. Their initials or photo appear in the top-right of the file. Their cursor is visible in the document, with their name. If they’re typing in the same paragraph as you, you’ll see their changes appear in real time. This presence layer is one of the most underrated features of Microsoft 365 — it transforms ‘who’s editing what?’ from a question into something you can just see.

The presence indicator does more than show who’s there. It changes how you collaborate. Instead of editing blindly and worrying about overwriting someone, you can see them working in section 4 and just edit section 6. If two of you are unavoidably in the same section, you can drop a comment (‘I’m rewriting this paragraph — can you give me five minutes?’) instead of accidentally overlapping. The coordination happens in the document, not in side conversations.

It’s also a useful sanity check. If you’ve shared a file for review and you see no one in it for two days, that’s information. If you see your colleague in it editing furiously the moment you sent it, that’s information too. Presence makes collaboration legible — you can see it happening.

When you’ll use this

• When you’re about to make significant changes and want to avoid editing collisions.
• When the document looks ‘busy’ and you want to coordinate with others.
• When you want to know if someone has actually opened the file you sent.
• Whenever you’re collaborating in real time — it’s the awareness layer.

How to do it

1. Open the file from SharePoint or OneDrive (not from a download — presence only works in the cloud version).
2. Look at the top-right of the file — initials or profile pictures show who else is in it.
3. Hover over a name to see exactly where they’re working.
4. Use Comments with @mentions if you need to coordinate or ask a question.
5. Make significant structural changes when others aren’t actively editing.

Best practices

• Edit different sections to start. Use the presence indicator to see where others are working and avoid collisions.
• Use comments to claim sections in complex docs. ‘I’m restructuring section 3 — please don’t edit there until I’m done.’
• One source of truth, always. Don’t open a downloaded copy alongside the cloud file.
• Store team docs in SharePoint, not personal OneDrive. Permissions and ownership are clearer.

Common mistakes

• Editing without checking who else is in the document. Easy to overlap, easy to fix — if you check first.
• Working from a downloaded copy. Presence doesn’t work, and your changes don’t sync until you re-upload.
• Copying content into a new file ‘to make changes safely’. You’ve now got two versions. Make changes in place; trust version history.

↑ Back to top ↑ Back to list

Version conflicts happen when collaboration breaks. Get the basics right and they almost never occur — saving you the merge work that nobody enjoys.

True version conflicts in Microsoft 365 are rare — far rarer than the file-server-era horror stories suggest. When they do happen, it’s almost always because someone broke the cloud collaboration model: downloaded a copy, edited it, then uploaded it back. Now there are two parallel versions and someone has to merge them. The merge work is the cost of breaking the system.

The fix is structural, not procedural. Stop relying on people to remember to share links instead of attachments. Stop hoping people will keep files in the right place. Make it the default — the file lives in SharePoint, the link goes in the email, the cloud version is the only version. Once that’s the norm, version conflicts mostly disappear.

When conflicts do occur (someone offline made changes that diverged from the live version), Word, Excel, and PowerPoint all have built-in conflict resolution. You see both versions side by side and pick what to keep. It’s manageable when it happens — but it’s much better not to need it. Train your team to stay in the cloud file and the conflicts evaporate.

When you’ll use this

• Always — version conflict prevention is a posture, not a one-time task.
• When you’ve been burned by ‘final_v2_FINAL’ files and want a permanent fix.
• When you’re setting up new collaboration habits in your team.
• When you’re auditing why a project keeps producing duplicate files.

How to do it

1. Store all collaborative files in SharePoint or OneDrive — never on local desktops.
2. Open files from their cloud location (don’t download them first).
3. Confirm AutoSave is enabled.
4. Always share links, not attachments.
5. If something goes wrong, restore using Version History rather than recreating files.

Best practices

• Links, never attachments. The single highest-impact rule for version sanity.
• Don’t download, edit, and re-upload. That sequence is how almost all version conflicts happen.
• Enable versioning on every important library. Even when conflicts happen, recovery is fast.
• Use clear status (Draft / Review / Final) instead of version numbers in filenames. SharePoint handles versions; filenames don’t need to.

Common mistakes

• Sending attachments ‘because the recipient might not have access’. Fix the access. Don’t perpetuate the chaos.
• Working from local copies ‘because the internet is slow’. Files On-Demand and offline sync solve this without breaking versioning.
• Naming files ‘final’, ‘v2’, ‘REVISED’. Use Status metadata and version history. Stop putting versions in filenames.

↑ Back to top ↑ Back to list

Comments turn documents into conversations. Used well, they replace email-driven feedback chaos with focused, traceable, in-context discussion.

Comments are the under-used star of Microsoft 365 collaboration. Most people learn the basics (highlight, click New Comment, type) and stop there. The deeper power is in how comments transform feedback culture: instead of getting feedback by email and trying to apply it manually, the feedback lives in the document, attached to the exact text it concerns. There’s no ambiguity about what the comment refers to, and there’s a record of every conversation.

Comments support @mentions, which trigger notifications in Teams or email. This is the magic that makes async review actually work — drop a comment with @Sarah Smith, and Sarah gets a notification that takes her directly to your comment in the document. She replies in the comment thread, and the back-and-forth happens in context. No email chains. No ‘which version are you looking at?’ confusion. Just a conversation tied to the work.

Where this falls down is when teams treat comments as second-class. They paste them into emails, screenshot them, or ignore them in favour of phone calls. Comments only work as a system when the team commits to using them — and resolving them, which is the other half of the discipline. A document buried in unresolved comments from six months ago isn’t collaboration; it’s noise.

When you’ll use this

• When you have feedback or questions about specific text in a document.
• When you want to suggest changes without rewriting other people’s work.
• When you’re collecting input from multiple reviewers and want it consolidated.
• When the discussion needs to be tied to the document for future reference.

How to do it

1. Open the document from OneDrive or SharePoint (not an emailed attachment).
2. Highlight the text the comment relates to (or place your cursor where it applies).
3. Click New Comment (or Insert → Comment).
4. Type your feedback and use @mention to notify a specific person.
5. Send the comment — it stays with the document for everyone to see.
6. Reply to existing comment threads to keep the conversation in one place.
7. Resolve the comment when the issue is addressed.

Best practices

• Be specific. ‘This sentence is unclear because X’ is actionable. ‘Fix this’ isn’t.
• Use @mentions to direct comments. If you want a specific person to respond, tag them.
• One thread per issue. Don’t start three comments about the same point.
• Resolve as you go. Resolved comments declutter the document.
• Don’t rewrite someone’s work silently. Comment first if your edit changes meaning.

Common mistakes

• Pasting feedback into emails instead of using comments. Loses context, splits the conversation.
• Vague feedback. ‘Improve this’ helps no one. Be specific or don’t comment.
• Never resolving comments. A document with 47 unresolved comments is a graveyard, not collaboration.

↑ Back to top ↑ Back to list

A document full of unresolved comments is harder to read than the document itself. Resolving completed comments keeps the focus on what’s still open.

Resolving a comment is the second half of using comments well. Once you’ve actioned the feedback (made the change, decided not to make it, agreed to revisit later), the comment’s job is done. Resolving it removes it from the active comment view but keeps it in the history — so the conversation isn’t lost, but it’s also not cluttering the document.

The discipline of resolving matters more than people realise. A document with 60 unresolved comments looks chaotic even if 50 of them are actually done. Reviewers can’t tell what’s still open. New collaborators feel overwhelmed. The signal of ‘what’s outstanding’ gets lost in the noise of ‘what’s been handled’. Resolved comments preserve the audit trail without polluting the live document.

If a comment’s outcome is uncertain (you’ve made a partial change, you’ve disagreed but want a discussion), reply before resolving. Capture the decision in the comment thread itself. Six months later, when someone wonders ‘why did we change this?’, the resolved comment thread tells them. That’s what makes comments more powerful than email — they preserve reasoning in context.

When you’ll use this

• When feedback has been actioned and the comment is no longer outstanding.
• When you want to declutter the active comments without losing history.
• When a comment thread has reached a clear decision.
• When you’re finalising a document and need to clear out completed feedback.

How to do it

1. Open the document and review each open comment.
2. Reply if needed to confirm the change made or the decision reached.
3. Click Resolve on the comment.
4. If the issue returns later, Reopen the comment rather than creating a new one.
5. Save and move on.

Best practices

• Resolve as you go. Don’t leave it all to the end.
• Reply with a quick ‘Done’ or ‘Updated to X’ before resolving. Preserves the decision.
• Don’t delete comment threads casually. Resolve, don’t delete — the history might matter later.
• Use Reopen instead of new comments. Keeps the thread together when issues return.

Common mistakes

• Deleting comments instead of resolving. Loses the audit trail.
• Resolving without replying. Six months later, no one knows what was decided.
• Letting comment count grow into the hundreds. Documents become unreadable. Resolve actively.

↑ Back to top ↑ Back to list

Track Changes shows every edit, attributed to the person who made it. Essential for formal review where accountability matters.

Track Changes is the formal-review mode of Word. Once turned on, every insertion is shown underlined, every deletion is shown struck through, and every edit 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, this is overkill. For documents where accountability matters — contracts, policies, regulated content, anything legal — it’s the standard.

The mechanics are simple. Review tab → Track Changes → on. From that moment, every edit is recorded. You can see all markup, simple markup (cleaner view, edits collapsed to vertical bars), or final/original (preview without markup). When the review is finished, someone walks through changes accepting or rejecting them. The result is a clean final document with a complete record of how it got there.

The thing that goes wrong with Track Changes is half-adoption. If half the team has it on and half doesn’t, the document becomes a confusing mix of tracked and untracked edits. Worse, people sometimes forget Track Changes is on and send the document externally with all the editing history visible. Always check before sending. And agree as a team: either we’re all using Track Changes for this document, or none of us is.

When you’ll use this

• When a document needs formal review and approval (policies, contracts, controlled documents).
• When multiple reviewers will edit and you need to see who proposed what.
• When an audit trail of edits is required.
• When you’re working with external lawyers, auditors, or reviewers who expect Track Changes.

How to do it

1. Open the document in Word.
2. Go to the Review tab.
3. Click Track Changes — it stays on until turned off.
4. Make edits as normal — every change is recorded with attribution.
5. Use Comments for discussion alongside edits.
6. Switch view between Simple Markup (clean) and All Markup (everything visible) as needed.
7. Save — version history preserves the document with markup at each save.
8. Accept or reject changes (see C-09) when review is complete.

Best practices

• Turn it on before edits start. Edits made before Track Changes is on aren’t tracked.
• Use Comments alongside Track Changes. Different tools for different jobs.
• Agree the workflow upfront. Who reviews, who accepts, who finalises.
• Always check before sending externally. Tracked edits leak more than people realise.
• Save a clean final version. Once changes are accepted, save without markup for distribution.

Common mistakes

• Sending a Track Changes document externally without checking. Editing history visible to outsiders. Always preview as ‘No Markup’ before sending.
• Half the team using Track Changes, half not. Confuses the audit trail.
• Accepting all changes without reading. The whole point of Track Changes is review. Read each one.

↑ Back to top ↑ Back to list

When the review is done, someone has to walk through every change and decide what stays. The cleaner the pass, the cleaner the final document.

Accept/Reject is the closing act of a Track Changes review. Once the document has been edited by reviewers, someone — usually the document owner or named approver — needs to walk through every change and decide whether to keep it or discard it. The result is a clean, final document with all the agreed changes incorporated, and a version history showing exactly how it got there.

Word makes this straightforward. The Review tab has Accept and Reject buttons, plus a Next button that walks you through changes 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 level of granularity depends on the document and your level of trust in the reviewers’ edits.

The key principle is that this is real work, not rubber-stamping. ‘Accept All’ is the wrong answer for any document where individual changes matter — and for most documents in formal review, individual changes do matter. Walk through each one. Read it in context. Make a deliberate decision. Yes, it takes longer than ‘Accept All’. The whole point of having a review process is that the result reflects deliberate decisions.

When you’ll use this

• When a Track Changes review is complete and the document needs finalising.
• When you’re the named approver for a controlled document.
• When tracked changes have accumulated and the document is becoming hard to read.
• When you need to produce a clean final version with no markup.

How to do it

1. Open the document in Word.
2. Go to the Review tab.
3. Set view to All Markup so every change is visible.
4. Use Next to step through changes in order.
5. Click Accept to incorporate, or Reject to discard.
6. Use Comments to confirm intent before rejecting if you’re unsure.
7. Once all changes are processed, turn Track Changes off.
8. 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 the wrong answer for most documents.
• Save before finalising. So you can roll back if needed.
• Remove markup before publishing. Final documents should be clean.

Common mistakes

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

↑ Back to top ↑ Back to list

Sometimes you need to know exactly what changed between two versions. Word’s Compare feature shows you in seconds — without you reading both end to end.

When you’ve received an updated version of a document and need to know what’s different, manual comparison is slow and error-prone. Word’s Compare feature does it in seconds — take two versions, produce a third document showing every change colour-coded by type (insertion, deletion, formatting). It’s the same diff view you’d see in Track Changes, but applied to two existing documents that don’t have markup.

This is enormously useful when you’ve received an updated draft from someone else and need to know what’s changed. Or when two drafts have diverged and you’re reconciling them. Or when you’re auditing a document set and need to spot what’s different between versions. Compare doesn’t change either original — it produces a new comparison document 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 — every formatting tweak shows up alongside the substantive changes. For those, sometimes a focused review of specific sections is faster, possibly combined with Copilot for high-level summarisation of what’s changed. Use the right tool for the depth of comparison you need.

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

1. Open Word.
2. Go to Review → Compare → Compare.
3. Select the Original document (older version).
4. Select the Revised document (newer version).
5. Choose comparison settings (most defaults are fine).
6. Click OK — Word generates a third document showing all differences.
7. Review and either accept changes into a clean version or use the diff to guide manual reconciliation.

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.

Common mistakes

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

↑ Back to top ↑ Back to list

If a file has been overwritten, deleted, or broken, version history can usually bring it back in seconds. Knowing this exists changes how confidently you work.

Every time you save a file in SharePoint or OneDrive, Microsoft 365 records a new version. By default, libraries keep at least the last 500 major versions. This means: if something goes wrong — accidental deletion, content overwritten, formatting destroyed, file corrupted — you can almost always recover. Version restore is one of the most-used features once people know it exists, and one of the least-known until they need it.

The flow is simple. Open version history on the file. Browse the list of saves with timestamps and authors. Open any version to preview it. If it’s the right one, restore it — this makes the older version current, while keeping the (now-broken) version in history too. So even restore is reversible. You’re never one click from permanent loss.

What this does to your collaboration confidence is significant. Once your team knows version restore exists and works, the fear of editing disappears. Mistakes become easy to fix instead of catastrophes. The whole ‘I’d better make a backup copy first’ impulse — which causes most version chaos — goes away. Stay in the cloud file. Trust the system.

When you’ll use this

• When something has been overwritten, deleted, or changed accidentally and you need to roll back.
• When a formatting change has broken a document.
• When you want to see what a file looked like at a specific point in time.
• When recovering from a bad merge or unintended edit.

How to do it

1. Open the file in SharePoint or OneDrive.
2. Click More options (three dots) on the file or open the file menu.
3. Select Version history.
4. Review the list of versions, dates, authors, and check-in comments.
5. Click any version to open and preview it.
6. If it’s the right one, click Restore to make it the current version.
7. Confirm the restore.

Best practices

• Restore is non-destructive. The current version becomes a previous version — you can always restore again.
• Use version history instead of saving ‘final_v3’ files. SharePoint already does versioning.
• Train your team that nothing is lost immediately. Reduces panic and prevents bad recovery decisions.
• Educate users to edit in place rather than re-uploading. Re-upload breaks version history.

Common mistakes

• Recreating content from scratch when a previous version existed. Wasted hours.
• Downloading old versions and saving them as new files. Breaks version history. Restore in place instead.
• Not knowing version history exists. Train your team. This single feature prevents huge amounts of stress.

↑ Back to top ↑ Back to list

OneDrive lets you keep working when your internet drops, then syncs your changes when you reconnect. Genuinely useful for travel, dodgy connections, and focus time.

Offline work used to mean either local files (which broke versioning) or just not working until the internet came back. OneDrive sync changes this. Once a file is synced to your computer, you can edit it offline — make your changes locally, save normally, close your laptop. When you reconnect, OneDrive automatically syncs your changes back to the cloud. Other people see them as soon as sync completes. It feels like magic the first time.

The key feature is Files On-Demand. By default, synced files don’t take up space on your hard drive — they appear as placeholders that download on demand when you open them. You can mark specific files or folders as ‘Always keep on this device’ for guaranteed offline access. This gives you the best of both worlds: the cloud’s space and version control, plus reliable offline access for files you genuinely need.

The thing to watch is conflicts. If you edit a file offline, and your colleague edits the same file online while you’re away, you’ll have two divergent versions when you reconnect. OneDrive handles this with conflict resolution prompts — but it’s still extra work. For files actively co-edited, prefer staying online. Offline mode is best for files only you’re editing during the offline window.

When you’ll use this

• When you’re travelling, on a flight, or working from a poor connection.
• When you want guaranteed access to specific files regardless of network.
• When you’re heading into focus time and don’t want sync notifications.
• When you’re working on personal drafts that don’t need real-time sync.

How to do it

1. Make sure OneDrive is installed and signed in on your computer.
2. Open File Explorer (Windows) or Finder (Mac) and navigate to the OneDrive folder.
3. Right-click the file or folder you want available offline.
4. Select Always keep on this device.
5. Edit files normally — changes save locally first.
6. When you reconnect, OneDrive syncs your changes automatically.

Best practices

• Only mark important files as ‘Always offline’. Marking everything fills your hard drive.
• Avoid editing files offline if others are also editing them online. Conflicts will follow.
• Check sync status before closing your laptop. Make sure changes have uploaded.
• If sync conflicts happen, resolve immediately. Don’t ignore them — they accumulate.

Common mistakes

• Editing a co-authored file offline while others edit online. The merge work is real and unavoidable.
• Closing the laptop without checking sync status. Changes sit on your machine until you reopen — and might be lost if anything goes wrong.
• Marking everything offline. Defeats the storage advantage of cloud files.

↑ Back to top ↑ Back to list

Sometimes you need to lock a file while you make significant changes. SharePoint’s check-out is the right tool — but use it sparingly.

Most of the time, co-authoring is the right collaboration model — multiple people in the same file, edits flowing live. But sometimes you need exclusive access: you’re restructuring a document, doing major formatting work, updating a controlled template, or making changes where someone else’s parallel edits could cause real problems. SharePoint’s check-out feature gives you that exclusive access.

When you check out a file, it’s locked to you. Others can read the last checked-in version, but they can’t edit. While the file is checked out, you can save as often as you want without anyone else interfering. When you’re done, you check it back in — releasing the lock and creating a new version with your changes. The team knows where they stand: ‘in progress’ or ‘available’.

Use check-out sparingly. The default for everyday collaboration should be co-authoring, not check-out. Check-out is for the moments when serial editing genuinely beats parallel editing — major restructuring, controlled-document updates, situations where conflicts would be expensive. The risk with check-out is forgetting to check files back in. A file checked out on Friday and forgotten over a week of leave locks the team out for the whole week. Check files in promptly.

When you’ll use this

• When you’re making major structural changes to a document.
• When you’re updating a controlled document where parallel edits would cause problems.
• When you’re updating a template that others would otherwise be using.
• When you need to ensure no one else changes the file mid-edit.

How to do it

1. Open the SharePoint library.
2. Select the file (don’t open it yet).
3. Click More options (three dots) and select Check out.
4. Open the file and make your changes — others can read but not edit.
5. Communicate to your team that you’ve checked it out (especially for files used daily).
6. When done, return to the library, select the file, and choose Check in.
7. Add a meaningful check-in comment describing what changed.

Best practices

• Use check-out sparingly. Co-authoring is the default for a reason.
• Check files in promptly. Don’t leave files checked out overnight or before leave.
• Always add a check-in comment. Future you and your team need to know what changed.
• Communicate when checking out shared files. A quick chat saves confusion.

Common mistakes

• Forgetting to check files back in. Most ‘I can’t edit this’ tickets are about a forgotten check-out.
• Enforcing check-out on busy collaborative libraries. Forces serial editing where parallel would be faster.
• Using check-out as a security measure. It’s not — it’s a coordination tool. Use proper permissions for actual restriction.

↑ Back to top ↑ Back to list

A new project needs a shared place for files, conversations, and shared work. A Microsoft Team (with its built-in SharePoint site) is usually the right answer.

Every new project hits the same question early: where do we put everything? Files, meeting notes, planning documents, conversations, decisions — they all need a home. The wrong answer is ‘everyone’s email and OneDrive’, which guarantees chaos. The right answer for most teams is a Microsoft Team — which automatically creates a SharePoint site behind it, gives you channels for different workstreams, and provides chat and meetings in the same place.

Setting one up takes minutes. Create the Team, name it for the project (clearly — ‘Acme Q3 Implementation’, not ‘Project X’), add members with appropriate roles (Owners and Members), and set up channels for the main workstreams. Most projects need a General channel (for everything) plus 2-4 topic channels (e.g. Planning, Execution, Reporting). Don’t over-engineer; you can add more channels later as needs emerge.

The structural decision that matters most is keeping files in the right place. Files attached to chat go to your personal OneDrive (and disappear when you leave). Files uploaded to a channel’s Files tab go to the team’s SharePoint site (and stay with the team forever). Always upload important files to the channel, not the chat. This single habit, applied across an organisation, prevents a huge amount of organisational knowledge loss.

When you’ll use this

• When a new project is starting and needs a workspace.
• When you’re tired of project files scattered across emails, OneDrives, and chats.
• When the project team needs both files and conversations in one place.
• When you want a single source of truth for the project’s content.

How to do it

1. In Teams, click Join or create a team → Create team.
2. Choose a template (or ‘From scratch’ for a generic team).
3. Name the team clearly — include the project name and year if useful.
4. Add members with the right roles (Owners can manage; Members participate).
5. Create channels for the major workstreams — keep it to 3-5 to start.
6. Use the Files tab in each channel for shared documents (stored in SharePoint).
7. Pin key resources as tabs (planning doc, project plan, key links).

Best practices

• One Team per major project. Don’t over-fragment by creating Teams for every sub-project.
• Name channels clearly. ‘Sprint Planning’ is clearer than ‘Discussion 1’.
• Store files in channels (Files tab), not chat. Chat files don’t follow team permissions.
• Assign Owners early. Two named Owners is the right number — accountability without a single point of failure.
• Pin a ‘start here’ message. Quick orientation for new joiners.

Common mistakes

• Creating a Team for every tiny sub-project. Team sprawl is real. Most projects can live as channels in an existing Team.
• Storing important files in chat. They live in your OneDrive and disappear when you leave.
• No clear Owner. When everyone owns it, no one owns it. Name two Owners explicitly.
• Letting channels die without archiving. Inactive channels clutter the workspace.

↑ Back to top ↑ Back to list

A shared workspace only works if people can find what they need. A bit of structure up front saves the team hours every week.

Most teams put effort into the first step (creating a Team or SharePoint site) and then skip the second step (organising it well). The result is a shared workspace that’s only marginally better than what came before — files dropped randomly, no consistent naming, deep folder trees nobody wants to navigate. The team adapts by emailing people to ask ‘where’s the file?’ instead of finding it themselves.

Good organisation isn’t complex. It’s: a few clear top-level folders or libraries that match how the team actually thinks about its work; consistent naming (date prefixes, no version numbers in filenames); metadata for the things that matter (Document Type, Status, Owner); views that surface what’s current and what’s done. None of this is exotic — it’s the same set of habits applied consistently.

The single highest-impact decision is using metadata instead of deep folder hierarchies. Folders are easy to create and impossible to maintain at scale. Metadata is harder to set up but dramatically easier to use once it’s in place. A library with three metadata columns and good views beats a library with 50 nested folders, every time. The break-even is around 200-500 files; beyond that, folder-only structures become actively painful.

When you’ll use this

• When you’re setting up a new shared workspace.
• When you’ve inherited a messy workspace and need to clean it up.
• When the team keeps asking ‘where’s the file?’ and the answer is always different.
• When you want to make Copilot and search work better across team content.

How to do it

1. Agree on a simple top-level structure — usually 4-7 folders or libraries that match how the team thinks.
2. Establish naming conventions (use ISO dates, plain English, no version numbers in filenames).
3. Add 2-4 metadata columns (Document Type, Status, Owner, Department).
4. Create a few useful views (group by type, missing metadata, recent).
5. Document the structure briefly in a ‘how this site works’ page or pinned post.
6. Train the team on the convention — 5-minute session, every team member.
7. Review structure quarterly and adjust as use grows.

Best practices

• Avoid deep folder hierarchies. Three levels deep is the practical limit before navigation becomes painful.
• Design for search and metadata, not browsing. Modern SharePoint is best used as a database.
• Keep ownership clear. Each library or folder should have a named owner.
• Review and refine quarterly. Structure that worked at 200 files might not work at 2,000.

Common mistakes

• Replicating your old shared drive structure in SharePoint. You import the mess. SharePoint is more powerful — use the metadata layer.
• No naming convention. ‘Doc1.docx’, ‘Final.docx’, ‘mary’s version.docx’ — chaos.
• Setting up structure once and never reviewing. Use changes; structure should adapt.

↑ Back to top ↑ Back to list

Edit a shared document live during a Teams meeting, with everyone contributing simultaneously. Decisions get captured as they happen — not in someone’s notes after the fact.

Most meetings end with someone saying ‘I’ll update the document and send it round.’ Then they don’t, or they do but it’s three days later, or they do but the wrong version, or they capture half of what was actually decided. Live co-editing during the meeting fixes this completely. The document is open in the meeting. Multiple people contribute. Decisions are captured as they’re made. By the time the meeting ends, the document is already updated.

The mechanics are simple. Make sure the file is in SharePoint or OneDrive (not a desktop). In the Teams meeting, share the file via the chat or attach it via Share. Everyone with edit access can open and contribute simultaneously. Watch presence indicators to see who’s working where. Use comments for things that need follow-up. The document evolves through the meeting in a way email-after-the-fact never matches.

This works best for workshop-style meetings — brainstorms, planning sessions, retrospectives, agenda development, document review. It works less well for status updates or formal presentations, where the focus is on listening rather than editing. Pick the meeting type and the document carefully. When co-editing is right, it’s transformative.

When you’ll use this

• When you’re in a workshop, planning session, or retrospective and want decisions captured live.
• When the meeting is about producing or refining a document together.
• When you’d otherwise be sending notes after the fact.
• When the team wants visibility into changes as they happen.

How to do it

1. Make sure the file is stored in SharePoint or OneDrive (not someone’s desktop).
2. In the Teams meeting, share the file via meeting chat or the Share option.
3. Open the file in Teams or browser for the best co-authoring experience.
4. Multiple people edit at the same time — watch cursors/initials to coordinate.
5. Use Comments for things that need follow-up after the meeting.
6. Confirm the final version is saved before closing the file.

Best practices

• Use one master file, not copies in chat. Don’t upload the same file multiple times.
• Agree who’s ‘driving’ structure while others contribute content. Otherwise it gets chaotic.
• Turn on Track Changes if the document needs formal review later.
• Keep permissions simple. Attendees should have edit access if you expect them to contribute.

Common mistakes

• Sharing a downloaded copy. Defeats co-authoring entirely.
• Multiple people rewriting the same section. Coordinate; don’t overlap.
• No clear driver. Without one person owning structure, the doc becomes incoherent.

↑ Back to top ↑ Back to list

Version history shows you every change a document has ever had. Use it for audits, recovery, or just understanding how something got to where it is.

Every save in Microsoft 365 creates a version. Every version is timestamped, attributed to the person who made it, and (if check-in comments are used) labelled with what changed. The result is a complete edit history of every document — accessible to anyone with appropriate permissions, in seconds.

Most people only think about edit history when something goes wrong (see C-11 for restore). But the wider use is just understanding the document’s evolution. Why does this section say what it says? Who changed the pricing structure? When was this policy last updated? Edit history answers all of these. For controlled documents — policies, procedures, regulated content — edit history is your audit trail.

The quality of edit history depends on whether people add check-in comments. A version list without comments is just a list of dates. A version list with ‘Updated section 3 to reflect new policy’ or ‘Approved by Legal’ tells you exactly what happened. Train your team to add comments when checking in controlled documents. The two seconds it takes pays off massively when audit time arrives.

When you’ll use this

• When you need to understand who changed what and when.
• When auditing a controlled document for compliance.
• When something has changed and you want to know when and by whom.
• When you need to inspect a previous version without restoring it.

How to do it

1. Locate the file in SharePoint or OneDrive.
2. Open the file menu (… or right-click) and select Version history.
3. Review the list of versions including author and timestamp.
4. Open a version to see what it contained at that point.
5. Restore a version if needed (or copy specific content if you only need part).

Best practices

• Use version history as your audit trail. Don’t rely on memory or screenshots.
• Encourage meaningful check-in comments. Future you (or an auditor) needs to know what changed.
• For formal documents, combine versioning with approvals. Owner, approver, version, audit trail — full picture.
• Train teams that co-authoring doesn’t ‘lose’ changes. It records them. Reduces fear of edits.

Common mistakes

• Disabling versioning to ‘save space’. Storage is cheap; data loss is expensive.
• No check-in comments. Version history without comments is much less useful.
• Treating saved-as-new files as version history. ‘Final_v2.docx’ isn’t a version; it’s a duplicate.

↑ Back to top ↑ Back to list

Showing your screen so everyone can follow along is one of the most-used Teams features — and one of the most-mishandled. A few habits avoid the common pitfalls.

Screen sharing in Teams is straightforward — but the common mistakes are everywhere. Sharing your whole desktop instead of one window, accidentally exposing private content (notifications, other tabs, sensitive emails), forgetting to include sound when sharing a video, presenting a tiny window that the audience can’t read. Each one is small, each one is solved by a habit, but together they make screen sharing more painful than it should be.

The key choice is what to share. Screen shares your whole monitor — easy but risky. Window shares one specific app — safer, more focused. PowerPoint Live is the dedicated presenter mode for slides — better for the audience because they can navigate themselves, accessibility-friendly, and shows you presenter notes. For most meetings, share a window or use PowerPoint Live, not the whole screen.

Before you share anything, do a 30-second cleanup. Close sensitive tabs. Disable notifications (or use Do Not Disturb). Increase font sizes if needed. Have the file you want to show already open. The audience experience is dramatically better when you’re prepared, and you avoid the embarrassing ‘unread email from your boss flashes up while presenting to a client’ moment that everyone has at least once.

When you’ll use this

• When you need to show a document, demo a tool, or present slides.
• When walking someone through a process visually.
• When training or onboarding someone live.
• When debugging a problem together.

How to do it

1. In the meeting, click Share.
2. Choose what to share: Screen, Window, or PowerPoint Live.
3. Turn on Include computer sound if sharing video or audio.
4. Use the presenter toolbar at the top to switch content or stop sharing.
5. Watch for notifications — use Do Not Disturb if you want to suppress them.
6. Click Stop sharing when finished.

Best practices

• Share a window, not your whole screen, by default. Cleaner and safer.
• Close sensitive tabs before sharing. Notifications and other apps are visible if you share screen.
• Use PowerPoint Live for presentations. Better audience experience than screen-sharing slides.
• Ask someone to confirm they can see clearly. ‘Can everyone see okay?’ takes 5 seconds and avoids 30 minutes of confused presentation.

Common mistakes

• Sharing your whole screen by default. Exposes more than you intended, almost every time.
• Screen-sharing PowerPoint instead of using PowerPoint Live. Worse for the audience and for you.
• Forgetting ‘include sound’ when sharing video. Audience watches in silence and asks why.

↑ Back to top ↑ Back to list

Whiteboards and shared digital surfaces let everyone contribute ideas at once — far better than one person scribing while others wait their turn.

Brainstorming meetings have a structural problem: one person scribes while others wait their turn, ideas get lost in transcription, the loudest voice dominates, and quieter people don’t contribute. Microsoft Whiteboard fixes this. Everyone in the meeting can add sticky notes, draw, type, and arrange ideas simultaneously. The meeting becomes participatory instead of presentational. More ideas surface, more voices contribute, the output is shaped by the whole group instead of one note-taker.

Microsoft Whiteboard is built into Teams meetings. Click Share → Microsoft Whiteboard, and the surface opens for everyone. Templates exist for common scenarios — SWOT analysis, mind maps, retrospectives, workshop agendas. You can also start blank and build from scratch. Sticky notes are the workhorse: each person adds theirs, then the group clusters them into themes together. The visual nature is part of the magic — abstract ideas become spatial relationships you can see.

The risk with whiteboards is that they’re often where ideas go to die. The session is great, the board is full, and then nothing happens with it. Always end the session by capturing outcomes somewhere durable — task list in Planner, summary in a OneNote page, decisions in a meeting notes document. The whiteboard is the brainstorm; the action is what happens after.

When you’ll use this

• When you need a workshop or brainstorming session.
• When you want everyone to contribute, not just the loudest.
• When the meeting needs a visual surface for clustering ideas.
• When you’re running retrospectives or planning sessions.

How to do it

1. In the Teams meeting, click Share.
2. Choose Microsoft Whiteboard (or add a Whiteboard tab if prompted).
3. Add ideas using sticky notes, text, shapes, or templates.
4. Invite others to contribute live (everyone in the meeting can edit).
5. Cluster ideas into themes together.
6. Save/export outcomes or link the board to your project space.

Best practices

• Start with a template if appropriate. SWOT, mind map, agenda — structured boards focus thinking.
• Set a clear timebox. 10 minutes for ideation, 10 for clustering. Open-ended boards drift.
• Capture outcomes into a durable system. The whiteboard is brainstorm; the action is what comes next.
• Keep boards stored with the project. Don’t let them get orphaned in personal storage.

Common mistakes

• Ending with a beautiful whiteboard and no follow-up. Energy wasted; nothing changes.
• One person dominating the board. If everyone has access, encourage everyone to use it.
• No timebox. Ideation expands to fill the time you give it.

↑ Back to top ↑ Back to list

Getting feedback from several reviewers without it becoming a chaotic inbox of conflicting opinions. The trick is structure — and one shared link.

Asking five people for feedback on a document is one of the most common collaboration scenarios — and one of the most reliably broken. The default approach (email the document, get five replies with five different versions of edits, manually merge them, lose half the suggestions) is so common that whole teams accept it as normal. It isn’t. Microsoft 365 has tools that make this dramatically better — if you use them.

The right approach is one shared link, in the cloud file, with comments enabled. Send the link with clear instructions: ‘Please review by Friday. Use Comments for suggestions and questions. Use Track Changes if you’d edit anything directly.’ All reviewers work in the same file. Their comments live alongside the text. You see all feedback in one place, in context, with the ability to respond and resolve. No merge work. No lost suggestions. Done.

The other half is review etiquette. Set a deadline. Specify what kind of feedback you want (proofreading, content review, structural critique). Use ‘Can comment’ permission if you don’t want direct edits. And after the review, summarise the main themes and decisions back to the group, so reviewers know their input was heard. This is what makes review a conversation instead of a one-way submission.

When you’ll use this

• When you need feedback from multiple reviewers and want consolidated input.
• When you’re tired of merging conflicting versions from email replies.
• When the review needs to be auditable.
• When formal sign-off requires clear evidence of input.

How to do it

1. Store the document in SharePoint or OneDrive.
2. Share a single link with reviewers (Can edit or Can comment as needed).
3. Turn on Track Changes (Word) if direct edits must be visible.
4. Ask reviewers to use Comments and @mention people where relevant.
5. Set a clear deadline and review type (proofreading vs structural).
6. Resolve comments and accept/reject changes to finalise.
7. Send a summary back to reviewers showing what was incorporated.

Best practices

• One link, never multiple copies. The single highest-impact rule.
• Set a clear deadline and instructions. Vague reviews produce vague output.
• Use Can comment for review-only. Stops well-meaning reviewers from editing directly.
• Summarise and follow up. Closes the loop with reviewers.

Common mistakes

• Emailing the document for review. The single biggest source of merge-pain.
• No deadline. Reviews drift forever.
• No follow-up after the review. Reviewers feel ignored, won’t engage next time.

↑ Back to top ↑ Back to list

Templates remove the repetitive work of starting from scratch every time. Used well, they enforce consistency and embed best practice as the path of least resistance.

If your team produces the same kind of document over and over — meeting minutes, reports, proposals, project plans — you should have a template. The math is simple: 5 minutes of formatting per document × 50 documents per year = 4 hours of pure waste, every year, that a template eliminates. Beyond time saved, templates ensure consistency: every document has the right structure, the right branding, the required sections. The team’s output looks intentional rather than improvised.

Building a template is straightforward. Create the document with your standard layout, styles, headings, and sections. Include guidance text in [brackets] or italics so users know what to fill in. Save it to a central location — usually a ‘Templates’ folder in the team’s SharePoint library, with restricted edit permissions so only owners can change it. Then tell the team: ‘For X documents, start from this template.’

The trap is over-engineering. A 30-page proposal template that nobody understands gets ignored — people copy old proposals as starting points instead, perpetuating yesterday’s mistakes. Keep templates lean: just enough structure to be useful, not so much that they’re prescriptive. Review templates quarterly so they stay current. And put a named owner on each one — without ownership, templates drift.

When you’ll use this

• When your team produces the same kind of document repeatedly.
• When new starters keep copying old documents and getting it slightly wrong.
• When your team’s output lacks consistency.
• When you want to make best practice the default rather than an exception.

How to do it

1. Create the document with your standard layout, styles, and structure.
2. Save it to the right SharePoint library (not a personal desktop folder).
3. Set the template to read-only for most users (or store in a Templates folder with limited editors).
4. Tell the team to use New → From template or Copy to.
5. Add guidance text inside the template ([fill in date], [project name]).
6. Review and update the template quarterly so it stays current.

Best practices

• Lock down who can edit the template. A small owner group.
• Use a clear naming convention. ‘TEMPLATE – Meeting Minutes’ makes it instantly recognisable.
• Keep templates in one dedicated location. Avoid duplicates.
• Add guidance inside the template. Tells users exactly what to do.

Common mistakes

• Over-engineering templates. 30-page templates nobody uses; users copy old documents instead.
• No template owner. The template drifts, becomes stale, gets abandoned.
• Templates scattered across personal folders. Multiple slightly-different versions, none authoritative.

↑ Back to top ↑ Back to list

External collaboration done right means clean access, clear permissions, and easy clean-up. Done wrong, it’s a mess that lingers for years.

Collaborating with people outside your organisation — clients, contractors, partners, suppliers — is increasingly normal. SharePoint and OneDrive support it natively, but the patterns that work for internal collaboration don’t always transfer. External collaborators don’t have access to your tenant by default, so sharing has to be deliberate. They might leave projects without your knowing, so clean-up matters. They might be on a competitor’s tenant by next year, so over-sharing is a real risk.

The fundamentals are simple. Store the document in SharePoint or OneDrive (never email it). Use Share with the right link type: Specific people for targeted access, with the external person’s email. Set permission level (view vs edit) deliberately. Add an expiry date if your tenant supports it. The recipient gets a sign-in link; they authenticate; they have access. Standard MFA still applies — security stays intact.

The discipline that matters most is clean-up. External access shouldn’t outlive the project. When the work ends, remove access. When the contractor’s contract ends, remove access. When a client engagement closes, remove access. Quarterly audits of external sharing are not optional for any team that does this regularly — set the rhythm and stick to it.

When you’ll use this

• When you need a client or contractor to review or edit a document.
• When working with external suppliers or partners on shared content.
• When a project requires input from people outside your tenant.
• When you’d otherwise be emailing the document as an attachment.

How to do it

1. Store the document in SharePoint or OneDrive (don’t email it).
2. Click Share and choose Specific people.
3. Add the external person’s email and set permission (view or edit).
4. Add an expiry date if your tenant supports it.
5. Confirm access works (or ask them to confirm).
6. When the work is done, use Manage access to remove their access.

Best practices

• Prefer sharing from SharePoint or Teams. Centralised access management vs OneDrive sprawl.
• Use the least-permissive link that does the job. View beats edit if edit isn’t needed.
• Avoid forwarding links. Send the official share link only.
• Audit external access quarterly. Clean up old engagements before they accumulate.

Common mistakes

• Using ‘Anyone with the link’ for sensitive content. The link can be forwarded.
• Sending attachments instead of links. Loses control immediately.
• Never auditing external access. Old contractors retain access for years.

↑ Back to top ↑ Back to list

@mentions in comments turn passive feedback into directed action. The notification finds the right person; the response happens in context.

Most feedback fails because it’s never seen. You add a comment, the document goes back to normal, the person you wanted to respond doesn’t notice. @mentions fix this completely. When you mention someone in a comment, they get a notification — in Teams, in email, on their phone — that takes them straight to the comment. They can’t miss it; they can respond directly; the loop closes.

The mechanics are universal across Microsoft 365 — Word, Excel, PowerPoint, Teams chat, Loop components, and more. Type @ in a comment, start typing the person’s name, select them from the list, then write your message. They get notified. They reply in the comment thread. The notification has a link straight to the relevant comment in the relevant document.

Use mentions for actions, not commentary. ‘Sarah, can you confirm the Q3 numbers in this paragraph?’ is a good mention — clear ask, clear response expected. ‘Sarah, this is about your area’ is a weak mention — passive, no action. The strength of @mention as a tool is directly tied to how clearly you specify what you need from the person you’re mentioning.

When you’ll use this

• When your comment specifically needs a response from a particular person.
• When you want to assign a question or action to someone in the document.
• When you want to make sure a comment doesn’t get missed.
• When you’re following up on someone’s earlier feedback.

How to do it

1. Open the document in Word, Excel, or PowerPoint (web works best for comments).
2. Add a comment where you need input.
3. Type @ and select the person’s name from the list.
4. Write your question clearly and assign any action or date if needed.
5. Send — the person gets a notification with a link to your comment.
6. Resolve the comment once they’ve responded and acted.

Best practices

• Use @mentions for questions or actions. Don’t bury asks in long passive comments.
• One comment, one topic. Easier to resolve, easier to track.
• Be specific about what you want. Approve, rewrite, confirm, decline — name it.
• Resolve comments once handled. Don’t let documents become comment graveyards.

Common mistakes

• Mentioning everyone for general commentary. Notification fatigue; people stop reading.
• Vague mentions (‘thoughts?’). Passive, no action, low response rate.
• Never resolving mentioned comments. The person responded; close the loop.

↑ Back to top ↑ Back to list

The Recent and Pinned views in Microsoft 365 surface the files you actually use. Once you start using them, you stop hunting.

Most people spend more time hunting for files than they should. They navigate through folders, search by half-remembered names, ask colleagues ‘where’s that file?’ — when actually, the file they want is one of the dozen they used yesterday, and Microsoft 365 already knows that. The Recent view (in OneDrive, in Office.com, in any Office app) shows the files you’ve worked on most recently, regardless of where they’re stored. Use it instead of folder navigation, and the hunting evaporates.

Pinning takes this further. Files you use repeatedly — your team’s running notes, your personal task list, the policy you reference weekly — can be pinned so they stay at the top of Recent. They’re always there, always one click away. Combined with following important SharePoint sites and pinning channels in Teams, you build a personal navigation layer that’s optimised for what you actually do, not for the broader org structure.

What this enables, ultimately, is a different relationship with file storage. You stop caring exactly where files live (because you don’t navigate to them anyway) and start trusting that the system surfaces what you need. The library structure becomes the team’s organisation; your personal access is via Recent, Pinned, and Search. Both work together — but only the latter scales to the volume of files most modern workers deal with.

When you’ll use this

• When you’re losing time hunting for files you used recently.
• When you have a small set of files you use every day and want one-click access.
• When you’ve been working across multiple projects and need to surface what’s current.
• When onboarding to Microsoft 365 and want a more efficient access pattern.

How to do it

1. Open Microsoft 365 (office.com), OneDrive, or any Office app.
2. Look for the Recent or For You view.
3. Use Search and filters (type, people, date) to narrow if needed.
4. Open the file from the Recent list — this takes you to the real location.
5. Pin or favourite key files so they stay easy to find.

Best practices

• Use meaningful file names. Recent and Search both depend on it.
• Pin only genuinely frequent files. Too many pins defeats the purpose.
• Don’t download and re-upload. Keep one source of truth so Recent works.
• Combine Recent with Followed sites and pinned channels for a personal workspace.

Common mistakes

• Hunting through folders for files you used yesterday. Recent is right there.
• Generic file names (‘Document1.docx’). Useless in Recent and search alike.
• Pinning everything. Pinning loses meaning.

↑ Back to top ↑ Back to list

A handful of pinned files takes you straight to your daily work — no navigation, no search, no context-switching cost.

Pinning is the discipline of choosing what’s actually important. Not the 50 things you might need, but the 5 you do need every day. Once you pin them — at the top of OneDrive Recent, in Teams channel tabs, in browser bookmarks — they’re always there. The cost of accessing them drops to almost zero. Across a year, that’s hundreds of context-switches saved.

Different surfaces let you pin in different ways. OneDrive lets you pin individual files at the top of Recent and Shared views. Teams channels let you pin documents as tabs at the top of the channel — visible to the whole team, not just you. SharePoint sites let you favourite or follow them so they appear in your SharePoint home. Pick the right pinning level for the right purpose: personal pins for your own work, team tabs for shared work everyone needs.

The discipline is to keep pin counts low. The whole point is fast access — and fast access requires being selective. If you’ve pinned 30 files, you’re back to scanning. Pick the 5-10 files you genuinely use daily; pin those; let everything else live in Search or Recent. Periodically prune pins that no longer match your workload.

When you’ll use this

• When you have files you use every day and want one-click access.
• When the team needs to access a particular file frequently and you want it visible to everyone.
• When onboarding to a new role and want quick access to key resources.
• When you’re building a personal access layer optimised for your work.

How to do it

1. Find the file in OneDrive or the SharePoint library.
2. Select the file and choose Pin or Add to favourites.
3. If in Teams, add the file as a tab in the relevant channel for team-wide quick access.
4. Use the pinned/favourite section to access it quickly.
5. Unpin when it’s no longer needed to keep the list focused.

Best practices

• Pin only the truly frequent files. 5-10 is a useful range; 30 is back to scanning.
• Use Teams tabs for team-wide pins. Pinning for the team is more powerful than pinning for yourself.
• Keep pinned files in a stable location. Don’t move them around constantly.
• Prune pins quarterly. Workloads change; pins should follow.

Common mistakes

• Pinning too many files. Defeats the purpose.
• Pinning files you’ll only use once. Use Search or Recent for one-offs.
• Personal pins for team-critical files. Use a Teams tab so everyone benefits.

↑ Back to top ↑ Back to list

Activity tracking shows who’s actually opened your file — useful for follow-ups, but never for performance management.

When you share a file with a group — for review, for information, for action — there’s often a question afterwards: who actually looked at it? SharePoint and OneDrive track file activity (views, edits, opens, shares) and surface this in the file’s Details pane or Activity feed. You can see who’s engaged with the file and when, which is useful for follow-up reminders and understanding adoption.

Use this judiciously. Activity tracking is best for prompting follow-ups: ‘Three people on the review list haven’t opened the document — let me ping them before the deadline.’ It’s a tool for chasing the work along, not for surveilling colleagues. Treating activity data as performance data is bad for trust, bad for culture, and produces nothing useful — people who feel surveilled find ways to game the metric without actually engaging with the content.

The deeper limitation: activity ≠ comprehension. Someone opens a file; that doesn’t mean they read it. Someone scrolls to the bottom; that doesn’t mean they understood it. Use activity data as a prompt for human follow-up — a real conversation about whether the content landed — not as evidence of engagement on its own.

When you’ll use this

• When you need to confirm who has opened a shared document.
• When following up on review or sign-off and want to chase non-responders.
• When investigating who has had access to a sensitive file.
• When understanding adoption of a key document or process.

How to do it

1. Open the file location in SharePoint or OneDrive.
2. Select the file and open Details or Activity.
3. Review the activity list to see opens, edits, and recent actions.
4. Follow up with people who haven’t viewed it (re-share if needed).
5. Capture activity for audit purposes if your governance requires it.

Best practices

• Use activity for follow-up prompts, not performance management. Trust matters.
• Combine with explicit confirmation. ‘Have you reviewed?’ beats ‘I see you opened it.’
• Activity ≠ comprehension. Don’t equate the two.
• For regulated scenarios, align with audit policies. Don’t capture more than you need.

Common mistakes

• Using activity data to monitor colleagues. Cultural cost is real.
• Treating opens as engagement. They’re not the same thing.
• Skipping the follow-up conversation. Numbers don’t replace relationships.

↑ Back to top ↑ Back to list

Shared OneNote notebooks are perfect for ongoing team knowledge — meeting notes, project research, decisions, anything that benefits from being captured collectively.

OneNote is the unsung hero of Microsoft 365 collaboration. It’s flexible (free-form pages, sections, sub-pages), persistent (everything is saved automatically), shared (multiple people can edit a notebook together), and searchable (find anything across all your notebooks). For team knowledge that doesn’t fit neatly into Word documents — meeting notes, project research, ongoing decisions, accumulating context — OneNote is often a better fit than a structured library of separate files.

A team OneNote notebook lives in your Team’s SharePoint site (automatic) or anywhere you put it (manual). Each notebook contains sections (like tabs), each section contains pages (like paper notes). The structure is light enough to capture rapidly-evolving knowledge but enough to find things later. Multiple people can edit the same page simultaneously, just like Word — your notes appear in real time, with everyone’s contributions visible.

The trap with OneNote is letting it become a chaos of unnamed pages. Without naming conventions and section structure, the notebook becomes a bag of fragments — full of information, impossible to retrieve. Apply the same discipline to OneNote that you’d apply to a SharePoint library: clear sections, dated and titled pages, periodic clean-up of stale content. Done well, OneNote scales better than files for ongoing team knowledge.

When you’ll use this

• When your team needs a shared space for ongoing notes and knowledge.
• When information is too fragmented to fit in a structured Word document.
• When meeting notes, decisions, and research need to live together.
• When you want a low-overhead way to capture team knowledge.

How to do it

1. Create or open the OneNote notebook stored in the Team or SharePoint site.
2. Share the notebook with the right people (Members vs Visitors).
3. Create sections for topics (Meetings, Decisions, How-To, Research).
4. Agree on simple page naming (date + topic) so it stays searchable.
5. Review and tidy the notebook periodically.

Best practices

• Structure first. Sections + naming rules. Otherwise it becomes chaos.
• Link to the notebook from the team’s home page. Discoverability matters.
• Use one notebook per team or project. Not 12 competing notebooks.
• Summarise key decisions into formal records too. OneNote is the working space; the formal record might live elsewhere.

Common mistakes

• No structure or naming. Notebook becomes a graveyard.
• Multiple notebooks per team. Splits team knowledge.
• Treating OneNote as the official record for everything. Some content needs more formal storage.

↑ Back to top ↑ Back to list

Loop components are tiny shared documents that travel between Teams, Outlook, and other apps — perfect for short-lived collaborative content.

Microsoft Loop is one of the newer additions to Microsoft 365 — a way to create small, focused, collaborative components (a table, a checklist, a task list, an agenda) that can be embedded in Teams chat, Outlook email, and Loop pages. The same component appears in multiple places, but it’s the same content — edit it in one place, and the change appears everywhere it’s embedded.

Where this is useful is for fast, lightweight collaboration that doesn’t need a full document. A meeting agenda you build collaboratively in chat. A checklist of tasks shared in an email. A status table updated by multiple people across different conversations. Loop components are designed for this kind of small, shared, fluid content — too small to be a Word doc, too dynamic to be a static list.

Where Loop has limits is for long-term records. Loop components are great for live collaboration but less great as the system of record. Don’t try to use them as your project tracker, your knowledge base, or your formal documentation. Use them for what they’re built for — short-lived collaborative content — and move outcomes into proper systems (Lists, Planner, SharePoint pages) when they need to persist.

When you’ll use this

• When you need a small, shared, editable component in chat or email.
• When multiple people will edit the same content live (a table, list, agenda).
• When the content is short-lived and doesn’t need a full document.
• When you want changes to appear everywhere the component is embedded.

How to do it

1. In Teams chat or Outlook email, click the Loop icon (or paste a Loop component link).
2. Choose a component type (table, checklist, task list, etc.).
3. Add content; share with collaborators by sending the chat/email.
4. Recipients can edit the component in place — changes appear everywhere it’s embedded.
5. When the work is done, capture outcomes into a more permanent system if needed.

Best practices

• Use Loop for live collaboration, not long-term records. Different tools for different jobs.
• Keep components small and focused. One purpose per component.
• Define ownership. Who maintains it? Stops drift.
• Move final outcomes to the right system. Lists for tracking, Planner for tasks, SharePoint for documents.

Common mistakes

• Using Loop as your project tracker. Outgrows the format.
• Building giant Loop components. Defeats their purpose.
• No ownership. Component drifts; nobody updates it.

↑ Back to top ↑ Back to list

When a document needs sign-off, you don’t need to email it around or build a custom workflow. SharePoint’s built-in approval handles most cases.

Sending a document for approval is one of those tasks that gets weirdly complicated when it shouldn’t. The traditional approach — email the doc to your manager, wait, follow up, get a ‘Looks fine!’ reply, hope no one questions whether that counted as approval — works badly. It produces no audit trail, gets lost in inboxes, and depends entirely on people remembering. SharePoint has built-in approval that fixes this without needing custom workflows.

The simplest approach is the file’s built-in Request sign-off option (or the Approvals app in Teams). Right-click the file, request sign-off, choose approver(s), add a clear instruction, set a deadline. The approver gets a notification, opens the file, and clicks Approve or Reject directly. You get a notification of the outcome. The decision is recorded. The audit trail is automatic.

For more complex needs — multi-step approvals, conditional logic, integration with other systems — Power Automate is the tool. But for everyday ‘I need my manager to sign off on this report’ situations, the built-in approval is right. Don’t build a Power Automate flow for something a single click handles. Use the simple tool unless you genuinely need the complex one.

When you’ll use this

• When a document needs formal approval before being published or sent.
• When you need an audit trail showing who approved and when.
• When you’d otherwise be emailing the document for sign-off.
• When approvals are getting lost in email threads.

How to do it

1. Store the document in the correct SharePoint library.
2. Right-click the file or open the file menu.
3. Choose Request sign-off (or use the Approvals app in Teams).
4. Add approver(s), clear instructions, and a deadline.
5. The approver gets notified; they review and approve/reject.
6. Once approved, publish/share the final version.
7. The approval is recorded in the file’s history.

Best practices

• One document, one link, one approval. Don’t email attachments for approvals.
• Be explicit about what you want. ‘Approve as-is’ vs ‘Approve with changes’.
• Use built-in approval first. Build Power Automate flows only when complexity demands it.
• Store final approved version in a governed location.

Common mistakes

• Emailing the document for approval. No audit trail; gets lost; ambiguous outcome.
• Building custom workflows for simple approvals. Over-engineering.
• Vague approval requests. ‘Can you look at this?’ isn’t an approval — it’s a vibe.

↑ Back to top ↑ Back to list

Microsoft 365 can tell you when files change — but only if you set it up. Knowing the right tools for the right notification level keeps you informed without being overwhelmed.

Wanting to know when a document changes is reasonable. Wanting to be notified about every change to every document in every library is unmanageable. The art of file notifications is matching what you’re notified about to what you actually need to know — and using the right tool for each level of urgency.

For high-importance individual files, use Power Automate to send notifications: ‘When [file] is modified, send me a Teams message.’ Specific, controllable, easy to maintain. For team-level awareness, follow the channel — Teams will surface activity in the channel feed. For broader visibility into a library, use SharePoint’s activity feed and version history rather than email alerts (which often become noise).

The tool to mostly avoid is the old SharePoint ‘Alert me’ feature. It still exists but tends to produce email noise that people tune out. Power Automate gives you the same alerting capability with much better targeting (Teams instead of email, conditional logic, batched updates). For modern Microsoft 365, default to Power Automate for important alerts and to channel-following for broader awareness.

When you’ll use this

• When you need to know about changes to a specific high-importance document.
• When you’ve inherited content and want to monitor activity for a while.
• When approvals or reviews depend on knowing when content updates.
• When you want to stay across team activity without checking manually.

How to do it

1. Open the file or library in SharePoint or OneDrive.
2. For specific high-importance files, build a Power Automate flow with a clear trigger (file modified) and action (Teams notification).
3. For broader awareness, follow the SharePoint site or channel.
4. Use the file’s Details pane to view recent activity at any time.
5. Review version history if you need to see what specifically changed.

Best practices

• Use Power Automate for important alerts. Better targeting than old SharePoint alerts.
• Follow channels and sites for broader awareness. Activity feeds vs noisy email alerts.
• Less is more. Three meaningful alerts a week beats thirty unread alerts a day.
• Pair alerts with named ownership. Someone should care about each notification.

Common mistakes

• Alerting on everything. Notification fatigue; alerts get ignored.
• Sending alerts to inboxes nobody monitors. Useless.
• Not auditing alerts quarterly. Old alerts accumulate; you stop trusting any of them.

↑ Back to top ↑ Back to list