` pattern:
- `Get-MgUser`, `New-MgUser`, `Update-MgUser`, `Remove-MgUser`.
- `Get-MgGroup`, `Add-MgGroupMember`, `Remove-MgGroupMember`.
- `Get-MgUserMessage`, `Send-MgUserMail`.
- `Get-MgDeviceManagementManagedDevice` (Intune).
Sub-modules let you install only what you need: `Microsoft.Graph.Users`, `Microsoft.Graph.Groups`, `Microsoft.Graph.Mail`, `Microsoft.Graph.Identity.SignIns` — useful for keeping the install footprint small.
## Service-specific modules that still matter
A few modules remain non-Graph for now:
- **ExchangeOnlineManagement** — still the right module for Exchange-specific work (mail flow rules, mailbox settings, retention).
- **MicrosoftTeams** — Teams-specific configuration that hasn't fully landed in Graph yet.
- **PnP.PowerShell** — community/Microsoft-supported, great for SharePoint deep work.
Graph PowerShell handles the broad cases; reach for the others for service-specific deep configuration.
## Production patterns
- **Use certificate-based authentication** for unattended scripts. App registration in Entra ID + certificate + appropriate Graph permissions.
- **Use managed identities** when the script runs on Azure compute (VM, Function, Logic App).
- **Audit script identities** — service principals with Graph permissions show up in your enterprise apps list. Review them like any other app.
- **Avoid running scripts as a Global Admin user** — that's a Conditional Access mess waiting to happen.
The transition from old modules to Graph PowerShell is well underway. New automation should start there; existing scripts should be migrated over time as their owners touch them.
## Permissions and consent, in practice
Every Graph PowerShell call runs under whatever **delegated or application permissions** were consented to for the session — `Connect-MgGraph -Scopes` requests delegated permissions matching the signed-in user's own rights (an interactive `Get-MgUser` call still respects the caller's actual read access), while unattended scripts using an app registration with **application permissions** and a certificate act with the registration's own granted scopes regardless of who (if anyone) is signed in. Requesting broader scopes than a script actually needs is a common and avoidable risk — `User.ReadWrite.All` when a script only ever reads users, for instance — since Graph PowerShell doesn't narrow what's granted at consent time to what a specific script call uses; the admin consenting the app registration is the only checkpoint, so scoping the request precisely at that point matters more than it might for older, more narrowly-scoped modules.
## Frequently asked questions
**Can Graph PowerShell replace the Exchange Online, Teams, and SharePoint modules entirely?** Not yet, and not on a fixed date — Microsoft continues migrating capability into Graph over time, but several deep, service-specific operations (granular mail-flow rule configuration, Teams policy assignment, SharePoint site-collection administration) still require their dedicated modules. The practical approach is Graph PowerShell as the default for identity, groups, and cross-service scripting, falling back to the service-specific module only for the operations Graph genuinely doesn't cover yet.
**Why does installing the full Microsoft.Graph module feel slow compared to the old AzureAD module?** The full module ships as many sub-modules covering the entire Graph API surface, and importing all of them at once genuinely does take longer than a single-purpose legacy module; installing and importing only the specific sub-modules a script needs (`Microsoft.Graph.Users`, `Microsoft.Graph.Groups`, and so on, rather than the umbrella `Microsoft.Graph` package) is the standard fix and noticeably improves both install and session start time.
**Is the older AzureAD module still safe to use for new scripts?** No — `AzureAD` and `MSOnline` are deprecated, meaning they no longer receive feature updates and are on a retirement path; any new automation should start on Microsoft Graph PowerShell, and existing scripts on the old modules should be migrated opportunistically rather than left to break unannounced when the deprecated modules are eventually withdrawn.
---
# Microsoft Lists templates and patterns
URL: https://www.solvingmicrosoft365.com/guides/microsoft-lists-templates
Category: Viva & Apps
Published: 2026-05-01
> Practical patterns for using Microsoft Lists — templates, column formatting, integrations, and where Lists fits best.
**Microsoft Lists** is a friendly surface on top of SharePoint lists — same engine, better UX. For ad-hoc and lightweight structured data, it's often the right answer over Excel spreadsheets, SharePoint document libraries, or jumping straight to a custom app. Knowing the templates and patterns saves users from reinventing the same things.
Lists are compared with SharePoint lists in [SharePoint Lists vs Microsoft Lists](/guides/sharepoint-lists-vs-microsoft-lists), styled with [list formatting](/guides/sharepoint-list-formatting), and extended with [Power Apps](/guides/what-is-power-apps) and [Power Automate](/guides/what-is-power-automate); for tracking work, compare with [Planner](/guides/microsoft-planner-tasks-and-project).
## What Lists is good for
Lists fits scenarios where you need:
- **Structured rows** with defined columns.
- **Multiple editors** with light permissions.
- **Searchable** with filters, sorts, views.
- **Triggered automation** via Power Automate.
- **Custom rendering** via JSON column / view formatting.
- **Mobile access** via the Lists mobile app.
Common use cases:
- **Issue trackers** for small teams.
- **Inventory tracking** for assets or equipment.
- **Request logs** for help-desk-style intake.
- **Contact lists** beyond a personal Outlook contacts file.
- **Asset registers** with metadata and status.
- **Approval workflows** with status fields and history.
## Built-in templates
When creating a new list, Microsoft offers templates as starting points:
- **Issue tracker** — title, status, priority, assignee, description.
- **Asset manager** — asset name, type, location, owner, condition.
- **Recruitment tracker** — candidate, role, status, interview rounds.
- **Travel requests** — destination, dates, purpose, approval.
- **Work progress tracker** — task, owner, status, due date.
- **Event itinerary** — event, location, schedule items.
- **Onboarding checklist** — new hire, items, completion.
- **Patients** (healthcare-flavoured).
- **Loans** (financial-flavoured).
- **Custom** — start from scratch.
Each template includes pre-defined columns, sample data, suggested views, and formatting. Customise from there.
## Lists in Microsoft Teams
Lists integrates as a **tab in Teams channels**. The list is the same list (in the channel's SharePoint site), but the experience is in the Teams app — useful for teams that live in Teams.
Common pattern: project teams use a Lists tab for the project's issues / actions tracker, with adaptive cards posted to the channel for major changes.
## Column types
Lists supports rich column types beyond just text:
- **Text, multi-line text, rich text**.
- **Number, currency, percentage**.
- **Choice (single / multiple), with conditional dependencies**.
- **Date and time** with reminders.
- **Yes/No**.
- **Person or group** — resolves to Microsoft 365 identities.
- **Hyperlink, image**.
- **Lookup** to another list's column.
- **Calculated** — formulas referencing other columns.
- **Managed metadata** — taxonomy terms from the SharePoint term store.
- **File attachments**.
Each column type has appropriate validation and rendering.
## JSON formatting
For visual customisation:
- **Column formatting JSON** changes how individual column values render — colour, icons, action buttons, progress bars.
- **View formatting JSON** transforms entire rows or list views — cards, tiles, custom layouts.
Microsoft and the community publish hundreds of formatting samples on GitHub. Copy, adapt, save dramatic visual quality improvement.
## Power Automate integration
Lists triggers Power Automate flows:
- **When an item is created** — provision related artefacts (Teams channel, Planner task, ServiceNow ticket).
- **When an item is modified** — notify stakeholders, validate, update other systems.
- **When an item is deleted** — log, archive, prevent.
- **Scheduled flows** — daily summary of new items, weekly digest of overdue tasks.
The combination of Lists + flows replaces a surprising fraction of "we need a little app for this" requests.
## Power Apps integration
For richer UI than Lists offers, **Power Apps** can build canvas apps on top of a Lists data source. Same list, different experience — Lists for general administration, Power App for purpose-built workflows.
## When Lists isn't right
- **Very large volumes** (>5,000 active items per view without indexing) — Lists slows down.
- **Transactional or relational data** — Dataverse is the right answer.
- **Heavy concurrency** — many users editing simultaneously.
- **Public-facing data** — Lists are internal-tenant; for external use, look at Power Pages.
- **Complex many-to-many relationships** — Lists' lookup model is limited.
For these, graduate to **Dataverse** or a real database. Lists is the right entry point; not always the destination.
For Microsoft 365 customers, Lists is one of the more under-used capabilities. A handful of well-designed lists replace a lot of Excel-and-email workflow.
---
# Microsoft Loop component patterns
URL: https://www.solvingmicrosoft365.com/guides/microsoft-loop-component-patterns
Category: Viva & Apps
Published: 2026-05-01
> Practical patterns for using Loop components — where they shine, where they don't, and how to operate them at scale.
**Microsoft Loop components** are portable, real-time collaborative blocks — task lists, tables, paragraphs, Q&As — that can be embedded across Teams chats, Outlook emails, Word documents, OneNote, Whiteboard, and Loop workspaces. Edit anywhere; changes propagate everywhere. Understanding where they shine (and where they don't) makes them genuinely useful rather than just a curiosity.
Loop is introduced in [Microsoft Loop explained](/guides/microsoft-loop-explained); components live in [Teams](/guides/what-is-microsoft-teams) chats and [Outlook](/guides/copilot-in-outlook), roll up into [Loop workspaces](/guides/microsoft-loop-workspaces), and surface in Copilot as [Copilot Pages](/guides/copilot-pages-and-loop-components).
## Where Loop components shine
The pattern that consistently works: **ongoing collaborative content that needs to live in multiple places**.
### Project status tracker
A team starts working on a project. They drop a **Loop task list** into the project's Teams channel. The list shows up in everyone's channel view; when stakeholders ask for an update in a different chat, they paste the same Loop component there. Edit in either place; the other updates.
No more "wait, which version of the status doc is current?" — there's one live component.
### Meeting action items
Take meeting notes in a Loop component embedded in a Teams chat. Action items as a task list update live as the meeting progresses. After the meeting, the same component lives in the post-meeting follow-up email.
Beats "I'll send around the notes after the meeting" by being live during the meeting and persistent afterwards.
### Lightweight shared tracker
For a team running a small recurring process — weekly check-ins, sprint commitments, customer-issue tracker — a Loop component embedded in their working chat is enough. Far less overhead than spinning up a SharePoint list or a Planner plan.
### Q&A and Decisions
The **Q&A component** captures questions and answers in a structured format. Used in meetings or chats to track unanswered questions, decisions made, things to follow up on.
## Where Loop components don't shine
Loop components are NOT good for:
- **Polished final documents** — components are for working content; finished documents go in Word / PowerPoint.
- **Long-form structured documents** — components are blocks; for a 20-page document, use a Word doc or a SharePoint page.
- **Very large datasets** — table components are for small amounts of structured data; for serious data use a SharePoint list or Dataverse.
- **External / public sharing** — Loop components are tenant-internal mostly; for public-facing content use Power Pages or another web platform.
- **Heavy permissions complexity** — Loop's permission model is simpler than SharePoint's.
## Component types
The main block types:
- **Task list** — checkable items with optional assignment, due dates, integration with Planner / To Do.
- **Bulleted / numbered list** — simple list.
- **Table** — small structured grid.
- **Paragraph** — rich text.
- **Heading** — section header.
- **Image** — embedded image.
- **File** — embedded file viewer.
- **Person mention** — `@`-mention resolved to Microsoft 365 identity.
- **Code** — code block with syntax highlighting.
- **Q&A** — question-and-answer interaction surface.
- **Voting / poll** — quick decisions.
Each is composable into longer Loop pages or used standalone as embedded components.
## Permissions
A Loop component's permissions follow its **storage location**:
- **OneDrive-stored** components (personal use) — visible to whoever has access to the OneDrive location.
- **Workspace-stored** components — visible to workspace members.
- **Embedded in a Teams chat** — chat members can see and edit.
- **Embedded in Outlook email** — email recipients can view and edit (within Microsoft 365).
A component's permissions can effectively widen when it's embedded somewhere new — be aware of this when sharing sensitive content via Loop components.
## Governance
For tenants enabling Loop:
- **Sensitivity labels** apply to Loop content via the underlying storage.
- **Retention policies** apply via the underlying SharePoint / OneDrive.
- **eDiscovery** reaches Loop content via SharePoint.
- **External sharing** of Loop content follows SharePoint / Teams external sharing policies.
For most tenants, the **Loop on / off** switch is the main admin decision. Once on, normal Microsoft 365 governance applies.
## Adoption patterns
Loop adoption tends to cluster:
- **Specific teams** adopting heavily for their internal collaboration.
- **Cross-team kickoffs** where Loop components reduce email back-and-forth.
- **Power users** who multiply usage in their networks.
Slower in organisations with strong existing patterns around Teams files, OneNote, or other collaboration surfaces. Don't push Loop where existing patterns work — surface it where it solves the cross-app-sync problem.
For Microsoft 365 customers already comfortable with Microsoft 365 collaboration, Loop components are worth piloting deliberately. They reward users who learn the patterns; they're irrelevant to users who don't.
---
# Microsoft Loop explained
URL: https://www.solvingmicrosoft365.com/guides/microsoft-loop-explained
Category: Viva & Apps
Published: 2026-05-01
> Microsoft Loop is a collaborative document and components platform — what it is and how it fits with the rest of Microsoft 365.
**Microsoft Loop** is Microsoft's modern collaborative document platform — pages built from reusable, real-time **components** that can be embedded across Teams, Outlook, Word, and more. It's Microsoft's answer to Notion, Coda, and the broader category of "blocks-based" collaborative documents.
Go deeper with [Loop component patterns](/guides/microsoft-loop-component-patterns), [Loop workspaces](/guides/microsoft-loop-workspaces), [Loop external sharing and governance](/guides/microsoft-loop-external-sharing), and [Copilot Pages and Loop components](/guides/copilot-pages-and-loop-components). The neighbouring canvas tools are [Whiteboard in meetings](/guides/microsoft-whiteboard-in-meetings) and [Whiteboard for hybrid workshops](/guides/microsoft-whiteboard-hybrid-workshops).
## What Loop is
Loop has two faces:
- **The Loop app** at `loop.cloud.microsoft` — a standalone web app where users create **workspaces** containing **pages**, each built from blocks of content.
- **Loop components** — portable blocks that can be embedded in **Teams chats**, **Outlook emails**, **Word documents**, **OneNote**, **Whiteboard**. The same component is the same live content everywhere.
The key trick: edit a component in Teams chat, and the change appears in the same component embedded in Outlook, with no manual sync.
## The block types
A Loop page or component can include:
- **Paragraphs** of rich text.
- **Headings** (multiple levels).
- **Lists** — bulleted, numbered, checklist, voting.
- **Tables**.
- **Task lists** that integrate with **Planner** and **Microsoft To Do**.
- **Person mentions** that resolve to Microsoft 365 identities.
- **Code blocks** with syntax highlighting.
- **Images, videos, files**.
- **Q&A components**.
- **Embeds** — pull in content from other apps (Figma, Adobe XD, YouTube, etc.).
- **AI-assisted content** generated via Copilot.
## Loop workspaces
A **workspace** is a Loop home for a group of related pages. Workspaces are shared with specific people (not yet with whole tenant directories), with each member getting access to all pages. Backed by a hidden **Microsoft 365 Group** and **SharePoint site** for storage.
Pages within a workspace can be hierarchical (page contains sub-pages), search across the workspace works, and changes flow live.
## Loop and Copilot
When **Microsoft 365 Copilot** generates content in the standalone Copilot Chat experience, you can **export to Pages** — the response becomes an editable Loop page that you can refine collaboratively. This is one of the most underrated Copilot patterns.
## How Loop fits with Microsoft 365
- **OneNote** — Loop is for **collaborative** working documents; OneNote is for **personal or team notebooks** with section/page structure.
- **Word** — Word is for **finished documents** with rich formatting; Loop is for **in-progress collaborative content**.
- **SharePoint pages** — for **published** content with broader audiences; Loop for **working** content.
- **Teams chat** — Loop components are embedded **inside** Teams chat; Loop pages can replace shared docs for ongoing collaboration.
A practical pattern: working notes and brainstorms in Loop, polished output in Word or PowerPoint when needed.
## Governance
Loop content is stored in **OneDrive** (personal) or **SharePoint** (shared via workspaces). It's:
- Subject to **retention policies**.
- Searchable in **eDiscovery**.
- Covered by **sensitivity labels**.
- Auditable via Purview.
Tenant admins enable / disable Loop via the **Microsoft 365 admin center**. New tenants increasingly have Loop on by default.
## When to use Loop
- **Cross-app collaboration** where the same content needs to live in chat, email, and a doc.
- **Working content** that several people contribute to over days or weeks.
- **Copilot output iteration**.
- **Lightweight knowledge management** in a team.
For tasks where Word or SharePoint pages are the obvious answer (finished documents, published intranet), stay with them. Loop is for the messy middle.
---
# Microsoft Loop external sharing and governance
URL: https://www.solvingmicrosoft365.com/guides/microsoft-loop-external-sharing
Category: Viva & Apps
Published: 2026-05-01
> How Loop components and workspaces work with external users — and the governance considerations.
**Microsoft Loop** components and workspaces have a more complex external-sharing story than typical SharePoint files because components are **portable** — they can be embedded in chats, emails, and documents that travel outside the tenant. Governance for Loop requires understanding both the workspace-level model and the component-level travel pattern.
Loop sharing is one thread of [external collaboration explained](/guides/microsoft-365-external-collaboration-explained); it follows [OneDrive sharing and permissions](/guides/onedrive-sharing-and-permissions) and the [SharePoint external sharing](/guides/sharepoint-external-sharing) ceiling, and [sensitivity labels](/guides/purview-sensitivity-labels-deep-dive) apply to Loop content.
## Workspace-level sharing
A **Loop workspace** is backed by a hidden Microsoft 365 Group and SharePoint site. Sharing a workspace is structurally similar to sharing other Microsoft 365 content:
- **Add internal members** — full access to all workspace pages.
- **Add external guests** (where tenant policy permits) — same access as members.
- **Roles** — Member (edit), Read-only (where supported).
The workspace's sharing inherits the SharePoint and Entra ID external-sharing settings. If your tenant blocks external sharing, Loop workspaces can't be shared externally. If it allows guests, Loop workspaces can have them.
## Component-level travel
This is where Loop differs from typical content. A **Loop component** — a list, a table, a task list — embedded in a Teams chat or Outlook email can be **shared with the chat's recipients**, including external ones (if your tenant allows external chat).
The component is the same live content as the one in the workspace. Editing it anywhere updates everywhere.
This is **powerful and tricky**:
- Powerful: a project status list lives in one place but appears in everyone's relevant chat and inbox, always current.
- Tricky: the same component can end up visible in many places to many people, with permissions defined per-host rather than per-component.
## Governance challenges
- **Permissions spread by embedding** — a component starts in your private workspace; you embed it in a chat with three colleagues; it's now visible to those three. No re-permissioning happened explicitly.
- **Surface inconsistency** — the same component looks different in Teams chat vs Outlook email vs Word document.
- **External access** propagates through chats — if you have a Teams shared channel with a partner, components in that channel are visible to the partner.
- **Audit complexity** — tracking component access across multiple hosts requires looking at all those hosts.
## Configuration controls
Tenant admins control Loop via the **Microsoft 365 admin center** and via Microsoft Graph:
- **Enable / disable Loop** tenant-wide.
- **Enable / disable Loop workspaces** specifically (separate from components).
- **Sensitivity label** support — apply labels to Loop content for inheritance.
- **Retention policies** apply via the underlying SharePoint storage.
- **External sharing** of workspaces follows the SharePoint settings.
Loop **components in Teams chat** are governed by Teams' external-sharing policies; **components in Outlook** by Exchange's policies.
## Practical guidance
For tenants enabling Loop:
- **Decide on workspace external-sharing posture** explicitly. Default to internal-only unless you have specific external-collaboration needs.
- **Communicate the embedding model** to users — components travel, and users need to understand the implications.
- **Apply sensitivity labels** to Loop workspaces and pages for sensitive content.
- **Audit periodically** — workspaces accumulate orphaned content over time.
- **Set retention** so workspace content has a managed lifecycle.
## Where Loop is heading
Microsoft continues to invest in Loop. The component model is increasingly the substrate for **Copilot Pages** (Copilot output → editable Loop page) and for collaborative work generally. As Loop matures, the governance surface around it will continue to evolve.
For tenants new to Loop, start with internal-only workspaces, get comfortable with the model, then consider external scenarios deliberately. Don't enable broad external Loop access on day one.
---
# Microsoft Mesh and immersive spaces in Teams
URL: https://www.solvingmicrosoft365.com/guides/microsoft-mesh-and-immersive-spaces
Category: Viva & Apps
Published: 2026-05-01
> Mesh brings 3D and avatar-based experiences to Microsoft Teams. Here's what it does and where it's used.
**Microsoft Mesh** is the platform for 3D / avatar-based collaboration experiences across Microsoft 365 — most visibly as **immersive spaces** in Microsoft Teams meetings. It's Microsoft's bet that a subset of meetings — especially large internal events, training, and team gatherings — benefit from something between a video grid and physical presence.
Mesh is a meeting experience inside [Teams](/guides/what-is-microsoft-teams), licensed through [Teams Premium](/guides/teams-premium-features-deep-dive) and E5; compare with [Whiteboard for hybrid workshops](/guides/microsoft-whiteboard-hybrid-workshops) and [town halls](/guides/teams-town-hall-vs-live-events-vs-stream) for the events it is sometimes proposed for.
## What immersive spaces in Teams provide
In a Teams meeting, participants can choose to enter the **immersive space**:
- Each participant has an **avatar** representing them.
- The space itself is a **3D environment** — a virtual conference room, an auditorium, a beach, a board room.
- Avatars can **move around the space**, group up in smaller huddles, signal interest via emotes.
- **Spatial audio** — voices come from the direction of speakers within the space.
- **Shared content** (slides, video, web pages) appears on virtual screens in the space.
- **Templates** and **custom environments** branded for your organisation.
It works on Teams Desktop (Windows, Mac), the Quest VR headset (where it's fully immersive), and as a hybrid experience for mixed audiences.
## Where Mesh is useful
- **Large team gatherings** — quarterly meetings, all-hands where the video-grid experience feels impersonal.
- **Training and workshops** — small-group breakouts within a larger space.
- **Onboarding** — new-hire welcomes that feel less transactional.
- **Customer engagement** — branded immersive product launches and customer events.
- **Cultural events** — happy hours, celebrations, social activities for remote teams.
## Where Mesh isn't useful
- **Daily stand-ups** — the format adds friction without benefit.
- **One-to-one meetings** — overkill.
- **Quick check-ins** — too much setup time.
- **High-bandwidth-constrained environments** — Mesh is bandwidth-hungry.
The honest answer is that Mesh works well in specific scenarios and poorly in others. It's not "the future of all meetings" — it's a tool for a particular kind of meeting.
## What's behind the scenes
Microsoft Mesh is built on:
- **Avatars in Teams** — the personalised 3D avatars representing each participant.
- **Spatial audio engine** — voices positioned in 3D.
- **Custom environments** — built with the Mesh Toolkit in Unity.
- **Microsoft 365 identity and Conditional Access** — the same identity and governance as regular Teams meetings.
For organisations wanting custom branded spaces, the Mesh Toolkit in Unity lets you create them. For everyone else, Microsoft's library of pre-built spaces is the starting point.
## Licensing
Immersive spaces in Teams meetings are available with **Teams Premium** for richer features; basic avatars in Teams are included with most Microsoft 365 plans. Custom Mesh experiences require Mesh-specific licensing for the authoring tools.
## Where this is going
Mesh has been a slow-burn product — interesting in theory, more niche in practice than Microsoft initially marketed. Adoption has clustered around organisations with specific use cases (training, customer events, distributed-first companies) rather than becoming universal.
The investment continues — better avatars, better integration with Copilot for in-meeting AI assistance, more environment templates. For most Microsoft 365 customers in 2026, it's still a "try with one event" rather than a default capability — but it's becoming more credible year by year.
---
# Microsoft Places — workplace planning
URL: https://www.solvingmicrosoft365.com/guides/microsoft-places-workplace-planning
Category: Viva & Apps
Published: 2026-05-01
> Microsoft Places brings hybrid-work coordination to Microsoft 365 — desk booking, in-office days, and team scheduling.
**Microsoft Places** is the workplace-planning product in Microsoft 365 for **hybrid-work coordination**: helping employees plan their in-office days, book desks and rooms, see when colleagues will be on-site, and helping leaders understand space utilisation. It plugs directly into the Microsoft 365 surfaces people already use — Outlook, Teams, Outlook Calendar.
Places builds on [resource mailboxes](/guides/exchange-online-resource-mailboxes), [Teams Rooms](/guides/microsoft-teams-rooms), and [Outlook](/guides/outlook-new-vs-classic-on-windows) calendars; it is part of the workplace story alongside [Viva Insights](/guides/microsoft-viva-insights) and [Teams meetings best practices](/guides/microsoft-teams-meetings-best-practices).
## What Places provides
For employees:
- **Set your work location** for each day (in office, remote, on holiday) directly in Outlook calendar.
- **See colleagues' in-office days** so you can plan to be there when relevant collaborators are.
- **Book a desk** in the office for specific days.
- **Book a meeting room** with a richer experience than Outlook's room finder — see capacity, equipment, location.
- **Find the right space** — book a focus room, a collaboration space, a phone booth based on what you need.
- **Outlook calendar integration** — work-location information surfaces in colleagues' availability.
For managers and team leads:
- See **team utilisation** — when team members are in office.
- **Recommend** in-office days when most of the team will be present.
For facility managers and leaders:
- **Space utilisation analytics** — which rooms / floors are over- and under-used.
- **Building occupancy trends** over time.
- **Wayfinding** integration with sensors and IoT in the building.
## How it integrates
Places sits on top of Microsoft 365 infrastructure:
- **Exchange Online resource mailboxes** continue to back rooms and equipment.
- **Outlook calendar** is the source of work-location data.
- **Teams** is the place collaboration around in-office days happens.
- **Viva Insights** surfaces hybrid-work analytics.
- **Building IoT integration** — for buildings instrumented with people-counting sensors, occupancy maps update in real time.
## Where it's useful
- **Hybrid-work organisations** trying to make in-office days feel intentional, not random.
- **Larger offices** where finding the right space and the right people takes coordination.
- **Distributed teams** that gather in offices occasionally — Places helps everyone coordinate.
- **Facilities teams** wanting data on actual space usage.
## Where it's less useful
- **Fully remote organisations** — no office means no desk booking; Places is mostly irrelevant.
- **Small offices** where everyone knows where everyone is.
- **Organisations with rigid in-office mandates** — Places doesn't help if all days are mandatory; it shines when there's choice and coordination matters.
## Licensing
Microsoft Places **basic capabilities** — setting work location, seeing colleague availability, basic room booking — are included with most Microsoft 365 plans.
**Microsoft Places premium** features — analytics, advanced room finding, wayfinding integration, custom workplaces — require a separate per-user licence or are bundled with **Microsoft 365 Copilot** in some plan combinations.
## Realistic adoption
Like other hybrid-work tools, Places' value depends on the **organisational practice** more than the tooling. The product can suggest in-office days; the team has to actually decide together that Tuesday is the day, and then enforce that lightly. Without that cultural piece, even the best tooling just shows accurate but unused data.
For Microsoft 365 customers in hybrid mode, Places is worth piloting once the basic Teams / Outlook hybrid practices are established — not as the foundation, but as the optimisation layer on top.
---
# Microsoft Planner, Tasks, and Project
URL: https://www.solvingmicrosoft365.com/guides/microsoft-planner-tasks-and-project
Category: Viva & Apps
Published: 2026-05-01
> The three task and project tools in Microsoft 365 — when to use each.
Microsoft 365 has three task-management products, all of which Microsoft has shuffled together and renamed several times. As of 2026 the picture is clearer than it was: **Microsoft Planner** is the unified task app, **Microsoft To Do** lives inside it for personal lists, and **Microsoft Project** sits on top for serious project management.
The premium tier and its licensing are in [Planner premium vs Project for the web](/guides/microsoft-planner-premium-vs-project-for-the-web). Adjacent light-weight apps each have a guide: [Microsoft Lists templates](/guides/microsoft-lists-templates), [Forms surveys and quizzes](/guides/microsoft-forms-surveys-and-quizzes) with [branching and quiz mode](/guides/microsoft-forms-branching-and-quiz-mode), [Bookings](/guides/microsoft-bookings-explained) and [Bookings advanced configuration](/guides/microsoft-bookings-advanced), [Places](/guides/microsoft-places-workplace-planning), [Stream on SharePoint](/guides/microsoft-stream-on-sharepoint), [Mesh and immersive spaces](/guides/microsoft-mesh-and-immersive-spaces), and [Syntex](/guides/microsoft-syntex-deep-dive).
## The unified Planner app
The **new Microsoft Planner** (the Teams app and standalone web app at `planner.cloud.microsoft`) is the single surface for:
- **My Tasks** — your personal task list (formerly Microsoft To Do).
- **Plans** — shared task boards for a team (formerly classic Planner).
- **Premium plans** — project-style plans with timelines, dependencies, and resource management (formerly Project for the Web).
- **Outlook tasks** and **Loop tasks** — surfaced in the same view.
For end users this consolidation is overdue. Tasks, regardless of where they came from, appear in one place.
## Planner basic (the free tier)
Included with all Microsoft 365 plans:
- **Boards** — Kanban-style with buckets and labels.
- **Charts and Schedule** views for the same plan.
- **Assignments** — a task can have multiple assignees, due dates, attachments, checklists, comments.
- **Teams integration** — every Teams team can add a Planner tab.
- **My Tasks** — personal list (formerly To Do).
This level works well for **team-level task management** — what's traditionally called "lightweight project management" or "team kanban."
## Planner premium (paid)
For more serious project management, **Planner premium** (formerly Project for the Web) adds:
- **Gantt and timeline** views with dependencies.
- **Resource management** — capacity, allocation, levelling.
- **Roadmaps** across multiple plans.
- **Custom fields and conditional formatting**.
- **Power BI templates** for project reporting.
- **Critical path** analysis.
- Backed by **Dataverse** rather than the Planner basic data store, with all the governance and extension benefits.
This is the tier for actual project managers running real projects.
## Microsoft Project Online and Project Server
For very large enterprise project portfolios — multi-project resource pools, EVM (earned-value management), complex governance — **Microsoft Project Online** (a separate SaaS product) and **Project Server** (on-prem) still exist. Microsoft's direction is to migrate Project Online customers to Planner premium over time, but the migration is gradual.
## Microsoft Project for the Desktop
The classic desktop **Microsoft Project** app (`.mpp` files) is also still around, primarily for stand-alone schedulers who need rich timeline editing. It can publish to Project Online but increasingly doesn't fit modern team-collaboration workflows.
## When to use which
| Need | Tool |
| --- | --- |
| Personal task list | Planner — My Tasks |
| Team kanban for a project | Planner basic |
| Real project with timelines, dependencies, resources | Planner premium |
| Enterprise portfolio with EVM, resource pools | Project Online / Project Server |
| Quick task in a Teams chat | Loop task block (syncs to Planner) |
| Task from an email | Outlook Tasks (syncs to Planner) |
## Licensing
- **Planner basic** — included with all Microsoft 365 plans.
- **Planner premium** — separate per-user licence.
- **Microsoft Project Online** — per-user Plan 1, Plan 3, Plan 5 licences (different feature sets).
For most teams using Microsoft 365, **Planner basic is enough**. Reach for premium when you genuinely have dependencies and resource management to manage.
---
# Microsoft Priva privacy management
URL: https://www.solvingmicrosoft365.com/guides/microsoft-priva-privacy-management
Category: Microsoft Purview (Compliance)
Published: 2026-05-01
> Microsoft Priva is the data-privacy management product in Microsoft 365 — risk management and subject rights requests.
**Microsoft Priva** is the data privacy management product in Microsoft 365, addressing regulatory privacy concerns like GDPR, CCPA, and similar regimes. It sits alongside Purview but focuses on privacy specifically: where personal data is, who has access, and how to handle subject rights requests.
Priva is a privacy-focused sibling of the [Purview](/guides/what-is-microsoft-purview) solutions, relying on [sensitive information types from DLP](/guides/purview-data-loss-prevention-deep-dive) and [retention](/guides/purview-retention-policies-explained); subject rights requests overlap with [eDiscovery](/guides/purview-ediscovery-standard-vs-premium), and residency questions with [tenant isolation and data residency](/guides/microsoft-365-tenant-isolation-and-data-residency).
## What Priva does
Priva has two main capabilities:
### Privacy Risk Management
Continuously evaluates personal data in your Microsoft 365 environment and flags risks:
- **Data overexposure** — personal data shared with too many people internally.
- **Data transfers** — personal data crossing geographic or organisational boundaries inappropriately.
- **Data minimisation** — personal data being collected or retained without clear purpose.
- **Sensitive types in unusual locations** — credit cards in OneDrives, government IDs in chat.
Risk findings drive **policies** — automated controls that warn users, restrict actions, or alert admins when risks are detected. For example: "Block sharing of a document containing more than 100 customer records to anyone outside the organisation."
### Subject Rights Requests
When a customer or employee submits a **subject rights request** under GDPR / CCPA / equivalents (right to access, right to deletion, right to correction), Priva orchestrates the response:
- **Define the request** — what kind, what subject, what scope.
- **Identify data** — Priva searches across Microsoft 365 for content related to the subject.
- **Review** — reviewer assesses what to include, what to redact.
- **Generate response** — package the data for the requester.
- **Audit trail** — every step is logged for compliance evidence.
Built on top of eDiscovery infrastructure, with privacy-specific workflows.
## Why this matters
GDPR went live in 2018 and subject rights requests have grown steadily. CCPA, China PIPL, India DPDP, and many others have followed. For organisations subject to these regimes, a structured way to respond is necessary — and "we'll search email manually when someone asks" doesn't scale.
Priva offers the structured workflow that legal teams can run repeatedly.
## How it integrates
- **Microsoft Purview** handles general compliance (retention, eDiscovery, DLP); Priva specifically addresses privacy.
- **Defender** signals contribute to risk detection in Priva.
- **Sensitivity labels** in Purview can drive Priva risk assessments.
- **Subject Rights Requests** in Priva are technically eDiscovery cases with a privacy-specific UI on top.
## Licensing
Priva is licensed as a **per-user** add-on, with separate skus for **Privacy Risk Management** and **Subject Rights Requests**. Included with **Microsoft Priva** standalone licences or bundled in **Microsoft 365 E5 Compliance** for some scenarios.
For organisations handling significant personal data — anyone with European customers, anyone in healthcare, anyone in financial services — Priva is increasingly part of the compliance baseline.
## Practical rollout
1. **Inventory personal data** across Microsoft 365 — use Priva's automatic discovery.
2. **Set up the SRR workflow** with named reviewers (legal, privacy officer, HR).
3. **Define risk policies** for high-priority data classes (customer PII, employee records, payment data).
4. **Train the team** on running SRRs through Priva rather than ad-hoc.
5. **Audit and report** quarterly on SRRs handled, risks closed, policy effectiveness.
Priva doesn't make privacy management easy — privacy is inherently a structured legal / process exercise — but it makes the Microsoft 365 side of it dramatically more manageable than doing it by hand.
## Decision matrix — do you need Priva now?
| Situation | Verdict |
|---|---|
| EU customer base of any size, no SRR process yet | Priva SRR is the fastest path off spreadsheets and manual mailbox searches. |
| Existing SRR process running through outside counsel | Priva for the internal collection, hand the review off to counsel — cheaper per request. |
| Very small tenant, one SRR every couple of years | Skip Priva; run the request as a Purview eDiscovery Standard case with a privacy checklist. |
| Regulated (health, finance) with a privacy officer | Both Priva SRR and Priva Risk Management. The risk-management side is what a privacy officer will actually use daily. |
| B2C org with heavy consent management | Priva plus a dedicated consent platform (OneTrust, TrustArc). Priva does not manage consent itself. |
## Wrong-fit warnings
- **Priva is not a consent management platform.** It will not host your cookie banner, capture opt-ins, or maintain a preference centre.
- **Priva SRR reaches Microsoft 365 content, not everything.** Data in Salesforce, HubSpot, on-prem file shares, or a customer database is out of scope; SRR fulfilment for those needs its own path.
- **Priva Risk policies are noisy at first.** Expect a quiet-mode rollout period where you tune signal-to-noise before enforcement. Rolling out with block actions on day one produces a slack-ticket avalanche.
- **Priva SRR is not eDiscovery for legal cases.** Do not repurpose it for litigation; the audit trail and export shape are tuned for privacy responses, not for court production.
- **A subject rights *request* is not always a *deletion* request.** Priva distinguishes access, portability, correction and deletion — make sure your reviewers understand which is which; a wrong response is a regulator-worthy incident.
## Worked example — first-year Priva rollout at a mid-market SaaS
*Scenario:* 1,200 employees, EU + US customers, GDPR + CCPA in scope, no formal SRR tooling.
- **Month 1:** Turn on Priva Privacy Risk Management in report-only. Baseline emerges: personal-data spread by department, the top overexposed sites, the "shadow HR" folders in team OneDrives.
- **Month 2:** Publish the first three privacy policies in warn-only: overexposure of employee records, external sharing of files with named customer PII types, transfers of personal data to unmanaged locations.
- **Month 3:** Stand up SRR reviewers — one privacy officer, one legal, one HR. Rehearse a synthetic SRR end to end. Time the response and record it.
- **Month 4:** Publish the SRR intake form on the public site or in-app. All new requests route through Priva SRR from day one.
- **Month 6:** Flip the top privacy policies from warn to enforce. Publish a quarterly privacy metrics report — requests handled, median time, closed risks — as the board-level artefact.
## FAQ for MSPs
- **Can we run Priva SRR on behalf of a customer?** Yes with GDAP and role assignments in the customer tenant. Restrict yourselves to case setup and workflow; the customer's privacy officer should be the reviewer who sees the personal data.
- **Multi-tenant Priva view?** No unified view across tenants. Report per-tenant and roll up in your own PSA/BI stack.
- **How do we price Priva engagements?** Priva add-ons are per-user, so incremental to the customer's E3/E5 base. Bundle "SRR fulfilment SLA" as an outcome, not "hours in Priva."
- **What is the fastest first-value win for a customer?** Turn on the personal-data overexposure risk in report-only for a week and hand them the top-20 sites report. Concrete, cheap, and it earns the follow-on rollout conversation.
---
# Microsoft Search administration
URL: https://www.solvingmicrosoft365.com/guides/microsoft-search-administration
Category: Microsoft 365 essentials
Published: 2026-05-01
> How to configure Microsoft Search — bookmarks, answers, verticals, acronyms, and tenant-wide search ranking.
**Microsoft Search** is the unified search across Microsoft 365 — the search box at the top of Outlook, Teams, SharePoint, Office, and Bing-at-work, all backed by a single per-tenant index. Beyond just working out of the box, it has a rich admin layer for shaping results. Used well, it dramatically improves how users find content.
## The admin surface
Admin configuration lives in the **Microsoft 365 admin center → Settings → Search & intelligence** (or `admin.microsoft.com/search`). Key configuration areas:
### Bookmarks
Curated **promoted results** for known queries. When a user searches "VPN," the bookmark for the VPN setup page appears at the top of results. Cover common help-desk questions:
- HR pages (benefits, payroll, time off).
- IT pages (VPN, password reset, software requests).
- Internal tools (expense system, project tracker).
- Company info (mission, executives, contact info).
Each bookmark has keywords, a title, description, URL, optional reserved/promoted status, and scoping by group.
### Answers
For factual questions, **answers** provide direct content (a block of text or a card) inline in search results. "Office address" returns the answer directly, not just a link. Used for FAQ-style content.
### Acronyms
For organisation-specific acronyms — `ARR`, `MAU`, `OKR`, internal project codenames — define what they mean so users searching for them get a definitional answer. Powerful for onboarding.
### Q&A
Curated questions and answers, more verbose than acronyms, surfaced when users type natural-language questions.
### Verticals
Search results categories — Files, People, Sites, Conversations, plus custom verticals you define for **third-party content** indexed via Graph connectors (ServiceNow tickets, GitHub repos, etc.).
### Locations
Office addresses with map coordinates — surfaced in people cards and Room Finder.
### Configurations
Tenant-wide ranking signals, custom Bing search experience, branding for the Microsoft Search homepage.
## Microsoft Graph connectors
To extend Search beyond Microsoft 365's native content, **Graph connectors** index third-party data sources — Jira tickets, ServiceNow records, GitHub repos, file shares, Box, custom REST APIs. Each connector defines schema mapping and permissions trimming so users see only what they should.
Connectors are essential for **Microsoft 365 Copilot** customers — Copilot grounds on what's in the index, so connecting external knowledge bases dramatically improves Copilot answers.
## Search analytics
The admin surface reports:
- **Top queries** users are searching for.
- **Zero-click queries** — searches that returned no clicks (your candidates for new bookmarks).
- **Trending content** users are clicking.
- **Click-through rates** on bookmarks and answers.
Use this for an iterative bookmark / answer programme — quarterly review of top zero-click queries, add bookmarks, measure impact.
## Operational practice
A mature Search administration practice:
- **Named owner** in IT for Search admin.
- **Monthly bookmark addition** based on top zero-click queries.
- **Quarterly review** of existing bookmarks for staleness.
- **Cross-team contributions** — HR adds HR bookmarks, IT adds IT bookmarks.
- **Acronym list** maintained alongside the internal glossary.
For Microsoft 365 tenants of any meaningful size, Search administration is one of those quietly high-leverage roles — the search box gets used hundreds of times a day; small improvements compound.
---
# Microsoft Security Copilot
URL: https://www.solvingmicrosoft365.com/guides/microsoft-security-copilot
Category: Microsoft 365 Copilot
Published: 2026-05-01
> Microsoft's AI assistant for security analysts — what it does, where it's embedded, and how it's licensed.
**Microsoft Security Copilot** is the AI assistant for security analysts, embedded across the Defender XDR portal, Microsoft Sentinel, Microsoft Intune, Microsoft Entra, Microsoft Purview, and Microsoft Defender for Cloud. It uses generative AI to accelerate the common SOC tasks: triaging incidents, understanding alerts, writing KQL queries, drafting incident reports.
## What Security Copilot does
In Defender XDR / Sentinel:
- **Summarise an incident** in plain English with affected users, timeline, suspected attacker behaviour.
- **Explain an alert** — what triggered it, what it likely means, recommended response.
- **Generate KQL queries** from a natural-language description.
- **Suggest hunting queries** based on the current incident context.
- **Reverse-engineer a script** — paste in suspicious PowerShell, get a plain-English explanation.
- **Draft incident reports** suitable for handoff to management or other teams.
In Entra:
- Summarise sign-in risk events.
- Explain Conditional Access policy outcomes.
In Purview:
- Summarise data security investigations.
- Explain DLP detections.
In Intune:
- Explain device compliance failures.
- Suggest configuration changes.
## How it works
Security Copilot is a thin orchestrator on top of:
- **Generative AI** (Microsoft and OpenAI models hosted in Azure).
- **Plugins** that fetch data from Microsoft and third-party security products. The plugin model is extensible — Microsoft ships built-in plugins, and partners build custom ones for their security tools.
- **Customer prompts and responses** are processed under Microsoft's commercial AI commitments — no training on customer data, no cross-tenant data.
A typical query — "what's going on with incident 12345?" — fans out to relevant plugins, gathers data, and synthesises a response with citations to the underlying sources.
## Licensing
Security Copilot is licensed by **Security Compute Units (SCUs)** — a capacity-based unit billed per hour. A small SOC team might run 4–8 SCUs continuously; larger deployments scale up. SCUs can be provisioned and decommissioned through the **Security Copilot portal**.
This is distinct from **Microsoft 365 Copilot** (per-user productivity AI) — different licensing model, different scope.
## Where it fits in the SOC
Security Copilot is most valuable for:
- **Tier-1 triage** — speeding up first responses to incidents.
- **Junior analyst enablement** — analysts who don't yet know KQL well can ask in English.
- **Incident reporting** — turning analyst notes into structured reports.
- **Cross-tool investigations** — getting a coherent view across Defender, Sentinel, Entra, Purview.
It's not a replacement for skilled analysts — the AI produces drafts that humans validate. Treat it as a copilot, not an autopilot.
## Realistic expectations
- **High-quality answers** for common scenarios with well-formed prompts.
- **Imperfect responses** when the underlying data is sparse or ambiguous.
- **No magic** — it can't see signals the connected sources don't expose.
For SOCs already running Defender XDR and Sentinel, Security Copilot is one of the highest-leverage AI investments available — provided you have analysts who'll use it well.
---
# Microsoft Sentinel cost optimisation
URL: https://www.solvingmicrosoft365.com/guides/microsoft-sentinel-cost-optimization
Category: Microsoft Defender (Security)
Published: 2026-05-01
> How to control Microsoft Sentinel costs — ingestion tuning, commitment tiers, retention, and data tiering.
Microsoft Sentinel can be expensive. Bills are driven by **ingested data volume**, **storage**, and **retention period**. For organisations at scale, even modest cost optimisation produces meaningful savings without compromising security visibility.
Cost follows the data sources chosen in [Sentinel onboarding](/guides/microsoft-sentinel-onboarding) and [Sentinel for Microsoft 365](/guides/microsoft-sentinel-for-microsoft-365); [analytic rules](/guides/sentinel-analytic-rules) determine what you need to keep hot, and [Defender XDR advanced hunting](/guides/defender-xdr-advanced-hunting) covers what you can query without ingesting into Sentinel at all.
## How Sentinel bills
Two main cost components:
### Ingestion
Each GB of data ingested into the Log Analytics workspace backing Sentinel costs money. Pricing tiers:
- **Pay-as-you-go** — per-GB. Highest unit cost.
- **Commitment tiers** — pre-commit to N GB/day for discount. 100, 200, 300, 400, 500, 1000, 2000, 5000 GB/day tiers with progressively better unit pricing.
For tenants ingesting > 100 GB/day, commitment tiers save significantly. Choose the tier slightly below your sustained ingestion to maximise value while leaving headroom.
### Retention
- **First 90 days** included in ingestion cost.
- **Beyond 90 days** charges separately per GB-month.
- **Up to 730 days** (2 years) of retention supported.
For organisations needing very long retention, **archive tier** (much cheaper, slower to query) extends to 7+ years.
## Free Microsoft 365 sources
The biggest cost optimisation: **Microsoft sources are mostly free**:
- **Microsoft 365 Defender** — free.
- **Microsoft 365 audit logs** — free.
- **Microsoft Entra ID** sign-in and audit logs — free up to a daily limit.
- **Microsoft Defender for Cloud** alerts — free.
The pricing model heavily favours Microsoft-source ingestion. For Microsoft 365-heavy estates, much of the security signal is free.
## Cost-saving tactics
### Filter before ingestion
For verbose sources (firewalls, network logs), filter at the source or in the ingestion pipeline:
- **Drop low-value records** before they're ingested.
- **Sample high-volume noisy data** (only ingest 10% of debug-level events).
- **Aggregate** repeated events into summary records.
The cheapest data is data you don't ingest.
### Use data-collection rules (DCRs)
**Data Collection Rules** in Log Analytics let you filter and transform data **before storage**:
- KQL transformations applied at ingestion time.
- Drop fields you don't need.
- Split tables by content.
- Send subsets to **basic-logs** tables for cheaper storage.
### Basic vs analytics logs
Sentinel tables can be **analytics** (full features, higher cost) or **basic** (lower cost, limited queryability):
- **Analytics** — full KQL, analytic rules, fast query.
- **Basic** — restricted queries, ideal for high-volume low-investigation-frequency data.
Move high-volume / low-value data to basic; keep critical detection sources on analytics.
### Auxiliary logs (newer tier)
Microsoft is rolling out **auxiliary logs** — even cheaper than basic, optimised for archival / occasional-query scenarios.
### Retention tuning
- **Default 90 days** included.
- **Extend to longer** only for tables that need it.
- **Move older data to archive tier** for long retention at lower cost.
- **Set up data-collection rules** to route data to appropriate tier.
### Workspace consolidation
For organisations with multiple Sentinel workspaces (per region or per business unit), consolidating reduces per-workspace overhead and enables tier-based pricing.
But trade off: distributed workspaces may better match data-residency requirements.
## Monitoring and alerting
Set up alerts on ingestion volume:
- **Daily ingestion threshold** — alert if it spikes 20% above baseline.
- **New tables** with significant volume — investigate source.
- **Specific high-volume connectors** — verify they're producing useful signal.
The **Usage and estimated costs** workbook shows real-time cost analysis.
## Common surprises
- **A new firewall** connected to Sentinel doubles ingestion.
- **Verbose debug logging** turned on by an admin spikes the bill.
- **A misconfigured connector** ingests massively without value.
- **Sudden growth** in a specific table because of a policy change.
Catch these via monitoring; correct before they blow up the budget.
## Cost vs coverage trade-offs
Some signals are essential at any cost; some are optional luxuries. Frame the cost-coverage decision:
- **Essential**: Microsoft 365 Defender, Entra ID, Office 365 audit — fundamental security visibility.
- **Important**: firewall logs from internet edge, key network gear.
- **Useful**: detailed application logs, deep telemetry.
- **Optional**: verbose debug logs, very granular network telemetry.
Don't ingest "optional" sources just because you can. Justify each source.
## Operational discipline
- **Quarterly cost review** — track trend, identify growth.
- **Per-source cost analysis** — which sources are worth their cost.
- **Annual commitment-tier review** — adjust as ingestion changes.
- **Retention review** — extending retention is permanent commitment; verify justified.
For organisations running Sentinel seriously, cost optimisation is a real ongoing discipline. The savings are substantial when done well — and the security posture isn't compromised when optimisation is thoughtful.
---
# Microsoft Sentinel for Microsoft 365
URL: https://www.solvingmicrosoft365.com/guides/microsoft-sentinel-for-microsoft-365
Category: Microsoft Defender (Security)
Published: 2026-05-01
> How Microsoft Sentinel ingests Microsoft 365 signals and extends Defender XDR into a full SIEM.
**Microsoft Sentinel** is Microsoft's cloud-native **SIEM / SOAR** platform. For Microsoft 365 customers, it extends the **Defender XDR** experience with longer log retention, third-party log ingestion, custom hunting at scale, and full SOAR automation. As of 2025–2026, Sentinel lives inside the **Defender XDR portal** as a unified surface alongside Microsoft's first-party security signals.
## What Sentinel adds beyond Defender XDR
Defender XDR is excellent for **first-party Microsoft signals** — Defender for Office 365, Endpoint, Identity, Cloud Apps. Sentinel extends this in several directions:
- **Long-term retention** — Defender XDR retains data for ~30–180 days depending on plan; Sentinel can retain years.
- **Third-party log sources** — firewalls (Palo Alto, Cisco, Check Point), network devices, custom apps via Azure Functions or REST API, AWS / GCP cloud logs.
- **Custom detection rules** in KQL beyond what Defender ships.
- **Automation playbooks** built as Azure Logic Apps — automate responses, ticketing, notification.
- **Watchlists** for context (VIP users, asset criticality).
- **Threat intelligence** ingestion from TAXII feeds, structured threat intel from vendors.
- **User and Entity Behavior Analytics (UEBA)** — ML-driven baselines per user / entity, anomaly detection.
## How M365 signals flow
For Microsoft 365 customers, the integration is largely **free** of ingestion cost for first-party Microsoft sources:
- **Microsoft 365** audit logs (Exchange, SharePoint, Teams).
- **Entra ID** sign-in logs, audit logs, risk events.
- **Defender XDR** alerts and incidents.
- **Defender for Cloud** alerts.
Sentinel **billable** ingestion typically covers third-party sources and custom data. The pricing pivoted in 2024 to better align Sentinel with Microsoft 365 customers; ask your Microsoft account team about current cost models.
## The unified portal
Inside the Defender XDR portal, Sentinel and Defender XDR share:
- **Incidents** — unified view, with Sentinel incidents and Defender XDR incidents in one queue.
- **Advanced hunting** — KQL queries run across both Defender XDR tables and Sentinel tables.
- **Investigation graphs** — entity-centric views of attack chains.
- **Hunting books and notebooks** — reusable investigation patterns.
For SOC analysts, this means one portal, one query language, one incident workflow.
## When you need Sentinel
Sentinel is the right answer when:
- You need **long-term log retention** for compliance or investigation.
- You have **third-party security sources** (firewalls, network gear, custom apps) that need correlation with Microsoft signals.
- You want **deep custom detections** beyond Defender's first-party rules.
- You're building a **SOC with custom workflows** and want SOAR automation.
- You're doing **threat hunting at scale**.
Sentinel adds operational complexity — KQL skills, content library curation, playbook engineering. For smaller organisations, Defender XDR alone may be enough.
## Getting started
A typical first-month deployment:
1. **Connect Microsoft 365 sources** — Defender XDR, Entra ID, Office 365.
2. **Enable analytic rules** from the Sentinel content hub — Microsoft ships hundreds.
3. **Turn on UEBA** for behavioural baselines.
4. **Add a Logic App playbook** for one or two common response actions (notify Teams channel, create ServiceNow ticket).
5. **Establish KQL skills** in the SOC team — invest in training.
Mature deployments add custom rules, hunting books, watchlists, and threat-intel integrations iteratively.
## Frequently asked questions
**Is Microsoft Sentinel free for Microsoft 365 data?**
Ingestion of some Microsoft 365 data — Office 365 audit (Exchange, SharePoint, Teams) via the Microsoft 365 connector, and Defender XDR alerts — is free; Entra sign-in and audit logs, Defender raw event tables, and everything else is billed per GB with a free daily allowance for E5 customers (5 MB per user per day for certain sources).
**Do I need Sentinel if I have Defender XDR?**
Defender XDR correlates Microsoft signals and is enough for many organisations. Sentinel adds long-term retention, non-Microsoft data sources (firewalls, cloud providers, SaaS), custom analytics, SOAR playbooks, and a SIEM the audit and compliance team can point to. Sentinel is now surfaced inside the Defender portal.
**What is the first thing to connect to Sentinel?**
The Defender XDR connector (incidents and, if you want them, raw tables), the Entra ID connector (sign-in and audit logs), and the Microsoft 365 connector — then enable the analytics rules and workbooks that come with them. Firewall and proxy logs come next for shadow IT and exfiltration coverage.
---
# Microsoft Sentinel onboarding
URL: https://www.solvingmicrosoft365.com/guides/microsoft-sentinel-onboarding
Category: Microsoft Defender (Security)
Published: 2026-05-01
> How to onboard Microsoft Sentinel — workspace setup, data connectors, and starting analytic rules.
**Microsoft Sentinel** is Microsoft's cloud-native SIEM, and for organisations using Microsoft 365 it's increasingly the right SOC platform. Standing up Sentinel for the first time has a learning curve, but the foundational onboarding follows a predictable sequence.
Start with [Microsoft Sentinel for Microsoft 365](/guides/microsoft-sentinel-for-microsoft-365) for what to connect, then [analytic rules](/guides/sentinel-analytic-rules) and the [KQL primer](/guides/kql-primer-for-defender-xdr); [Sentinel cost optimisation](/guides/microsoft-sentinel-cost-optimization) should be read before the first month's bill, and [monitoring and alerts](/guides/microsoft-365-monitoring-and-alerts) lists what to alert on.
## Prerequisites
Before starting:
- **Azure subscription** — Sentinel runs as an Azure resource backed by Log Analytics workspace.
- **Log Analytics workspace** — Sentinel sits on top of one.
- **Tenant admin or Global Reader access** for connecting Microsoft 365 sources.
- **Decision on data residency** — workspace region selection.
- **Initial budget** — Sentinel bills by ingested data volume.
## Workspace setup
1. **Create a Log Analytics workspace** in Azure, in your chosen region.
2. **Enable Microsoft Sentinel** on that workspace.
3. **Configure access** — analyst roles for the SOC team, admin roles for setup.
4. **Set up data residency** appropriate to your regulatory requirements.
## Connecting data sources
Sentinel's value comes from the data it ingests. Connect sources in priority order:
### Microsoft 365 sources (typically free)
- **Microsoft 365 Defender** — XDR alerts and raw events.
- **Microsoft 365 audit logs** — Office 365 activity.
- **Microsoft Entra ID** — sign-in logs, audit logs.
- **Microsoft Defender for Cloud** — Azure security signals.
Most Microsoft sources are **free to ingest**, making them the natural starting point.
### Third-party sources (billable)
- **Firewall logs** — Palo Alto, Cisco, Check Point, Fortinet via Syslog or specific connectors.
- **Cloud platforms** — AWS, GCP for cross-cloud security visibility.
- **Custom applications** — via Logic Apps, Function Apps, or the Sentinel REST API.
- **Threat intelligence** — TAXII feeds.
Connect what's high-value first; expand over time as budget allows.
## Initial analytic rules
Sentinel ships **hundreds of analytic rules** in the content hub. For initial deployment:
1. **Browse the content hub** for Microsoft 365 and Defender solutions.
2. **Install the relevant solutions** — they include rules, workbooks, playbooks.
3. **Enable selected rules** — start with high-fidelity, low-false-positive rules.
4. **Tune over weeks** — adjust thresholds, suppress known-good patterns.
5. **Add custom rules** as your SOC matures.
Don't try to enable everything on day one — you'll drown in alerts. Start narrow; expand as you tune.
## Workbooks and dashboards
Sentinel **workbooks** are interactive dashboards. The content hub provides pre-built workbooks for:
- **Microsoft 365 Defender** — incident overview, threat trends.
- **Entra ID** — sign-in patterns, anomalies.
- **Network traffic** — for connected firewalls.
- **Cloud security posture** — for Defender for Cloud.
Pin the relevant ones to the workspace home for daily visibility.
## Playbooks (SOAR)
Sentinel **playbooks** are Logic Apps that automate responses. Pre-built playbooks include:
- **Block sender** in Exchange Online for confirmed phishing.
- **Isolate device** via Defender for Endpoint.
- **Disable account** in Entra ID.
- **Notify team** via Teams.
- **Create ServiceNow incident** for case management.
Configure playbooks with care — automated response to false positives causes real damage.
## Cost management
Sentinel bills by **ingested GB per day**:
- Microsoft 365 sources are typically free (where applicable).
- Other sources are billable; commitment tiers reduce per-GB cost.
- **Retention** beyond 90 days incurs additional cost.
Monitor ingestion volume in the workspace's **Usage and estimated costs** dashboard. Surprise bills from sudden ingestion spikes are common; alerting on volume thresholds catches them.
## Unified Defender + Sentinel portal
Sentinel now integrates into the **Defender XDR portal** at `security.microsoft.com`. Analysts work in a unified surface — Defender's first-party signals plus Sentinel's broader telemetry — without switching consoles. Same KQL hunting; same incident model; same response actions.
For organisations already using Defender XDR, the integration makes Sentinel onboarding feel like extending what's already there rather than learning a separate tool.
## Operational considerations
- **Designate Sentinel ownership** — a named team or person.
- **Define analyst tier model** — who handles what severity.
- **Establish response time targets** — SLA for critical / high / medium / low.
- **Document the runbook** — what to do when each kind of alert fires.
- **Continuous improvement** — quarterly review of detections and tuning.
For Microsoft 365 customers building a serious SOC capability, Sentinel is increasingly the standard platform. The initial setup is moderate; the value compounds as more sources are connected and the team gains KQL fluency.
---
# Microsoft Stream on SharePoint
URL: https://www.solvingmicrosoft365.com/guides/microsoft-stream-on-sharepoint
Category: Viva & Apps
Published: 2026-05-01
> The current Stream stores videos in SharePoint and OneDrive — what changed from Stream Classic and how to use it.
**Microsoft Stream** has had two major incarnations. The current — and only supported — version is **Stream (on SharePoint)**, which stores videos as files in OneDrive and SharePoint. The older **Stream (Classic)**, with its own segregated video storage and separate admin model, was retired in 2024. Knowing which one you're dealing with prevents a lot of confusion.
Stream is where [meeting recordings](/guides/teams-meeting-recording-management) and [town hall](/guides/teams-town-hall-vs-live-events-vs-stream) recordings land, stored per [document libraries deep dive](/guides/sharepoint-document-libraries-deep-dive), embedded via [pages and web parts](/guides/sharepoint-page-design-and-web-parts), and retained under [Purview retention](/guides/purview-retention-policies-explained).
## Stream (on SharePoint) in practice
Every video stored in OneDrive or SharePoint can play in the modern Stream player without any special handling:
- **Upload** a `.mp4` or other supported format to OneDrive or a SharePoint library — that's it.
- **Permissions** match the underlying file — Stream doesn't have its own permission model.
- **Search** uses Microsoft Search, including auto-generated transcripts.
- **Sharing** uses the standard OneDrive/SharePoint share dialog.
- **Retention** and **sensitivity labels** apply through Purview as they do for any file.
The player adds:
- **Chapters** for navigation.
- **Auto-generated transcripts** in many languages.
- **Search within transcript** during playback.
- **Speed controls, captions, accessibility features**.
- **Comments and engagement signals**.
## Teams meeting recordings
When a Teams meeting is recorded, the recording is automatically saved to **Stream-on-SharePoint** — specifically, to the **organiser's OneDrive** (for non-channel meetings) or the **channel's SharePoint site** (for channel meetings). Permissions inherit from those locations.
For **channel meetings**, this means the recording is automatically accessible to channel members and follows the team's retention.
## Stream web app
The **Stream web app** at `microsoftstream.com` (redirecting to `stream.cloud.microsoft`) is a portal-style experience for browsing your video content across the tenant. It surfaces:
- Videos you've created or starred.
- Videos shared with you.
- Watchlist and trending content.
- Live events (where applicable).
It's not a separate storage system — everything you see there lives in someone's OneDrive or SharePoint.
## What Stream Classic did differently
For historical context: Stream Classic had its own backend storage, its own permission model (independent of SharePoint), its own retention, and its own admin portal. None of that exists in Stream (on SharePoint), which is structurally simpler.
Tenants with classic-era content needed to migrate it during 2023–2024. Microsoft published migration tools and timelines; orphaned legacy Stream URLs may still surface in old links but the content lives in SharePoint now.
## Live events
Microsoft has consolidated live broadcasting into **Town Halls** in Teams (covered in its own guide), succeeding both **Stream live events** and **Teams Live Events**.
For most organisations, Stream (on SharePoint) is "just videos in SharePoint with a better player" — no special configuration required.
## Storage and quota implications
Because video files are large and now count as ordinary SharePoint/OneDrive content rather than living in a segregated Stream Classic storage pool, a tenant with a lot of recorded meetings and training content can see its SharePoint storage pool and individual OneDrive quotas grow noticeably faster than expected once video became "just another file." This is worth factoring into the same capacity planning used for document libraries generally — a channel that records every weekly meeting and never cleans up old recordings will accumulate video storage against that channel's SharePoint site quota indefinitely unless a retention policy or manual cleanup schedule is applied specifically to meeting recordings.
## Frequently asked questions
**Can a video's auto-generated transcript be edited or corrected?** Yes — the transcript can be edited directly in the Stream player by anyone with edit rights on the underlying file, which is useful for correcting misheard technical terms or names before the video is widely shared, since the transcript is also what search and Copilot draw on for that content.
**Do old Stream Classic video links still work after the 2024 retirement?** Migrated content generally works through the migration tool's link-remapping, but any link that wasn't captured by the migration process (an old link pasted into a document or chat years ago, for instance) may now point to nothing — checking any business-critical old Stream Classic links after migration, rather than assuming they redirected automatically, is worth the modest effort involved.
---
# Microsoft Syntex — content AI for SharePoint
URL: https://www.solvingmicrosoft365.com/guides/microsoft-syntex-deep-dive
Category: SharePoint & OneDrive
Published: 2026-05-01
> Microsoft Syntex (formerly SharePoint Premium) brings document understanding, content assembly, and AI processing to SharePoint.
**Microsoft Syntex** — also marketed as **SharePoint Premium** — is Microsoft's content AI service for SharePoint and Microsoft 365 content. It adds capabilities for understanding, classifying, extracting, and processing documents at scale, plus content assembly, eSignature, and advanced search. Useful when your organisation has high-volume document processes (contracts, invoices, claims, forms) that have historically been manual.
The SharePoint-side view is [Syntex content processing](/guides/sharepoint-syntex-content-processing); Syntex feeds [document libraries](/guides/sharepoint-document-libraries-deep-dive) metadata, competes with [AI Builder document processing](/guides/ai-builder-document-processing), and its successors surface in [Copilot](/guides/what-is-microsoft-copilot-for-m365).
## What Syntex provides
### Document understanding
Train **AI models** to classify documents and extract specific fields. Two flavours:
- **Unstructured document processing** — for text-heavy documents (contracts, policies, articles) where layout varies. Uses example-based training with Power Automate / AI Builder.
- **Structured/freeform document processing** — for forms (invoices, receipts, applications) with consistent field positions. Uses **AI Builder** form processor under the hood.
- **Prebuilt models** — Microsoft ships models for common document types (invoices, receipts, contracts, business cards) ready to use.
Once trained and applied to a SharePoint library, documents arriving in the library are automatically classified and have their extracted fields written into SharePoint columns.
### Content assembly
Generate documents from templates and structured data. Use cases: contract generation from a Dataverse customer record, proposal generation from a SharePoint list, letter generation from a CRM. The author defines a Word template with placeholders; Syntex fills them in from chosen data sources.
### Content query
AI-aware search across the tenant, with semantic ranking and natural-language understanding. Surfaced as an enhanced experience in Microsoft Search.
### eSignature
Native digital signing in Microsoft 365 — request signatures on PDF documents, collect them, file the signed artefact back in SharePoint. Alternative to DocuSign / Adobe Sign for in-tenant signing workflows.
### Content processing
Pay-as-you-go automated processing — image tagging, OCR, language detection, taxonomy management — applied at scale to content in SharePoint and OneDrive.
### Content compliance
Apply retention labels and sensitivity labels automatically based on AI-driven content classification.
## Where it fits
Syntex is most valuable when:
- **High-volume document processes** consume significant manual effort.
- Documents have **structured information** worth extracting and indexing.
- **Compliance** drives consistent classification of large content volumes.
- Existing **third-party content automation** tools are due for replacement.
It's less useful when:
- Document volumes are low — manual handling is fine.
- Existing systems already handle the workflow well.
- Content is too variable for ML models to perform reliably.
## Licensing
Syntex has shifted to a **pay-as-you-go** model billed by transaction volume:
- **Document understanding transactions** per file processed.
- **Content assembly** per document generated.
- **eSignature** per signature request.
- **Image / video processing** per asset.
Some capabilities can also be licensed per-user (heavier monthly use). Pricing has changed several times — check the current Syntex pricing page when planning.
## Relationship to Microsoft 365 Copilot
Syntex and **Microsoft 365 Copilot** are complementary. Copilot is conversational AI grounded on user content; Syntex is content-side AI that classifies, extracts, and processes documents systematically. Syntex makes content **machine-understandable**, which makes Copilot **more accurate** when reasoning over that content.
For organisations rolling out Copilot at scale, Syntex is part of the data-quality investment that pays back in Copilot quality.
---
# Microsoft Teams apps and tabs
URL: https://www.solvingmicrosoft365.com/guides/microsoft-teams-apps-and-tabs
Category: Microsoft Teams
Published: 2026-05-01
> How Teams apps, tabs, bots, and message extensions work — and how to govern them.
Microsoft Teams is a platform as well as a client. Apps extend Teams into other systems, and they show up in several different forms — tabs, bots, message extensions, personal apps, and meeting extensions. Knowing the shapes helps both users and admins.
Which apps are allowed is set in [app permission policies](/guides/teams-app-permission-policies); building your own is covered in [Teams app development for Copilot](/guides/teams-app-development-for-copilot), and the Copilot-era equivalent is [agents and the Agent Store](/guides/copilot-agents-and-agent-store-governance). Tabs most often surface [SharePoint pages](/guides/sharepoint-page-design-and-web-parts) and [Microsoft Lists](/guides/sharepoint-lists-vs-microsoft-lists).
## The forms an app can take
- **Personal app** — a private app on your sidebar, accessible only to you (Planner, Lists, OneNote in personal mode).
- **Tab** — a pinned page inside a channel or chat (a SharePoint page, a Power BI report, a web app, a wiki).
- **Bot** — a conversational agent in a chat or channel that responds to messages or events.
- **Message extension** — actions in the message composer (search a system, share a card, run a workflow).
- **Meeting extension** — apps that load inside a meeting's side panel or stage (polls, whiteboards, third-party tools).
Many published apps include multiple forms — for example, an HR system might offer a personal app, a tab, and a message extension.
## Where apps come from
- **Microsoft and partner apps** — published in the Teams store, ready to install with one click.
- **Custom apps** — built by your organisation with the **Teams Toolkit** or **Developer Portal** and side-loaded or distributed internally.
- **Power Apps and Power Automate** — canvas apps and flows can be deployed as Teams apps without writing code.
## Governance
Apps run with **user permissions**, so they can read what the signed-in user can read. Governance therefore matters:
- **App permission policies** decide which apps users can install.
- **App setup policies** pin a default set of apps to specific user groups.
- **App centric management** in the Teams admin center provides per-app, per-user controls.
- **Defender for Cloud Apps** integrates for monitoring and risk scoring.
For Microsoft 365 Copilot, **Copilot agents** also surface through this app model — they're Teams apps with grounding and reasoning capabilities.
## Lifecycle
Custom apps go through a manifest (`.zip` package) deployed via the Developer Portal or the Teams admin center. Apps can also be published to the **organisation's catalog** so users see only your approved third-party plus internal apps.
Get app governance right early. Once apps spread, retrofitting permission policies is much harder than starting strict and loosening as needed.
## Why "runs with user permissions" is the key governance fact
The single most important thing to understand about Teams apps from a security standpoint is that most apps operate under **delegated permissions** — they see and act on exactly what the signed-in user could see and do themselves, no more. This means app governance isn't really about "is this app trustworthy in the abstract" so much as "what Graph permissions does it request, and does the population it's assigned to actually need that access" — a seemingly innocuous productivity app requesting broad Mail.Read or Files.ReadWrite.All scope is a materially different risk than one requesting nothing beyond posting messages to a channel it's explicitly added to, regardless of how polished either app's interface looks.
## Frequently asked questions
**Can a custom-built internal app be restricted to specific departments only?** Yes — publishing it to the organisation's app catalog and then using app setup or app permission policies scoped to specific user groups controls both who can see it in the store and who it's automatically pinned for, so a finance-specific tool doesn't need to be visible to the whole tenant.
**Do Copilot agents go through the same governance surface as ordinary Teams apps?** Largely yes — agents surface through the same app model (app permission policies, the admin center's app-centric management) with an additional layer specific to agent grounding and data access, which is why the Agent Store is treated as an extension of existing Teams app governance rather than a wholly separate system administrators need to learn from scratch.
---
# External access and guest access in Microsoft Teams
URL: https://www.solvingmicrosoft365.com/guides/microsoft-teams-external-and-guest-access
Category: Microsoft Teams
Published: 2026-05-01
> The four ways outsiders can collaborate with you in Teams — and the trade-offs between guest, external access, shared channels, and anonymous join.
Outside collaboration in Microsoft Teams is a confusingly named topic because the terms overlap. There are actually four distinct mechanisms, and choosing the right one matters for both security and user experience.
## 1. Guest access
A **guest** is someone you add as a full member of one of your teams using their existing email address. They get a guest identity in your Entra ID directory and can chat in channels, access files, and join meetings — almost like a regular member, but with restricted permissions and visibility into your tenant.
Use guest access for **deep, long-term** collaboration with someone outside your organisation (a consultant embedded in a project for a year, for example).
## 2. External access (federation)
**External access** is one-to-one chat and calling with people in other Microsoft 365 tenants — and, optionally, with Skype consumer users. It's federation between tenants. The other party stays in their own tenant entirely; you just exchange messages and calls. No file sharing, no team membership.
Use external access for **direct messaging** with counterparts at other companies.
## 3. Shared channels (Teams Connect)
A **shared channel** lets you invite people from other Microsoft 365 tenants into a specific channel, without making them members of the team or guests in your tenant. They keep their home identity; your tenant publishes the channel via Entra ID **Cross-Tenant Access Settings**.
Use shared channels for **ongoing cross-organisation collaboration** that doesn't justify guest accounts. This is the most modern option and the one Microsoft is investing in.
## 4. Anonymous join
In a meeting, you can let people join **anonymously** without any identity at all — they enter a name and join the lobby. Useful for one-off meetings with people who don't have Teams.
## How to choose
| Need | Mechanism |
| --- | --- |
| Long-term embedded contractor | Guest |
| Direct chat/call with another tenant | External access |
| Ongoing cross-tenant project channel | Shared channel |
| One-off external meeting attendee | Anonymous join |
## Admin controls
All four are toggled separately. In the Teams admin center, External access controls federation; Guest access toggles allow guests at all. Shared channels are governed by Cross-Tenant Access Settings in the Entra admin center. Anonymous join is a meeting policy. A common mistake is to ask "is Teams open to outside people?" without distinguishing which of these four is meant.
## A worked example: partner working with two client tenants
A consultancy runs shared channels to two client tenants and guest access to a third. The design that stops confusion after week two:
- **Client A and B (long engagements, weekly cadence)** — **shared channels** in each client's tenant, the consultants added via B2B direct connect. Consultants sign in with their own identity; the channel content lives in the client's tenant with the client's retention and DLP. No profile switch, no guest account.
- **Client C (short-term, IT project)** — **guest access** in Client C's tenant. Consultants get a guest account and switch profiles in Teams to work there. Cheaper to set up, more friction daily.
- **Cross-tenant access settings** on the consultancy's tenant — Direct Connect inbound: allow, MFA required. Guest access outbound: allow (users can be added as guests elsewhere). B2B collaboration inbound: allow with the client tenants' IDs on the trusted list.
- **CA policies** — session-frequency of 8 hours for guests; require compliant device where the consultants access highly-sensitive client sites.
- **Guest lifecycle** — quarterly access review on the guest account population; anything not touched for 90 days gets removed automatically.
## Decision matrix: shared channels, guest access, or federation
| Situation | Reach for |
| --- | --- |
| Long-lived collaboration with people at one other tenant | **Shared channels** (B2B direct connect) |
| Occasional cross-tenant meeting attendance | **External access** (federation) — no account needed |
| Deep integration with a single partner over months/years | **Shared channels** on both sides, cross-tenant access settings tuned |
| A vendor needs to work inside your team for two weeks | **Guest access** (B2B collaboration) with time-bound access review |
| A single-tenant contractor sitting inside the tenant for months | **Full member** account, not guest |
| Multiple tenants that are all "you" (multi-tenant org, acquired brands) | **Multi-tenant organisation (MTO)** feature — inbound sync + shared channels by default |
## When these features are the wrong tool
- **You need document control not chat control.** Shared channels use a SharePoint site in the tenant that owns the channel. If the content belongs to the *other* side, put the channel there instead — you cannot flip the ownership later.
- **You want two-way calendar visibility.** External-access chat and calling doesn't share free/busy. That's [cross-tenant calendar sharing](/guides/cross-tenant-calendar-sharing), a separate capability.
- **You need per-file classification the partner honours.** Guests inherit your labels within your tenant. In a shared channel the labels live in the owning tenant — the partner can't apply their own on top.
- **You want one identity to work everywhere.** That's [cross-tenant synchronization](/guides/cross-tenant-synchronization) provisioning members across tenants, not guest access. Guests will always be second-class citizens with permission ceilings you can't lift.
## MSP checklist
- **Default posture per tier.** SMB client = guest access on, external access on, shared channels off. Mid-market = shared channels on with trust lists. Regulated = shared channels only, guest access off.
- **Trust list, not open-world.** Configure cross-tenant access settings with the specific partner tenant IDs — never leave "allow all tenants" enabled at the inbound layer.
- **Quarterly guest review** scheduled per client tenant, results archived. Guests dormant for 90 days = removed with a documented policy.
- **Naming convention** for guest accounts (`ext-firstname.lastname@client.com` or the raw external UPN) so the tenant Global Address List makes provenance obvious.
- **Cross-tenant sign-in reports** as part of monthly service review. Unexpected inbound patterns (new partner tenant, new user from a partner) surface before they become a support ticket.
## Frequently asked questions
**What is the difference between external access and guest access in Teams?**
External access (federation) lets your users chat, call, and meet with people in other Microsoft 365 tenants who stay in their own tenant. Guest access invites an outside person into your tenant as a B2B guest so they can join your teams and channels and see files. Most organisations enable both.
**Can I allow guest access for some teams only?**
Yes, through sensitivity labels applied to teams: a label can allow or block guests per team, overriding the org-wide default. Without labels, the guest setting is tenant-wide and per-team control is limited to owners' ability to add members.
**Is external chat with Teams personal accounts safe?**
It is a phishing and spam vector — attackers used it in 2023–2024 campaigns. Restrict external access to specific domains, disable chat with unmanaged Teams accounts unless there is a business need, and educate users that Teams chat can be phishing too.
---
# Microsoft Teams meeting policies
URL: https://www.solvingmicrosoft365.com/guides/microsoft-teams-meeting-policies
Category: Microsoft Teams
Published: 2026-05-01
> Meeting policies are the admin controls that decide what users can do in Teams meetings. Here's the map.
Meeting policies in Microsoft Teams are the admin controls that govern what happens before, during, and after a meeting. They're assigned per user (or via group assignment) from the Teams admin center, and they're the right lever for almost any "can we lock down…" question.
## What a meeting policy controls
A single meeting policy aggregates dozens of settings. The main groups:
- **General** — Meet Now in channels, scheduling permissions, channel meeting scheduling, Outlook add-in.
- **Audio & video** — IP audio and video, transcription, recording (cloud), live captions, language interpretation.
- **Content sharing** — screen sharing mode (entire screen vs window only), PowerPoint Live, whiteboard, shared notes, external participants giving control.
- **Participants & guests** — anonymous join, anonymous starting a meeting, "who can present" defaults, who can bypass the lobby, chat in meetings.
- **Engagement** — Q&A, reactions, polls.
- **Watermarking** — adds a watermark to shared content for confidential meetings (Teams Premium).
## Default policies and overrides
Every tenant has a **Global (Org-wide default)** meeting policy that applies to everyone unless overridden. Custom policies can be created and assigned to individual users or groups. Microsoft ships several **preset policies** as starting points:
| Preset | Typical use | What it locks down |
| --- | --- | --- |
| All On | Pilot groups, internal power users | Nothing — every feature enabled, for testing |
| Kiosk | Shared/lobby devices, meeting-room-only accounts | No scheduling, minimal controls, join-only behaviour |
| Restricted Anonymous Access | External-facing or regulated teams | Anonymous join and lobby bypass disabled entirely |
Starting from the closest preset and adjusting a handful of settings is usually faster and less error-prone than building a custom policy from the Global default line by line.
## Settings vs policies
Don't confuse **Meeting policies** (per-user, what users can do) with **Meeting settings** (tenant-wide, defaults for things like anonymous join domains, customisable meeting URL, QoS markers). Both live in the same admin nav and both affect meetings, but they apply at different scopes.
## Practical baselines
A reasonable baseline for most organisations:
- Cloud recording **on** for everyone, with retention via a Purview policy.
- Transcription **on** (required for Copilot meeting recap).
- Anonymous join **on**, but anonymous users must wait in the lobby unless explicitly admitted.
- Who can present default to **specific people**, not "Everyone."
- Chat in meetings **enabled with history retained** for the meeting only.
Adjust from there for high-security teams (executives, regulated functions) with a stricter custom policy.
Setting these once and forgetting them is one of the highest-leverage things an admin can do — every meeting in the tenant benefits forever.
## Meeting policy vs meeting template vs meeting type
It's worth keeping three similarly-named things straight. A **meeting policy** (this page) controls *capabilities* — what a user is allowed to do. A **meeting template** controls *defaults for a specific scenario* (Town Hall, Webinar) — what a new meeting of that type looks like when created, layered on top of whatever the user's policy already permits. A **meeting type** (regular meeting, Webinar, Town Hall) determines which template and which subset of engagement features (registration, Q&A moderation, reporting) are even available at all — a regular Teams meeting can't retroactively become a webinar's registration-and-reporting experience just by changing policy settings; the organiser has to create it as that meeting type from the start.
## Troubleshooting effective policy
The Teams admin center's per-user "effective policy" view is the fastest way to resolve a "why can't this user do X" ticket — it shows exactly which meeting policy applies to that specific user right now, after any group-based assignment, rather than requiring an admin to manually trace group memberships against policy assignments. Two things trip people up repeatedly: **assignment order** (a user can only have one meeting policy at a time; if they're in multiple groups with different policy assignments, Teams uses a defined precedence, not "most restrictive wins" or "most permissive wins" automatically), and **propagation delay** (a changed assignment can take several hours to reach the client, so testing immediately after a change and concluding it "didn't work" is a common false alarm). A third source of confusion is that some settings are genuinely locked to the meeting the moment it's scheduled — recording and transcription availability, in particular, reflect the policy in force at scheduling time for that specific meeting series, so a policy change doesn't retroactively apply to meetings already on the calendar; the organiser needs to reschedule or recreate the meeting for the new policy to take visible effect there.
## Frequently asked questions
**What is a Teams meeting policy?**
A set of settings assigned to users that controls what they can do in meetings they organise or join: recording, transcription, who can present, lobby behaviour, screen sharing, reactions, Copilot, and more. Everyone gets the Global (org-wide default) policy unless assigned another.
**Should I create custom meeting policies or edit the Global policy?**
Edit Global for settings everyone should have (transcription on, lobby for anonymous joiners), and create custom policies only for populations with different needs — executives, frontline, external-facing teams. Many custom policies become unmanageable.
**Why did my meeting policy change not take effect?**
Policy changes propagate over several hours (occasionally up to 24), and users may need to restart Teams. Meetings already scheduled keep some settings from when they were created; check the user's effective policy in the Teams admin center before assuming it failed.
---
# Microsoft Teams meetings best practices
URL: https://www.solvingmicrosoft365.com/guides/microsoft-teams-meetings-best-practices
Category: Microsoft Teams
Published: 2026-05-01
> Practical configuration and habits for running better Teams meetings — scheduling, security, recording, and accessibility.
Most Teams problems aren't with the product itself but with how meetings are set up. A handful of habits — and a few admin settings — go a long way.
The admin side of these practices is in [meeting policies design](/guides/teams-meeting-policies-design), [breakout rooms](/guides/teams-breakout-rooms), [recording management](/guides/teams-meeting-recording-management), and [Teams Rooms](/guides/microsoft-teams-rooms); the AI layer is [Copilot in Teams meetings](/guides/copilot-in-teams-meetings-recap-and-action-items).
## Schedule from the right surface
Use the **Teams calendar**, **Outlook**, or **Bookings** to create meetings rather than ad-hoc "Meet now" calls. Scheduled meetings get a proper join link, a chat that persists, a calendar entry, and the option of channel meetings (which post the meeting to a channel where the team can pick it up).
## Lock down lobby and presenters
By default, anonymous and guest users wait in the **lobby**. Keep this on for external meetings. For internal recurring meetings, make trusted attendees **Presenters** and everyone else **Attendees**, which restricts who can share screens, manage breakouts, or mute others.
## Recording, transcription, and Copilot
Recording and transcription are admin-toggled. Once on, recordings are stored in the organiser's OneDrive (for non-channel meetings) or in the channel's SharePoint site (for channel meetings), with permissions inherited from those locations. Transcription is required for **meeting recap** and **Microsoft 365 Copilot in Teams** post-meeting summaries to work well. Make sure attendees know meetings are being recorded.
## Layout and accessibility
- Turn on **Together mode** or **Gallery** for large meetings; **Speaker view** for small ones.
- Enable **live captions** for accessibility and noisy environments. Live translation is available in some plans.
- Use **PowerPoint Live** instead of screen-sharing slides — it preserves searchable text, lets attendees navigate independently, and reads cleanly to screen readers.
## Breakouts and town halls
For workshops and training, **breakout rooms** scale well up to about 50 rooms per meeting. For very large audiences (1,000+), use **Town Halls**, which provide a structured presenter/attendee model and built-in event production tools.
## Admin defaults that matter
In the **Teams admin center**, set sensible defaults under Meetings → Meeting policies: anonymous join, recording retention, who can present, and chat history controls. Pair those with a clear **Conditional Access** policy that enforces MFA and compliant devices for joining sensitive meetings.
Good defaults beat good habits — once these are set, meetings tend to run themselves.
## Meeting hygiene that isn't a setting
Some of the highest-impact practices aren't admin toggles at all. **Agendas in the invite** — even three bullet points — measurably shorten meetings and give latecomers something to orient against without asking "what did I miss." **Naming meetings specifically** ("Q3 budget review — decision needed" rather than "Sync") helps attendees triage a packed calendar and helps anyone searching Copilot-generated recaps later find the right one. **Ending meetings with a clear owner per action item**, not just a list of tasks, is what actually makes a Copilot-generated action-item summary useful afterward — a summary of "things discussed" with no owners just becomes another document nobody acts on.
## Frequently asked questions
**Should cameras be required in meetings?** There's no admin setting for this — it's a team-culture decision, not a policy one — but a light-touch default (cameras encouraged for internal working sessions, optional for large all-hands or when someone is on a poor connection) tends to work better than a hard mandate, which mainly generates friction for the exact situations where it's least warranted.
**Why do some recordings show up in a channel's SharePoint site while others land in a personal OneDrive?** Recording storage location follows the meeting type: a **channel meeting** (scheduled from within a Teams channel) stores its recording in that channel's SharePoint site, visible to the whole channel by default; an ordinary calendar meeting recording lands in the organiser's own OneDrive, visible only to people the organiser explicitly shares it with. Choosing to schedule as a channel meeting when the recording should be broadly discoverable — and as a personal meeting when it shouldn't — is a simple lever many organisers don't realise they're pulling.
**Is it worth enabling live translation alongside captions?** For genuinely multilingual audiences, yes — but it's worth testing with real speakers on real accents and technical vocabulary before rolling it out broadly, since automated translation quality varies noticeably by language pair and drops further with jargon-heavy content; a pilot with the specific meeting types and languages that will actually use it avoids discovering the gaps live in front of an audience.
---
# Private vs shared channels in Microsoft Teams
URL: https://www.solvingmicrosoft365.com/guides/microsoft-teams-private-vs-shared-channels
Category: Microsoft Teams
Published: 2026-05-01
> When to reach for a private channel versus a shared channel — the membership model, storage, and external-access trade-offs.
Standard channels in Microsoft Teams are easy: they're visible to every member of the team. The interesting decisions start when you need restricted membership — that's where **private channels** and **shared channels** come in. They look similar but solve different problems.
## Private channels
A private channel is for a **subset of the parent team's members**. Membership is a strict subset — you can't add anyone who isn't already in the team. Use cases:
- Leadership-only sub-channel inside a department team.
- HR business-partner channel inside a HR team.
- Sensitive project work inside a wider product team.
Each private channel provisions its own **SharePoint site** (not just a folder), with its own permissions and storage quota. That gives strong isolation but creates more sites to govern.
## Shared channels
A shared channel allows you to add **people who aren't members of the parent team** — including users from **other Microsoft 365 tenants** (cross-tenant collaboration via Entra ID's external collaboration settings). Members of a shared channel don't see the rest of the team. Use cases:
- Ongoing collaboration with an external partner organisation.
- A cross-team working group that spans two or three product teams.
- A vendor or consultant relationship that needs persistent chat plus files.
Shared channels also get their own SharePoint site.
## Decision matrix
| Need | Channel type |
| --- | --- |
| Confidential subgroup within the team | Private |
| Cross-team or cross-tenant collaboration | Shared |
| Open to all team members | Standard |
| Guests need full team access | Standard with guest accounts |
## Operational caveats
- **Conversion isn't supported**: a channel created as standard, private, or shared stays that type. Plan up front.
- **App support is uneven**: some Teams apps work in standard but not private or shared channels — check before you commit.
- **Cross-tenant shared channels** need both tenants to configure trust under Cross-Tenant Access Settings, and both ends need to enable shared channels for the partner.
- **Quotas matter**: each team has limits (200 standard, 30 private, 200 shared), and every private/shared channel inflates your SharePoint site count.
Used well, private and shared channels keep the right people focused on the right conversations without sprouting more whole teams.
## Why not just create a separate team?
The temptation to solve "some people need restricted access" by spinning up a whole new team is understandable, but it multiplies the things that need governing — a new Microsoft 365 Group, a new SharePoint site, a new set of owners to maintain, and a parallel structure that's easy to lose track of alongside the parent team it logically belongs with. A private or shared channel keeps the restricted conversation discoverable in context (still listed under the parent team, just with narrower membership) while still isolating the SharePoint storage and permissions behind it — the right default whenever the restricted group's work is a subset or extension of the parent team's purpose, reserving a genuinely separate team for work that doesn't conceptually belong under any existing team at all.
## Frequently asked questions
**Can a private channel's SharePoint site be accessed directly, bypassing Teams?** Yes — like any Teams channel, a private channel's SharePoint site has its own URL and can be reached directly by anyone with permission, which matters for admins running SharePoint-level reports (including SharePoint Advanced Management's oversharing reports) since private and shared channel sites show up there as sites in their own right, not nested inside the parent team's site.
**What happens to a private or shared channel if the parent team is deleted?** The channel and its SharePoint site are deleted along with the parent team (subject to the same recycle-bin recovery window as the team itself) — a shared channel's external members lose access at that point too, since the channel's existence is still tied to the parent team even though its membership extended beyond it.
**Can a shared channel's external partner see who else is in the parent team?** No — a fundamental design point of shared channels is that external or cross-team members only ever see the shared channel's own membership, never the parent team's roster, files, or other channels. This is what makes shared channels usable for genuinely sensitive partner relationships in a way that simply adding the partner as a guest to the whole team never could be.
---
# Microsoft Teams Shifts for frontline workers
URL: https://www.solvingmicrosoft365.com/guides/microsoft-teams-shifts-for-frontline
Category: Microsoft Teams
Published: 2026-05-01
> Shifts is the schedule-management app in Teams for shift-based work. Here's what it does and where it fits.
**Shifts** is the schedule-management app built into Microsoft Teams, aimed at frontline and shift-based workers — retail associates, healthcare staff, hospitality, manufacturing, field services. It gives managers a tool for building schedules and workers a phone-friendly view of when and where they're working.
Shifts pairs with [Walkie Talkie](/guides/teams-walkie-talkie-and-frontline) in the frontline toolkit, is licensed through the [F1 and F3 plans](/guides/frontline-plans-deep-dive), and runs on shared devices managed per [Intune Android Enterprise](/guides/intune-android-enterprise); the integration story connects to [Power Automate](/guides/what-is-power-automate) for schedule automation.
## What managers do
Managers use the Shifts app (in Teams, or via the **Teams admin center**) to:
- Build a weekly or monthly **schedule** for a team, with shifts, time-off, and open shifts.
- **Assign shifts** to individual members of the team.
- Publish the schedule, which notifies workers via Teams on mobile.
- **Approve swap and offer requests** when workers want to trade shifts.
- Track **time-off** balances and approvals.
- See **clock-in / clock-out** records if Time Clock is enabled.
## What workers do
Workers see their schedule on the Shifts tab in Teams. They can:
- See upcoming shifts.
- **Swap** shifts with eligible colleagues.
- **Offer** shifts to others.
- Request **time off**.
- **Clock in / out** (with optional geofencing — only allow clock-in within X metres of the workplace).
- Mark themselves available or unavailable.
## Integration with the rest of Teams
Shifts builds on the Teams frontline experience:
- A **frontline manager** policy sets the right Teams app layout for that role.
- **Walkie Talkie** gives push-to-talk over Wi-Fi or cellular.
- **Approvals**, **Tasks by Planner**, and **Praise** complement Shifts for day-to-day shift work.
- **Microsoft 365 F1 / F3** plans license frontline-worker users at lower cost than knowledge-worker plans.
## Integration with workforce-management systems
For organisations running enterprise WFM tools (Blue Yonder JDA, Kronos / UKG Dimensions, Reflexis, Zebra Reflexis), Shifts has a **WFM connector** model that syncs schedules between the source system and Teams. This is the right approach when the source of truth lives in WFM — managers keep their existing tooling, but workers see the schedule in Teams on mobile.
## Where Shifts fits
Shifts isn't a replacement for full workforce management — it doesn't do labour forecasting, demand modelling, or complex compliance. It's a "good enough" scheduler for organisations that didn't have one, and a clean phone interface for organisations that did but couldn't get workers to install yet another app.
## Licensing frontline devices, not just people
Shifts is licensed through **Microsoft 365 F1 or F3**, but a frontline rollout is rarely just a licensing decision for the person — the **shared device** the schedule is viewed on matters just as much. A retail floor with one tablet per department, used by whoever's on shift, needs **shared device mode** (a single Entra ID device identity multiple staff sign in and out of quickly, rather than one device per employee) and an Intune Android Enterprise or Windows shared-device configuration to match — buying F3 licences for every frontline worker without also solving the shared-device sign-in experience typically produces a rollout that looks fully licensed on paper but that workers avoid using because signing in and out is too slow for a five-minute break.
## Frequently asked questions
**Can Shifts replace a dedicated workforce-management system entirely?** For simple scheduling needs, often yes; for organisations with real labour-forecasting, demand-modelling, or complex union-rule compliance requirements, Shifts is deliberately not trying to compete with dedicated WFM platforms — the connector model exists specifically so those organisations can keep their WFM system as the source of truth while still giving workers the Teams mobile experience.
**Does Time Clock in Shifts integrate with payroll systems?** Time Clock captures clock-in/out events and makes them available for export or via Graph API integration, but it isn't itself a payroll system — organisations typically feed that data into their existing payroll or WFM platform rather than treating Shifts as a standalone payroll source.
---
# Microsoft Teams templates
URL: https://www.solvingmicrosoft365.com/guides/microsoft-teams-templates
Category: Microsoft Teams
Published: 2026-05-01
> Templates standardise how new teams are created — channels, tabs, apps, and settings, baked into one starting point.
A **team template** in Microsoft Teams is a pre-defined blueprint for creating new teams. It bundles a set of channels, pre-installed apps and tabs, and starter settings, so users don't start from a blank slate every time.
Templates enforce the structure decisions in [Teams channels explained](/guides/microsoft-teams-channels-explained) and [Groups vs Teams vs SharePoint](/guides/m365-groups-vs-teams-vs-sharepoint); combine them with [naming and expiration policies](/guides/group-naming-and-expiration-policies) and [sensitivity labels](/guides/purview-sensitivity-labels-deep-dive) for a governed creation process.
## Why templates exist
Without templates, every team grows organically — different channel naming, different apps, different conventions — and quickly becomes hard to govern. A template makes the **first version of a team consistent** with how you want similar teams to look.
Templates are most valuable for repeatable patterns:
- **Project teams** with consistent kickoff, planning, retro channels.
- **Incident response teams** with predefined apps for paging, status, and post-mortems.
- **Department teams** (HR, Finance) with standard channels for typical workstreams.
- **Crisis management** with the right ServiceNow / PagerDuty / Approval apps already pinned.
## Built-in templates
Microsoft ships a small set of built-in templates: Manage a Project, Manage an Event, Crisis Response, Patient Care, Bank Branch, Retail, and so on. They're a useful starting point even if you don't use them as-is.
## Custom templates
In the Teams admin center under **Teams → Team templates**, you can:
- Create a template **from scratch**.
- Create one **from an existing team** (recommended — clone a known-good team).
- Create one **from an existing template** and customise.
A custom template defines: the team's default settings, the channel list (standard channels only — private and shared channels aren't in templates), and tabs/apps pinned to each channel. It doesn't include channel content, files, or membership.
## Assignment
Admins decide which templates show up in the "Create a team" flow via **Team templates policies**. A policy can hide all built-in templates and surface only the templates your governance approves. Pair this with **naming and expiration policies** for Microsoft 365 Groups for full control over team sprawl.
## Limits
Templates are creation-time blueprints; **changing the template later does not update teams that already used it**. If you add a new app to a template, only teams created from that point on get it. Treat templates as defaults, not living standards.
For organisations creating many teams a week, a few well-maintained custom templates pay back the setup time many times over.
## Templates don't replace governance policy
A template standardises the *starting shape* of a team, but it doesn't enforce anything about the team's ongoing lifecycle — naming conventions, expiration, guest access rules, and sensitivity labelling are all governed separately, by Microsoft 365 Groups policies and Conditional Access, and apply regardless of which template (if any) a team was created from. A well-designed template combined with weak group governance still ends up with consistently-structured teams that nonetheless sprawl indefinitely with no owner ever reviewing whether they're still needed; the template solves the "what does day one look like" problem, not the "does this team still need to exist in year three" problem.
## Frequently asked questions
**Can a template pre-assign specific people as owners or members?** No — templates define channels, apps, and settings, but membership is set at creation time by whoever creates the team; a template can't pre-populate a roster, since the whole point is that the same template is reused across many different teams with different people each time.
**What happens to a team's template reference after creation?** Nothing persists — once a team is created from a template, it becomes an entirely independent team with no ongoing link back to the template it was built from. Updating the template afterward has zero effect on teams already created from it, which is why templates should be thought of as one-time blueprints rather than a source of truth to keep teams in sync with.
**Is it better to build a custom template from scratch or clone an existing team?** Cloning a known-good, already-in-use team is usually the faster and more reliable path — it captures the actual apps, tabs, and channel structure that a real working team settled on, rather than an admin's best guess at what a good starting point looks like in the abstract, and it's easy to trim down afterward if the source team had anything too specific to itself.
---
# Microsoft Teams webinars and town halls
URL: https://www.solvingmicrosoft365.com/guides/microsoft-teams-webinars-and-town-halls
Category: Microsoft Teams
Published: 2026-05-01
> The difference between Teams meetings, webinars, and town halls — and when to pick each for an event.
Microsoft Teams supports three distinct event formats: regular **meetings**, structured **webinars**, and large-scale **town halls** (which replaced Teams Live Events in 2024). They share a lot of plumbing but solve different problems.
For the detailed comparisons see [webinars vs meetings and licensing](/guides/teams-webinars-vs-meetings-and-licensing) and [town hall vs live events vs Stream](/guides/teams-town-hall-vs-live-events-vs-stream); the premium features are in [Teams Premium](/guides/teams-premium-features-deep-dive), the recordings end up under [Stream on SharePoint](/guides/microsoft-stream-on-sharepoint), and the buying alternative is [Teams vs Zoom](/guides/microsoft-teams-vs-zoom).
## Regular meetings
A standard Teams meeting is interactive: everyone can see and hear everyone else, share screen, chat, and unmute. It's the right format for working sessions, daily stand-ups, and small workshops. Practical capacity is a few hundred attendees, though all-microphones-open dynamics break down well before that.
## Webinars
A **Teams webinar** is a meeting with structured registration, presenter/attendee roles, and a polished landing page. Typical webinar use cases include training, sales demos, and external presentations to a few hundred attendees.
Webinar features:
- **Registration page** with custom fields, automated confirmation emails, and reminder workflows.
- **Co-organisers and presenters** with distinct permissions.
- **Q&A** moderation, separate from open chat.
- **Reports** on registrants, attendees, and engagement.
- **Green room** for presenters to gather before going live.
Webinars are included in most Microsoft 365 plans, with the Premium webinar features (advanced registration, manual approval, waitlists) requiring Teams Premium.
## Town halls
A **town hall** is built for one-to-many broadcasts — all-hands meetings, product launches, town-hall-style company updates. They scale to tens of thousands of attendees and offer a structured presenter / attendee separation: attendees can ask questions but cannot unmute or share. Town halls support:
- **Multi-language audio** (real-time interpretation channels).
- **External presenters** without tenant accounts.
- **Captions, transcripts, and recording**.
- **eCDN partner integration** for large internal broadcasts.
Hosting town halls of any size requires a regular Microsoft 365 plan; large-scale features and external attendees require **Teams Premium**.
## How to choose
- **Under 300 interactive attendees, working session**: meeting.
- **External or formal audience needing registration, under 1,000**: webinar.
- **Company-wide or large external broadcast, low interactivity**: town hall.
Town halls replaced **Teams Live Events**, which was retired in 2024. Migration is mostly straightforward, but if you have automation calling Live Events APIs, plan a rewrite against the town-hall equivalents.
| | Meeting | Webinar | Town hall |
| --- | --- | --- | --- |
| Interaction model | Fully interactive | Presenter/attendee, moderated Q&A | Presenter/attendee, moderated Q&A |
| Registration | No | Yes, with custom fields | Optional |
| Practical scale | A few hundred | Up to ~1,000 | Tens of thousands |
| External attendees without accounts | Guest access only | Yes | Yes |
| Reporting | Attendance list only | Registrant + engagement reports | Engagement + eCDN delivery reports |
## Frequently asked questions
**Can a webinar be converted into a town hall after it's scheduled, or the reverse?** No — the meeting type is set at creation and determines which template, roles, and reporting are available throughout; changing formats means creating a new event of the target type and re-sending invitations, not editing the existing one in place.
**Do attendees need a Teams licence to join a webinar or town hall?** No — attendees join as guests or anonymously via the registration or join link with no Microsoft 365 licence or even an account required; only the organisation hosting the event needs appropriate licensing (and Teams Premium for the advanced features), not the audience.
**What happened to the recordings and analytics from retired Live Events?** Existing Live Events recordings already saved to Stream or SharePoint were not deleted by the retirement and remain accessible where they were stored; what changed is that no *new* Live Events can be scheduled, so any recurring broadcast previously built on Live Events needs to be recreated as a town hall going forward, with its own separate recording and reporting history starting fresh from that point.
---
# Microsoft Tunnel for Intune
URL: https://www.solvingmicrosoft365.com/guides/microsoft-tunnel-for-intune
Category: Microsoft Intune (Devices)
Published: 2026-05-01
> Microsoft Tunnel provides per-app VPN for managed mobile devices — the Intune-integrated way to access on-prem resources.
**Microsoft Tunnel** is a VPN solution integrated with Microsoft Intune for **managed mobile devices** (iOS, Android, Windows) — providing **per-app VPN** that's controlled through Intune policies and identity-aware via Entra ID. It's how mobile devices access on-premises resources without a traditional client-VPN deployment.
Tunnel is the Intune VPN for the mobile devices managed under [Android Enterprise](/guides/intune-android-enterprise) and protected by [app protection policies](/guides/intune-app-protection-policies) (Tunnel for MAM is in the [Intune Suite](/guides/intune-suite-explained)); for Windows the modern alternative is [Global Secure Access](/guides/entra-global-secure-access).
## What Tunnel provides
For mobile users with Microsoft 365 access plus a need to reach on-prem resources:
- **Per-app VPN** — only specific apps route through the tunnel; everything else uses normal internet.
- **Per-user VPN** — only specific user groups have access.
- **Conditional Access integration** — tunnel access conditional on device compliance, location, sign-in risk.
- **Single sign-on** through Entra ID.
- **TLS-based** — modern VPN, not legacy IPsec.
## Two flavours
### Microsoft Tunnel (MDM-based)
For **Intune-enrolled** managed mobile devices. The Tunnel client is deployed via Intune; configuration profiles set up the VPN; access is gated by Conditional Access.
Best for corporate-owned mobile devices.
### Microsoft Tunnel for MAM (Mobile Application Management)
For **personal devices** under Intune's MAM model — devices that aren't enrolled in MDM but have corporate apps protected by app protection policies. Tunnel for MAM provides similar VPN capability **scoped to MAM-protected apps**, without device enrolment.
Best for BYOD scenarios where the user keeps their device unmanaged but corporate apps need on-prem access.
## Architecture
Tunnel deploys a **gateway service** in your network:
- A small Linux server (often a container) acts as the gateway.
- The gateway authenticates against Entra ID.
- Tunnel client apps on devices connect to the gateway over TLS.
- Traffic is routed from the gateway to internal resources.
Gateways can be deployed in **HA pairs** for resilience and in **multiple regions** for global mobile users.
## Configuration
A typical setup:
1. **Deploy the Tunnel gateway** on a Linux VM in your network, with appropriate firewall rules to reach internal resources.
2. **Register the gateway** with Intune.
3. **Configure server settings** — what subnets and DNS servers the tunnel exposes.
4. **Create VPN profile** in Intune referencing the gateway.
5. **Assign the profile** to user groups.
6. **Pair with Conditional Access** — require Tunnel for accessing specific apps.
7. **Test** with pilot users.
## When Tunnel is right
- **Mobile users needing on-prem resources** — internal websites, legacy line-of-business apps, file shares.
- **Field workers** with corporate-owned mobile devices.
- **BYOD users with MAM** needing controlled access without full device enrolment.
- **Hybrid-cloud scenarios** during migration when on-prem resources still exist.
## When Tunnel isn't right
- **Cloud-native deployments** — apps in Azure / AWS / GCP with no on-prem dependency don't need a VPN.
- **Persistent VPN scenarios** — Tunnel is per-app and per-session; for always-on VPN, look at Entra Private Access or traditional VPN.
- **Linux mobile** — not supported (it's iOS, Android, Windows for now).
- **Non-Intune-managed devices** — Tunnel requires Intune as the management surface.
## Relationship to Entra Private Access
**Entra Private Access** (part of Global Secure Access) overlaps with Tunnel — both publish private apps to remote users. The difference:
- **Tunnel** — Intune-managed mobile devices, classic VPN model.
- **Entra Private Access** — any device, any platform, identity-aware modern model.
For Microsoft 365 customers building toward zero-trust networking, **Entra Private Access** is the strategic direction. Tunnel remains useful for tactical mobile-VPN scenarios in the meantime.
## Licensing
Microsoft Tunnel is part of the **Intune Suite** add-on or licensed standalone. Tunnel for MAM is licensed similarly but with MAM-specific pricing.
For Intune-managed mobile estates with significant on-prem dependencies, Tunnel is a clean way to bridge mobile-to-on-prem without legacy MDM-VPN tooling. For cloud-native estates, it's increasingly unnecessary.
---
# Microsoft Viva Engage moderation
URL: https://www.solvingmicrosoft365.com/guides/microsoft-viva-engage-moderation
Category: Viva & Apps
Published: 2026-05-01
> Moderating Viva Engage communities — policies, reporting, community guidelines, and the moderation toolset.
**Microsoft Viva Engage** is the enterprise social network in Microsoft 365 (the rebrand of Yammer). For organisations using Viva Engage at scale, **moderation** — keeping conversations productive, respectful, and within community guidelines — is essential. The moderation toolset is mature; using it well is mostly an operational question.
Engage is introduced in [Viva Engage vs Yammer](/guides/microsoft-viva-engage-vs-yammer) and the [Viva overview](/guides/microsoft-viva-overview); moderation sits beside [Communication Compliance](/guides/purview-communication-compliance) in the conduct controls, and community campaigns run through [Viva Amplify](/guides/microsoft-viva-amplify-for-internal-comms).
## Community structure
Viva Engage organises content into:
- **Storylines** — personal posts by individuals (like LinkedIn).
- **Communities** — topic-based groups people opt into.
- **Stories** — short video / image posts.
- **All Company** — the tenant-wide community everyone is in by default.
- **Leadership Corner** — surfaced posts from designated leaders.
Each community has **community admins** who own moderation and content curation. The structure scales — large organisations may have hundreds of communities.
## Roles in moderation
- **Verified admins** — tenant-wide admins managing all communities.
- **Network admins** — admins of the All Company / network.
- **Community admins** — own moderation in their specific community.
- **Group admins** — older designation for Microsoft 365 Groups managed via Viva Engage.
Moderation responsibilities can be delegated to specific community-admin roles per community.
## Moderation tools
The toolset for community admins:
- **Delete posts** that violate guidelines.
- **Edit posts** if appropriate (mark as edited).
- **Pin announcements** to the top of the community.
- **Mute users** for specific durations.
- **Remove users** from a community.
- **Mark "best answers"** for Q&A posts.
- **Stop notifications** on threads.
- **Lock threads** to prevent further replies.
At the tenant level, network admins can:
- **Block users** tenant-wide.
- **Delete content** across communities.
- **Export content** for legal / compliance investigations.
## Community guidelines
For each community, publish clear guidelines:
- **What's encouraged** — topic-related discussions, helping colleagues.
- **What's not** — off-topic content, harassment, confidential information.
- **Reporting** — how to flag inappropriate content.
- **Moderation response time** — what users can expect.
Pinned community guidelines reduce moderation load by setting expectations upfront.
## Reporting and escalation
Users can **report content** they find inappropriate:
- Reports go to community admins for the relevant community.
- Tenant-wide reports for serious issues escalate to network admins.
- **Communication compliance** (Microsoft Purview, requires E5 / E5 Compliance) can automatically detect concerning content for review.
For organisations with formal HR / Legal involvement in social-media incidents, the escalation path needs to be documented.
## Communication compliance integration
For regulated industries or organisations wanting automatic content review, **Microsoft Purview Communication Compliance** policies can scan Viva Engage content for:
- Harassment language.
- Sensitive information disclosure.
- Conflict-of-interest signals.
- Regulatory-violation keywords.
Detections route to designated reviewers (compliance officers, HR, security) for review. Important for finance, healthcare, defence, and other regulated industries.
## Best practices
- **Active moderation** — community admins regularly visible, posting, responding.
- **Recognise positive contributions** — Praise feature, public thanks.
- **Address violations promptly** — don't let bad content sit.
- **Be transparent about removal** — when content is removed, leadership knows why.
- **Periodic community audits** — communities without activity or owners get archived.
## Common challenges
- **Off-topic drift** — communities about Topic X end up discussing Topic Y. Moderators redirect.
- **Single-voice dominance** — one user posts everything; others quieted. Encourage diverse participation.
- **Bot / spam content** — increasingly rare with Microsoft 365's filtering but possible.
- **Leadership absence** — communities thrive when leaders participate; suffer when leaders ignore.
## Cultural framing
Successful Viva Engage moderation depends on **culture more than policy**. A trusting culture with explicit guidelines and active moderation produces vibrant communities. A distrustful culture with strict rules produces communities people don't post in.
For organisations rolling out Viva Engage seriously, the moderation programme is more important than the tooling. Pick community admins carefully; give them guidance; trust them.
---
# Viva Engage vs Yammer
URL: https://www.solvingmicrosoft365.com/guides/microsoft-viva-engage-vs-yammer
Category: Viva & Apps
Published: 2026-05-01
> Viva Engage is the rebranded and refactored Yammer. Here's what changed and what didn't.
**Microsoft Viva Engage** is the rebrand of **Yammer**, but it's also more than a name change: the product has been re-architected, re-integrated, and given some new features. For organisations on Yammer or thinking about enterprise social, the differences matter.
See the [Viva overview](/guides/microsoft-viva-overview) for the suite, [Viva Engage moderation](/guides/microsoft-viva-engage-moderation) for running communities, [Viva Amplify](/guides/microsoft-viva-amplify-for-internal-comms) for campaigns, and [Teams channels explained](/guides/microsoft-teams-channels-explained) for when a channel is the better tool.
## The rebrand
In 2023 Microsoft renamed Yammer to **Viva Engage** as part of folding Yammer into the Microsoft Viva family. The classic Yammer URL (`yammer.com`) now redirects to **`engage.cloud.microsoft`**. The same content, communities, and conversations move with the rename — no migration required.
## What's new beyond the name
- **Native Teams integration** — Engage is the default community surface inside Teams, not a separate web app users have to switch to.
- **Communities** replace the older "groups" concept, with more structured roles (community admin, member, follower).
- **Leadership corner** — surfaced posts from leaders, with focused engagement metrics (questions answered, posts engaged).
- **Storylines** — personal-feed posts from individuals, similar to LinkedIn but inside the tenant.
- **Stories** — short video and image posts.
- **AMAs (ask me anything)** — structured Q&A events with leaders.
- **Answers in Viva Engage** — a Stack Overflow-style Q&A surface for the org.
- **Topics** integration — posts can be tagged with Viva Topics for richer cross-content surfacing.
## What didn't change
- The underlying community / conversation model is recognisably Yammer.
- Existing groups, files, and conversations carried over.
- Federation models and external network features carried over.
- The basic permission model (community membership, internal vs external networks).
## How it fits with Teams
This is the most asked question: **isn't this just Teams channels?** No:
- Teams channels are for small group collaboration with shared files and meetings.
- Viva Engage communities are for **large-scale, social-style discussion** — hundreds or thousands of people, broad announcements, opt-in conversations.
A 5,000-employee company doesn't have a "general" Teams channel for everyone — it would be useless. It does have an "All employees" Viva Engage community for that traffic.
## When Engage is the right tool
- **Company-wide announcements** with comment threads.
- **Leadership communication** beyond one-way broadcasts.
- **Cross-functional communities** (parents' network, cycling club, communities of practice).
- **Knowledge sharing** at scale where Q&A and search matter.
- **Internal recognition** programmes.
## When it's not
- Project work — use Teams.
- Time-sensitive discussion — use Teams chat or channels.
- Document collaboration — use SharePoint and Loop.
- External community engagement — use customer communities or third-party platforms.
## Licensing
Viva Engage **basic features** are included with most Microsoft 365 plans. **Premium features** — advanced leadership analytics, advanced AMA features, additional moderation tools — require **Viva Suite** or **Viva Engage standalone licensing**.
For organisations that previously had a Yammer footprint, Viva Engage is a worthwhile reinvestment. For those that never adopted Yammer, the question is whether enterprise social fits the culture — that's a strategy decision, not a tooling one.
---
# Microsoft Viva Learning
URL: https://www.solvingmicrosoft365.com/guides/microsoft-viva-learning
Category: Viva & Apps
Published: 2026-05-01
> Viva Learning is a single learning surface inside Teams that aggregates content from many providers. Here's how it works.
**Microsoft Viva Learning** is the central learning surface in Microsoft 365 — a Teams app and an Outlook integration that aggregates learning content from many providers into one place, makes it discoverable, and lets managers assign and track training.
Learning is one module of the [Viva overview](/guides/microsoft-viva-overview); its content sources include [LinkedIn Learning](/guides/microsoft-viva-learning-linkedin-learning-integration), it delivers the [training programmes](/guides/microsoft-365-training-programs) a [champions network](/guides/champions-network) runs, and it is a natural home for [Copilot use cases by role](/guides/copilot-use-cases-by-role).
## What Viva Learning aggregates
Out of the box, Viva Learning ships with content from:
- **Microsoft Learn** — Microsoft's own training catalogue.
- **LinkedIn Learning** — included content (more with a LinkedIn Learning subscription).
- **Microsoft 365 Training** — Office app training.
With premium licensing, additional providers integrate natively:
- **Coursera**.
- **edX**.
- **Pluralsight**.
- **Udemy Business**.
- **Skillsoft**.
- **Many others** through Viva Learning Content Connector partners.
You can also bring **internal content** from SharePoint and OneDrive — videos, documents, presentations — into Viva Learning so it sits alongside external content.
## The user experience
In Viva Learning (a Teams app), users see:
- **Recommended for you** — content tied to their role and recent activity.
- **Required for you** — content assigned by a manager or admin.
- **Search** across the whole catalogue.
- **My Learning** — a personal queue of saved and in-progress content.
- **Sharing** — drop a course into a Teams chat or channel to recommend it.
- **Completion tracking** — for many provider integrations.
Outlook integration lets a manager send a course as part of an email message; recipients can launch it without leaving Outlook.
## Manager and admin features
- **Assign learning** to specific users or groups with due dates.
- **Recommend learning** without making it mandatory.
- **Track completion** for assignments.
- **Reports** on completion rates and engagement.
## Integration with HRIS and LMS
For organisations with an existing **Learning Management System (LMS)** — Cornerstone, Workday Learning, SAP SuccessFactors — Viva Learning typically complements rather than replaces:
- Use the LMS for **compliance training** with strict tracking, accreditation, and audit requirements.
- Use Viva Learning for **discovery** — surface content from many sources in a flow that integrates with Teams and Microsoft 365.
A Viva Learning **LMS connector** model exists for some providers, but the relationship is often "Viva surfaces, LMS records."
## Licensing
- **Viva Learning Free** — included with most Microsoft 365 plans. Limited to a basic catalogue (Microsoft Learn, free LinkedIn Learning content, a sampling of partners).
- **Viva Learning premium / Viva Suite** — full content provider integrations, manager features, analytics.
## When it's useful
- For **learning discovery** in companies with many content subscriptions that previously lived in silos.
- For **lightweight learning paths** where formal LMS infrastructure is overkill.
- For **embedded learning** — surfacing relevant content next to actual work in Teams.
For organisations whose primary L&D investment is in a dedicated LMS, Viva Learning is an addition, not a replacement. For those without a serious L&D toolset, the free tier is a meaningful improvement on the status quo.
---
# Microsoft Viva overview
URL: https://www.solvingmicrosoft365.com/guides/microsoft-viva-overview
Category: Viva & Apps
Published: 2026-05-01
> Microsoft Viva is the employee experience platform inside Microsoft 365. Here's what's in it and how it fits together.
**Microsoft Viva** is Microsoft's **employee experience platform (EXP)** — a family of products built on top of Microsoft 365 covering communications, learning, well-being, knowledge, and goals. It's positioned as the modern intranet plus workforce-analytics plus learning-and-development surface, all delivered through Teams.
Each module has its own guide: [Viva Insights](/guides/microsoft-viva-insights), [Viva Learning](/guides/microsoft-viva-learning) and its [LinkedIn Learning integration](/guides/microsoft-viva-learning-linkedin-learning-integration), [Viva Engage moderation](/guides/microsoft-viva-engage-moderation) and [Viva Engage vs Yammer](/guides/microsoft-viva-engage-vs-yammer), [Viva Amplify for internal comms](/guides/microsoft-viva-amplify-for-internal-comms), and [what to do about OKRs after Viva Goals' retirement](/guides/microsoft-viva-goals-and-okrs-after-retirement). Adoption programmes around Viva usually lean on [a champions network](/guides/champions-network) and [Adoption Score](/guides/microsoft-adoption-score).
## What's in Viva
The modules, grouped:
### Communications and community
- **Viva Connections** — the modern intranet surface, a personalised home in Teams pulling SharePoint content, news, and announcements.
- **Viva Engage** — community discussions, social posts, Q&A, "ask me anything" sessions, internal video. The rebranded successor to Yammer.
- **Viva Amplify** — outbound corporate communications and campaign management.
### Insights and well-being
- **Viva Insights** — personal productivity insights, manager insights, leader insights based on Microsoft 365 telemetry.
- **Viva Pulse** — quick feedback surveys.
- **Viva Glint** — full employee engagement surveys (formerly Glint).
### Knowledge and expertise
- **Viva Topics** — AI-curated knowledge cards about people, projects, and concepts surfaced across Microsoft 365. **Note**: Microsoft has announced Viva Topics retirement; capabilities are migrating into Microsoft 365 Copilot.
### Learning and skills
- **Viva Learning** — central learning surface aggregating content from LinkedIn Learning, Microsoft Learn, Coursera, Pluralsight, internal SharePoint, and many other providers.
- **Viva Skills** — skills profile, recommendations, and matching.
### Goals and performance
- **Viva Goals** — OKR (Objectives and Key Results) management.
## How Viva is licensed
Viva is partially included with Microsoft 365 and partially sold as add-ons:
- **Microsoft 365 plans include**: Viva Connections, basic Viva Engage, basic Viva Insights, basic Viva Learning (limited content).
- **Viva Suite** — the bundled add-on, including the premium versions of Connections, Engage, Insights, Learning, Goals, and Glint.
- **Standalone modules** are sold for tenants that want only specific Viva products.
The licensing model has been adjusted several times; check the current Microsoft Viva pricing page when planning.
## Where Viva lives
Viva is **delivered through Teams** primarily. There's no separate "Viva" app for most users — Connections appears as a customised home in the Teams sidebar, Engage as a Teams app, Insights surfaces in Teams and Outlook, Learning in Teams.
For Viva Engage, the standalone web (`engage.cloud.microsoft`) and mobile apps also exist.
## Where to start
For organisations new to Viva, a sensible adoption sequence:
1. **Viva Connections** — replace the existing intranet experience with the personalised Teams home.
2. **Viva Engage** — if you're already on Yammer, it's already there.
3. **Viva Learning** — turn it on with whatever content licences you already have.
4. **Viva Insights** — encourage personal productivity insights at the user level first.
5. **Viva Goals** — pilot with one or two leadership teams; expand if it sticks.
Not every Viva module fits every organisation. Viva is a menu, not a mandate — pick the parts that solve real problems.
---
# Microsoft Whiteboard in meetings and beyond
URL: https://www.solvingmicrosoft365.com/guides/microsoft-whiteboard-in-meetings
Category: Viva & Apps
Published: 2026-05-01
> How Microsoft Whiteboard works in Teams meetings, where it stores content, and the practical patterns for collaborative work.
**Microsoft Whiteboard** is the digital whiteboard in Microsoft 365 — an infinite canvas for sketching, sticky notes, shapes, text, images, and templates with real-time co-editing across web, Windows, iOS, Android, and Surface Hub. It works as a standalone app and as the **whiteboard experience inside Teams meetings**.
The workshop-scale version is [Whiteboard for hybrid workshops](/guides/microsoft-whiteboard-hybrid-workshops); it lives inside [Teams meetings](/guides/microsoft-teams-meetings-best-practices), is stored in [OneDrive](/guides/what-is-onedrive), and competes with [Loop](/guides/microsoft-loop-explained) for lightweight collaboration.
## In a Teams meeting
Open the **Share** menu in a Teams meeting and choose **Microsoft Whiteboard**. Every participant gets a live canvas they can draw on simultaneously. Useful for:
- **Brainstorming** with sticky notes.
- **Workshop facilitation** with templates (retrospectives, design exercises, decision frameworks).
- **Visual collaboration** during a synchronous discussion.
- **Note-taking** that's more flexible than a shared document.
After the meeting, the whiteboard persists. Attendees can come back to it later, continue iterating, and reference it in subsequent meetings.
## Storage and governance
Whiteboards are stored in **OneDrive**:
- Whiteboards created in personal context live in the creator's OneDrive.
- Whiteboards created in a Teams meeting are stored in the meeting organiser's OneDrive.
- Whiteboards created in a channel meeting are stored in the channel's SharePoint site.
That means they inherit Microsoft 365 governance: **retention policies**, **sensitivity labels**, **eDiscovery**, **Purview audit logs**.
## What's in the toolset
- **Sticky notes** in multiple colours.
- **Pens** with pressure sensitivity (on touch devices).
- **Shapes** with snap-to-grid and connectors.
- **Text** with formatting.
- **Images** dragged in.
- **Reactions** for live feedback.
- **Templates** for retros, brainstorms, planning, design thinking.
- **AI features** — Copilot-assisted suggestion and summarisation (with Microsoft 365 Copilot licensing).
## Practical patterns
A few that work well in practice:
- **Async whiteboards** — start a board before a meeting, invite participants to add their notes ahead of time; review in the meeting.
- **Sprint retros** with a pre-loaded retro template (Liked, Learned, Lacked, Longed for).
- **Decision frameworks** — pre-load a 2×2 matrix or fishbone diagram, run the discussion live.
- **Visual planning** for projects with sticky notes that get moved between columns.
## Admin controls
Whiteboard is enabled per tenant in the **Microsoft 365 admin center**. Granular controls include:
- Whether Whiteboard is available at all.
- Whether anonymous meeting participants can use it.
- Whether external sharing of whiteboards is allowed.
- OneDrive storage location preferences.
For tenants new to Whiteboard, turning it on and providing a few starter templates is usually enough — adoption follows once one team uses it visibly.
## Whiteboard vs Loop — picking the right lightweight tool
Both Whiteboard and Loop aim at lightweight, in-the-moment collaboration, and it's a fair question which one a given session should use. **Whiteboard** is the better fit for genuinely visual, spatial thinking — sticky notes arranged freely, diagrams, sketches, anything where position on a canvas carries meaning. **Loop** is the better fit for structured, text-first collaborative content — a shared agenda, a running list of decisions, a table of action items — that needs to be referenced and edited as a document, not just visually arranged. A retrospective with movable sticky notes belongs on a Whiteboard; a shared meeting-notes-and-action-items page that multiple people edit inline belongs in Loop. Many organisations end up using both, reaching for whichever fits the specific artefact rather than standardising on one for everything.
## Frequently asked questions
**Can a whiteboard created during a meeting be shared with someone who wasn't in the meeting?** Yes — since it's a normal OneDrive- or SharePoint-stored file under the hood, it can be shared afterward like any other file, subject to the same sharing controls and any sensitivity label applied to it.
**Does Whiteboard support real-time co-editing at large scale, like a 50-person workshop?** It works, but usability degrades well before any hard technical limit — a canvas with dozens of people drawing simultaneously becomes visually chaotic and hard to facilitate; breaking a large session into smaller boards per breakout group, then consolidating afterward, is the more common pattern for genuinely large workshops.
---
# Migrating file shares to OneDrive and SharePoint
URL: https://www.solvingmicrosoft365.com/guides/migrating-file-shares-to-onedrive-and-sharepoint
Category: Migration & Tenants
Published: 2026-05-01
> A focused playbook for moving Windows file shares to OneDrive and SharePoint — tools, structure, and lessons.
Moving Windows file shares to **OneDrive** and **SharePoint** is the single most common Microsoft 365 migration project. The mechanics are well-understood, but getting the destination architecture right takes more thought than the migration itself.
## Where each kind of share goes
The mapping that works for most organisations:
- **Personal H: drives, "My Documents", user home folders** → **OneDrive** per user.
- **Department-wide shares** (HR, Finance, IT) → one **SharePoint team site per department**, with libraries for different content types. Site members are the department.
- **Project shares** → either a **Microsoft Teams team** (with channels per workstream) or a SharePoint project site, depending on how the team works.
- **Reference / read-only shares** (policies, templates) → a **communication site** with libraries.
- **Application data shares** — re-evaluate; many should stay on a file server or migrate to **Azure Files** instead. SharePoint isn't designed for application I/O patterns.
- **Build shares, source control shares** — definitely don't put in SharePoint.
Resist recreating file share structure 1:1. The cloud rewards **flatter structure with metadata** over **deep nested folders**.
## First-party tooling
Microsoft provides two free tools:
- **SharePoint Migration Tool (SPMT)** — Windows tool that you run on-prem to push files into SharePoint or OneDrive. Good for moderate volumes.
- **Migration Manager** — orchestrates SPMT agents across multiple servers from a single web UI in the SharePoint admin center. Right for larger projects.
Both handle Windows file shares, on-premises SharePoint, and (via Migration Manager) Google Drive and Box. Both preserve file metadata, version history (some flavours), and permissions where possible.
## Third-party tooling
For complex migrations (millions of files, mixed sources, custom mappings, hybrid environments) the established tools — **ShareGate**, **AvePoint Fly**, **Quest Migration Manager**, **Mover** (now part of Microsoft) — offer richer permissions handling, transformation, and reporting.
## Pre-migration
The boring-but-essential work before you migrate anything:
- **Inventory and triage**. How big is each share? When was it last accessed? Who owns it? A common finding: 30–50% of file shares haven't been touched in 5+ years.
- **Identify owners** for every destination site or OneDrive. Each destination needs an accountable owner.
- **Map permissions** to a clean target. NTFS permissions don't translate 1:1 to SharePoint; design the target permissions first.
- **Fix file issues**. Files with illegal characters, very long paths, or `$` system files need handling.
- **Communicate the timeline**. Users need to know what's moving, when, and what changes.
## During migration
A typical pattern:
1. **Initial bulk migration** to the destination (read content from source, write to OneDrive/SharePoint).
2. **Delta migration** of any newly added or modified files since the bulk run.
3. **Source goes read-only** at a defined cutover.
4. **Final delta** to catch the last changes.
5. **Source decommissioned** after a stabilisation period (typically 30 days).
For shares with active editing, this typically means an evening or weekend cutover with users out.
## After migration
- **Onboard users** — show them where their content is now, train them on co-authoring, OneDrive sync, Teams.
- **Roll out Known Folder Move** so users' Desktop/Documents/Pictures back up to OneDrive automatically.
- **Decommission the old shares** — leaving them online is the surest way to make sure people keep using them.
- **Capture lessons** for the next wave.
## Common pitfalls
- **Migrating before cleaning** — you carry junk forward.
- **Not designing target permissions** — re-shaped at the eleventh hour, badly.
- **Underestimating user training** — the file share habit is decades old.
- **Trying to preserve every file ever created** — old, stale content rarely earns its keep.
A successful migration replaces "where are the files?" with "the files are in the obvious place." That's the goal.
---
# Migrating from Google Workspace to Microsoft 365
URL: https://www.solvingmicrosoft365.com/guides/migrating-from-google-workspace-to-microsoft-365
Category: Migration & Tenants
Published: 2026-05-01
> A practical migration playbook for moving from Google Workspace to Microsoft 365 — workloads, tools, and pitfalls.
Moving from **Google Workspace** to **Microsoft 365** isn't a like-for-like swap — the products solve similar problems with different shapes. Done well, it's straightforward; done badly, it's a six-month tax on the IT team.
Before migrating, read [Microsoft 365 vs Google Workspace](/guides/microsoft-365-vs-google-workspace) for what changes; the target is described in [setting up Microsoft 365 from scratch](/guides/setting-up-microsoft-365-from-scratch), files follow [migrating file shares to OneDrive and SharePoint](/guides/migrating-file-shares-to-onedrive-and-sharepoint), and identity moves to [Entra ID](/guides/what-is-microsoft-entra-id).
## What needs to migrate
A typical scope:
- **Identities** — Google users → Entra ID accounts.
- **Email** — Gmail mailboxes → Exchange Online.
- **Calendars** — Google Calendar → Exchange Online calendars.
- **Contacts** — Google Contacts → Outlook contacts.
- **Files** — Google Drive (personal) → OneDrive; Shared Drives → SharePoint.
- **Documents** — Google Docs/Sheets/Slides → Word/Excel/PowerPoint (conversion happens automatically; formatting often needs touch-up).
- **Sites** — Google Sites → SharePoint communication / team sites.
- **Groups** — Google Groups → Microsoft 365 Groups or distribution lists.
- **Chat** — Google Chat history → typically *not* migrated (too different).
- **Meet recordings** → OneDrive / SharePoint.
- **Forms** → Microsoft Forms.
- **Email domain cutover** — the big day.
## Migration tools
Microsoft ships first-party tools that cover the bulk of the scope:
- **Exchange admin center → Migration** for Gmail (IMAP-based migration with OAuth).
- **Microsoft 365 Migration Manager** for files, with cloud-to-cloud Google Drive support.
- **Migration Manager** also handles SharePoint sites from Google Sites in limited cases.
Third-party tools cover gaps and add concurrency:
- **Quest On Demand**, **BitTitan MigrationWiz**, **CodeTwo**, **AvePoint Fly** all support full Google → Microsoft migrations.
- For mid-to-large estates, a third-party tool plus a partner is the typical approach.
## A realistic playbook
A migration of a couple hundred users typically runs:
### Phase 1 — Plan (2–4 weeks)
- Inventory Google estate — users, files, sites, groups, custom apps.
- Decide on **identity strategy** — fresh Entra ID accounts, or sync existing AD.
- Decide on **co-existence period** — usually 1–4 weeks where both systems run in parallel.
- Set up Microsoft 365 tenant, domain, basic baseline.
### Phase 2 — Prepare (1–2 weeks)
- Provision Entra ID users.
- Buy and assign Microsoft 365 licences.
- Configure DNS for co-existence (split routing so mail still flows to Gmail until cutover).
- Pilot migration with 5–10 users; iterate on issues.
### Phase 3 — Migrate (2–8 weeks depending on size)
- Migrate user data in waves — typically by department or geography.
- Provide users with **Outlook, Teams, OneDrive** training during their wave.
- Run a **secondary sync** before final cutover to catch new content.
### Phase 4 — Cutover (1 day)
- Update DNS MX records to point to Exchange Online.
- Run a final delta migration.
- Disable Google email forwarding.
- Validate mail flow.
### Phase 5 — Stabilise (2–4 weeks)
- Help-desk surge for adoption questions.
- Track migration completeness via reports.
- Hold Google Workspace open in read-only for 30 days for missed content.
## Common pitfalls
- **Shared drives** with complex permissions translate roughly into SharePoint. Plan permissions before migration, not after.
- **Google Docs formatting** doesn't survive conversion intact — heavy users feel this.
- **Google-specific integrations** (Apps Script, native Google add-ons) don't have direct Microsoft equivalents.
- **Calendar invite cutover** — meetings scheduled before cutover need handling so they don't lose responses.
- **User training** is usually the biggest underestimate. Plan for it.
## Why people migrate
The usual drivers:
- **Security and compliance** consolidation (Defender, Purview, Conditional Access).
- **Identity and device management** unification with Windows estate.
- **Existing Microsoft enterprise relationship** — EA, Azure, Dynamics.
- **Specific app needs** that Microsoft does better (Excel, deeper Office desktop tools).
When the move makes sense for those reasons, the migration mechanics are well-trodden — it's a project, not an experiment.
---
# Migrating from on-premises Exchange to Microsoft 365
URL: https://www.solvingmicrosoft365.com/guides/migrating-from-on-premises-exchange-to-microsoft-365
Category: Migration & Tenants
Published: 2026-05-01
> How to move mailboxes from Exchange Server to Exchange Online — the migration types, hybrid deployment, and the realistic plan.
Moving from **Exchange Server** (on-premises) to **Exchange Online** is one of the most common Microsoft 365 migrations. The mechanics are mature, but the right approach depends on size, version, and how long you'll coexist.
The hybrid configuration itself is in [Exchange hybrid deployment](/guides/exchange-hybrid-deployment); what comes after is [retiring the last Exchange server](/guides/exchange-hybrid-decommission-last-exchange-server), the identity side is [hybrid identity strategy](/guides/hybrid-identity-strategy), and the domain and mail-authentication work follows [adding a domain without downtime](/guides/exchange-online-add-domain-without-downtime).
## The four main migration types
### 1. Cutover migration
For tenants with **fewer than ~150 mailboxes** on Exchange 2003–2019. All mailboxes move at once, no coexistence, simple to plan and execute.
- Microsoft moves all mailboxes via Outlook Anywhere over a few days.
- Users get a brand-new Microsoft 365 account on cutover day.
- No directory sync; user accounts are fresh in Entra ID.
- Simple, fast, but disruptive on the cutover day.
### 2. Staged migration
For **larger Exchange 2003 / 2007 organisations** (legacy versions). Migrate mailboxes in batches with cross-premises coexistence. Increasingly rare as these versions are long out of support.
### 3. Hybrid migration
The **modern enterprise default**. Set up an **Exchange hybrid deployment** (covered in its own guide), then move mailboxes in waves over weeks or months while users keep working. The recommended path for organisations with 150+ mailboxes or Exchange 2010+.
- **Free/busy** works across on-prem and cloud during coexistence.
- **Mailbox moves** are seamless from the user's perspective.
- **Email flow** continues to work through the hybrid namespace.
- Move at your own pace; pause if needed; reverse if necessary.
### 4. PST import / IMAP migration
For unusual cases — third-party mail systems, departed users, archived content. Move data via PST files or IMAP rather than direct mailbox move. Slower and less complete, but flexible.
## What needs to happen
Regardless of migration type, the typical steps:
1. **Plan and licence**. Buy Microsoft 365 licences. Decide on identity model (cloud-only, hybrid).
2. **Set up identity sync**. Install Entra Connect or Cloud Sync, sync users.
3. **Set up hybrid** (for hybrid migration). Run the Hybrid Configuration Wizard.
4. **Configure DNS** for hybrid mail flow if relevant.
5. **Pilot migration**. Move IT mailboxes first; verify everything works.
6. **Wave migration**. Migrate users in batches (typically 50–200 per wave).
7. **Update DNS** — final MX cutover at the right point.
8. **Decommission on-premises Exchange** (mostly).
## Co-existence period
During hybrid migration, both Exchange Online and Exchange Server are live. Mail flows between them transparently. Users in the cloud calendar correctly with users on-prem. The co-existence can last weeks or months.
This is the period when most operational complexity lives. Plan for:
- A help desk that supports both clients.
- Documentation for both worlds.
- Migration-status dashboards.
- Communication to users at their wave.
## Decommissioning on-premises Exchange
After all mailboxes are in Exchange Online, the on-premises Exchange Servers can be **mostly decommissioned**. Microsoft historically required keeping at least one Exchange server for managing mail-attribute objects on AD-synced accounts. The newer **Exchange Server SE Management Tools** and growing Entra ID support for managing recipient attributes have eased this — full on-prem-Exchange-free is increasingly viable.
## Common pitfalls
- **Public folders** are a pain. Plan their migration carefully or migrate to Microsoft 365 Groups.
- **Mailbox quotas** in Microsoft 365 differ from on-prem; very large mailboxes (>50GB) need archive policies.
- **Outlook profile reconfiguration** at cutover — Autodiscover handles most, but plan for help-desk volume.
- **OWA URL changes** — communicate the new URL.
- **Mobile devices** need to re-authenticate; Exchange ActiveSync clients can be quirky.
For most organisations, a hybrid migration over 2–6 months is the right answer. The work is well-understood, the tooling is mature, and the destination is meaningfully better than running your own mail.
---
# Multi-language Microsoft 365 tenant setup
URL: https://www.solvingmicrosoft365.com/guides/multi-language-tenant-setup
Category: Migration & Tenants
Published: 2026-05-01
> How to support multiple languages across a Microsoft 365 tenant — UI, content, communications, and accessibility.
For multinational organisations, supporting employees in multiple languages affects every Microsoft 365 surface. The default English-only experience excludes non-English speakers; thoughtful multi-language setup makes the tenant genuinely usable for everyone.
Language settings span [SharePoint multilingual sites](/guides/sharepoint-multilingual-sites), [Teams live captions and translation](/guides/teams-live-captions-and-translation), [Copilot translation in PowerPoint](/guides/copilot-in-powerpoint-speaker-notes-and-translation), and the regional shape decided in [Multi-Geo](/guides/microsoft-365-multi-geo).
## Microsoft 365 user-language settings
Each user has a **preferred display language** affecting the UI of Microsoft 365 apps:
- **Set in Microsoft 365 Settings** — `myaccount.microsoft.com → Language preferences`.
- **Or via Entra ID** as a user attribute — `preferredLanguage`.
- **Synced from HR** if available — language follows the user automatically.
Languages supported include 60+ — most major European, Asian, and other languages with active Microsoft localisation.
## Outlook / mail
User-language preferences affect:
- **Outlook UI language**.
- **System-generated emails** (welcome, password reset, etc.) — sent in the user's preferred language where supported.
- **Microsoft 365 admin centre branding** for the user.
For organisational emails — internal newsletters, leadership communications, etc. — language is the **sender's choice**; multi-lingual orgs typically send the same content multiple times in different languages or use machine translation.
## Teams
Teams UI follows user preference. Specific scenarios:
- **Meeting captions** — live captions available in many languages.
- **Live translation** in meetings (Teams Premium) — translated captions per attendee.
- **Translator for messages** — translate chat messages on demand.
- **Walkie Talkie** is voice-based; language is the speaker's.
## SharePoint multilingual sites
Sites can have **multiple language variants** with translated pages:
- **Primary language** of the site.
- **Alternative languages** enabled per site.
- **Per-page translations** — each page authored separately.
- **Navigation translations** at hub and site levels.
Configure per site in **Site information → Language settings**. AI-translation drafts (via Microsoft Translator integration) provide starting points; humans refine.
For tenant-wide intranet, multilingual hub sites are how a multinational organisation delivers a consistent intranet experience across languages.
## Office app language packs
For installable Office apps, language packs are configured via Office Deployment Tool:
```xml
```
Users get all configured languages installed; their preferred language is determined by Windows / system settings.
## Forms and surveys
**Microsoft Forms** doesn't natively support multilingual forms, but workarounds exist:
- Build separate forms per language.
- Use response-based branching for language selection at the start.
- Use Power Automate to route by language.
**Viva Glint** and other engagement-survey tools have proper multilingual support built in.
## Internal communications
For multinational employee communications:
- **Viva Connections** can be multilingual via the underlying SharePoint home site.
- **Viva Engage** community posts are typically in the community's primary language; users translate via Translator.
- **Email blasts** to multilingual audiences typically have multiple language versions.
## Compliance and legal
Some considerations specific to regulated multinationals:
- **Privacy notices** must be in users' languages — GDPR / similar regulations.
- **Terms of use** documents (configurable in Entra ID Conditional Access) must be available in users' languages.
- **Mandatory training** — multilingual training content for compliance scenarios.
## Practical setup
For a multinational organisation:
1. **Survey languages** actually spoken across the workforce. Often 80% of users use 3–5 languages.
2. **Set Entra ID `preferredLanguage`** for every user, synced from HR.
3. **Test the experience** — sign in as users in different languages, verify UI translates correctly.
4. **Deploy multilingual Office** via ODT or Intune.
5. **Set up multilingual intranet** for top languages.
6. **Translate mandatory documents** — privacy notices, terms of use, key training.
7. **Train internal communicators** to author in the right language for the audience.
## Operational considerations
- **AI translation isn't perfect** — review translations especially for legally-significant content.
- **Cultural adaptation** matters beyond translation — localisation, not just translation.
- **Time zones** matter alongside language — meeting scheduling, communications, etc.
- **Accessibility** in different languages — screen readers, captions, font support.
For multinational tenants serious about employee experience, multilingual setup is one of those investments that's invisible when done well and obviously broken when not. The work is moderate; the payoff is durable.
---
# Office 365 Message Encryption deep dive
URL: https://www.solvingmicrosoft365.com/guides/office-365-message-encryption-deep-dive
Category: Exchange & Outlook
Published: 2026-05-01
> How OME works under the hood — encryption flow, branding, custom templates, and the recipient experience.
**Office 365 Message Encryption (OME)** is Microsoft's email encryption service. Beyond the basic "click Protect to encrypt," knowing how it works enables advanced configurations for branding, custom templates, and specific recipient experiences.
The overview is [Office 365 Message Encryption](/guides/office-365-message-encryption); the label-driven approach is in [sensitivity labels](/guides/purview-sensitivity-labels-deep-dive), and the key-control options beyond OME are [Customer Key](/guides/customer-key-for-microsoft-365) and [Customer Lockbox](/guides/customer-lockbox-deep-dive).
## The encryption flow
When a user encrypts a message:
1. Sender composes email in Outlook (desktop, web, or mobile).
2. Sender applies encryption via **Protect button** or **sensitivity label** with encryption enabled.
3. Outlook encrypts the message body and attachments using **Azure Information Protection / Microsoft Purview Information Protection** under the hood.
4. The encrypted message is sent via standard Exchange Online mail flow.
5. Delivery happens normally.
For **recipients in the same Microsoft 365 tenant**: their Outlook decrypts transparently — no portal, no friction.
For **recipients in different Microsoft 365 tenants**: same — federated trust between tenants enables transparent decryption.
For **external recipients (Gmail, etc.)**: the encrypted message arrives with a link to the **OME portal** at `outlook.office365.com/encryption`. The recipient:
1. Clicks the link.
2. **Signs in** using their own Microsoft account, Google account, or **one-time passcode** sent to their email.
3. Views the message in the secure portal.
4. Can reply through the portal (with their reply also encrypted).
## Available protections
OME supports multiple protection levels:
- **Encrypt** — encryption only; recipient can forward (though forwarded copies are still encrypted).
- **Do Not Forward** — encryption plus the recipient can't forward, copy, or print.
- **Confidential** — admin-configured template with corporate-specific restrictions.
- **Highly Confidential** — stricter admin template.
- **Custom templates** — admin-defined for specific business scenarios.
## Branding the OME portal
For external recipients, the OME portal is **brandable**:
- **Logo** at the top.
- **Background image** for the portal page.
- **Sender name and corporate identity**.
- **Disclaimer text**.
- **Custom email body** for the notification email.
Configured via **Exchange Online PowerShell**:
```powershell
Set-OMEConfiguration -Identity "OME Configuration" `
-EmailText "Encrypted message from Contoso" `
-PortalText "Contoso secure messages" `
-DisclaimerText "This message is confidential..." `
-OTPEnabled $true `
-SocialIdSignIn $true `
-BackgroundColor "#003366"
```
For consistent corporate experience, configure branding before deploying OME tenant-wide.
## Custom templates
Beyond the built-in templates, **custom templates** allow specific business scenarios:
```powershell
New-RMSTemplate -Name "Legal Privilege" `
-DepartmentName "Legal" `
-RightsDefinitions @(
New-Object Microsoft.Online.Administration.RightsDefinition `
-Property @{
EmailAddress = "everyone@contoso.com"
Rights = "VIEW","REPLY","REPLYALL","EDIT","EXPORT","EXTRACT","FORWARD"
}
)
```
Custom templates appear in the sender's encryption-options dropdown.
## Sensitivity-label integration
The modern pattern: configure OME via **sensitivity labels** rather than templates directly:
- Create a sensitivity label "Confidential — External."
- Configure encryption with appropriate permissions.
- Apply via Office apps Protect menu or auto-apply policy.
When a user applies the label, OME encryption applies automatically. The label is the user-facing concept; OME is the underlying mechanism.
## Auto-encryption via transport rules
For consistent enforcement, **Exchange transport rules** can auto-apply OME:
- **Condition**: outbound message contains "Credit Card" sensitive information type AND recipient is external.
- **Action**: apply OME with "Encrypt-Only" template.
The user doesn't need to remember to encrypt — the tenant ensures it for matching content.
## Operational considerations
- **Test recipient experience** with users on Gmail, Apple Mail, Yahoo — verify the portal flow works.
- **Communicate the experience** to senders so they understand what recipients will see.
- **One-time passcode (OTP)** is the most universal recipient auth — enable it.
- **Audit OME usage** — Purview audit logs show every encryption event.
- **Mobile experience** — verify OME works for recipients on iOS and Android Outlook.
## Limitations
- **Encrypted attachments** the recipient downloads may be inaccessible outside the portal — depends on the protection template.
- **Forwarding** by recipients works (within encryption restrictions) but second-recipient sees the same OME portal experience.
- **PGP / S/MIME** are separate encryption mechanisms — OME doesn't interoperate with them.
For organisations needing to send encrypted email externally — financial services, healthcare, legal, regulated communications — OME is the right Microsoft-native solution. The setup is moderate; the user experience is reasonable; the audit trail is solid.
---
# Office 365 Message Encryption
URL: https://www.solvingmicrosoft365.com/guides/office-365-message-encryption
Category: Exchange & Outlook
Published: 2026-05-01
> OME is Microsoft's email encryption service — what it does, how to enable it, and what it looks like for recipients.
**Office 365 Message Encryption (OME)** is Microsoft's email encryption service for protecting messages and attachments in transit and at rest, including to recipients outside your organisation. It's used most commonly to send sensitive content (financial data, PII, contracts) to external parties without resorting to encrypted file attachments or third-party tools.
The deeper treatment is [Office 365 Message Encryption deep dive](/guides/office-365-message-encryption-deep-dive); OME is applied through [sensitivity labels](/guides/purview-sensitivity-labels-deep-dive) or [transport rules](/guides/transport-rule-examples), and sits alongside [DLP](/guides/purview-data-loss-prevention-deep-dive) in the outbound-mail controls.
## How OME works
When a user encrypts a message:
1. The sender composes mail in Outlook and applies **encryption** via the **Protect** button or **sensitivity label**.
2. Microsoft encrypts the message body and attachments using **Microsoft Azure Information Protection**.
3. The encrypted message is delivered through normal Exchange mail flow.
4. **Internal recipients** in the same Microsoft 365 tenant (or federated tenant) see the message decrypted automatically in Outlook.
5. **External recipients** receive a message with a link to a **secure web portal** where they can authenticate (Microsoft account, Google, OTP) and read the message.
For Microsoft 365 recipients in any tenant, the decryption is invisible — the message just opens. For others, the portal experience handles authentication.
## Sender-side controls
Senders can apply OME in several ways:
- **Encrypt** — basic encryption that recipients can decrypt and forward.
- **Do Not Forward** — encryption plus recipient-only restriction; no forwarding, no copy, no print.
- **Encrypt-Only**, **Confidential**, **Highly Confidential** — sensitivity-label-driven templates configured by admins.
Sensitivity labels with encryption are the modern way — sender just picks the right label and OME applies automatically.
## Admin-applied OME via transport rules
For consistent enforcement, admins set up **transport rules** that automatically encrypt messages matching conditions:
- "If outbound message contains PCI data, encrypt with Do Not Forward."
- "If subject contains [CONFIDENTIAL], encrypt."
- "If recipient is on this list, encrypt outbound."
This catches users who forget to apply protection manually.
## What recipients see
External recipients receive an email with a link to the secure portal:
- They click the link, choose how to authenticate (use a Microsoft 365 account, Google account, or a one-time passcode).
- After authenticating, the portal shows the message and attachments.
- Replies and forwards (if allowed) happen through the portal — they don't go back through the recipient's email client.
It's a different experience from regular email, which sometimes generates support questions. Communicate to senders that recipients may need extra clicks.
## Branding
OME supports **custom branding** — your organisation's logo and colours in the portal, customised wording in the notification email. Set up in the Microsoft 365 admin center.
## Licensing
OME is included with **Microsoft 365 E3, E5, Business Premium**, **Microsoft 365 Apps for Enterprise**, and **Office 365 E3 / E5**. Recipients don't need any Microsoft licence — the portal handles them with whatever they have.
## When OME is the right tool
- **Sending sensitive content externally** — to partners, customers, regulators, advisors.
- **Compliance-driven encryption** — DLP-triggered automatic encryption for regulated data.
- **Replacing third-party encrypted-email gateways** — Mimecast Secure Messaging, Cisco Email Encryption.
For internal-only sensitive content, sensitivity labels with **Encrypt-Only** are usually enough without going through OME's external-recipient flow.
---
# Office add-ins development overview
URL: https://www.solvingmicrosoft365.com/guides/office-add-ins-development
Category: Developer & APIs
Published: 2026-05-01
> The modern Office add-in model — web-based extensions for Word, Excel, PowerPoint, Outlook running across platforms.
The modern **Office add-in model** lets developers build extensions for Word, Excel, PowerPoint, Outlook, and OneNote using **web technologies** — HTML, JavaScript, CSS — running inside the Office apps across Windows, Mac, web, iOS, and Android. It replaces the legacy COM-based add-ins (`.NET`, `VBA`, VSTO) which only worked on Windows desktop.
Add-ins are the pro-code extension model for the [Microsoft 365 Apps](/guides/intune-app-deployment-for-microsoft-365-apps), deployed centrally from the [admin center](/guides/microsoft-365-admin-center), authenticating via [Entra app registrations](/guides/entra-id-app-registrations-and-enterprise-apps) to the [Graph API](/guides/microsoft-graph-api-basics); [Office Scripts](/guides/office-scripts-in-excel) is the lighter alternative in Excel.
## The model
An Office add-in is fundamentally a **web app** that runs in a sandboxed iframe inside the Office app:
- **HTML / CSS / JS** code, hosted on any web server.
- **A manifest file** (XML, or newer JSON for the unified manifest) that describes the add-in — what app it extends, what features it adds, what permissions it needs.
- **The Office.js JavaScript library** for accessing the host app's API — reading and writing document content, listening to events, manipulating UI.
When a user installs the add-in, the manifest is registered; the add-in surfaces as a button or pane in the Office app; clicking loads the web app inside the iframe.
## What add-ins can do
Depending on the host app:
### Word add-ins
- Insert formatted content into the document.
- Read existing document content and structure.
- Bind to specific content controls.
- React to selection changes.
- Custom task panes alongside the document.
### Excel add-ins
- Read and write cell ranges, tables, charts.
- Add custom functions (similar to user-defined functions but in JavaScript).
- Bind to specific data ranges for streaming updates.
- Custom task panes for analysis tools.
### PowerPoint add-ins
- Insert content (shapes, images, slides).
- Read slide content.
- Bind to specific slides or shapes.
### Outlook add-ins
- React to email selection (read pane add-ins).
- React to compose events (compose pane add-ins).
- Add custom commands in the ribbon.
- Pull data from external systems and present in the read pane.
## Distribution
Add-ins can be distributed via:
- **The Office Store / AppSource** — public marketplace.
- **Microsoft 365 admin center** — sideload corporate-built add-ins to your tenant's users (similar to Teams app deployment).
- **SharePoint app catalog** — older but still supported for some scenarios.
- **Microsoft Teams app deployment** — the unified-manifest model lets add-ins ship as Teams apps that also work in Office, OS, and the web.
## When add-ins are the right tool
- **Embed a line-of-business tool** inside Office workflows — surface a CRM, a ticketing system, a translation tool, a citation manager.
- **Provide custom Excel functions** for specialised industry calculations.
- **Integrate a SaaS app** into Outlook to enable sending or acting on data without leaving email.
## When something else is better
- **Server-side processing of Office files** — use Graph instead of add-ins.
- **Document automation at scale** — use Power Automate or Graph.
- **Bulk-create Office documents** — use server-side approaches (OpenXML libraries) rather than add-ins.
## Tooling
- **Yeoman generator for Office** — scaffolds a new add-in project.
- **Office Toolkit** in Visual Studio Code — debugging and development helpers.
- **Office.js library** — the JavaScript API.
- **Microsoft Teams Toolkit** — for the unified app model spanning Teams and Office.
## What's coming
The strategic direction is the **unified app model**: one manifest, one codebase, deployed once, runs in Teams, Outlook, Word, Excel, PowerPoint, and Microsoft 365 Copilot. Microsoft has been progressively converging the previously separate Teams and Office app extensibility models. New add-in projects in 2026 should target this model.
For developers building line-of-business extensions to Office, add-ins are the modern path. They replace the brittle COM model with a cross-platform web-based approach that's far easier to operate.
---
# The Office Deployment Tool deep dive
URL: https://www.solvingmicrosoft365.com/guides/office-deployment-tool-deep-dive
Category: Microsoft Intune (Devices)
Published: 2026-05-01
> How to use the Office Deployment Tool (ODT) for granular Microsoft 365 Apps deployment.
The **Office Deployment Tool (ODT)** is Microsoft's command-line tool for granular control over **Microsoft 365 Apps installation** — what apps, what languages, what architecture, what update channel, with custom shortcuts and behaviour. For most Intune-managed estates, ODT runs under the covers; for traditional deployments, custom installers, or specific requirements, you drive ODT directly.
The ODT underlies [Intune app deployment for Microsoft 365 Apps](/guides/intune-app-deployment-for-microsoft-365-apps) and defines the [update channel](/guides/microsoft-365-deployment-rings-and-release-channels); settings after install are [Cloud Policy](/guides/microsoft-365-cloud-policy-service), and activation problems are in [activation troubleshooting](/guides/microsoft-365-apps-activation-troubleshooting).
## The XML configuration file
ODT is driven by an **XML configuration file**:
```xml
```
This describes a specific install: 64-bit Monthly Enterprise Channel, Microsoft 365 Apps for Enterprise plus Visio Pro, English (US and UK), excluding the deprecated Groove, OneDrive, and Lync (Skype for Business) sub-products.
## The Office Customization Tool
For the XML, **don't write it by hand** — use the **Office Customization Tool** at `config.office.com`. The GUI lets you pick:
- Which Microsoft 365 product and Visio / Project add-ons.
- Architecture (32 or 64 bit).
- Update channel.
- Apps to include / exclude.
- Languages and proofing tools.
- Display behaviour (silent or interactive install).
- Activation behaviour.
- Shared Computer Activation (for VDI).
- Custom installation properties.
Then export the XML. Use that with ODT.
## Running ODT
ODT itself is a small executable (`setup.exe`) you download from the Microsoft Download Center. Used with the XML:
```cmd
:: Download the installation files
setup.exe /download configuration.xml
:: Install Office using the downloaded files
setup.exe /configure configuration.xml
:: Uninstall existing Office
setup.exe /configure uninstall.xml
```
## Common scenarios
### Install Microsoft 365 Apps with Visio
XML specifying both products. Useful for users who need Visio on top of standard Office.
### Install for VDI / Cloud PC
Set `SharedComputerLicensing = 1` so Office activates per-session rather than per-device.
### Channel-pinning specific users
Pin a small population to the **Current Channel (Preview)** for early testing; everyone else on Monthly Enterprise Channel. Achieved via separate ODT configurations targeting different user groups.
### Architecture migration (32 to 64 bit)
Migrate from 32-bit Office to 64-bit on a managed fleet. Requires uninstall, then reinstall with the new architecture. ODT scripts handle both steps cleanly.
### Removing pre-existing classic Office
`` removes any legacy MSI-based Office installation before installing Microsoft 365 Apps. Essential for migrating users on older Office versions.
## ODT vs Intune deployment
For Intune-managed estates, the **Microsoft 365 Apps for Windows** app type in Intune wraps ODT internally — you configure via Intune's UI (same options as the Office Customization Tool), Intune generates the XML and runs ODT under the hood.
When to drive ODT directly:
- **Configuration Manager (SCCM) deployments** — ODT used in task sequences.
- **Custom installer packages** — chocolatey-style packages or PSADT.
- **Specific customisations** Intune's UI doesn't expose.
- **Offline / air-gapped scenarios** — download via ODT, deploy from local share.
## Operational considerations
- **Test in a controlled environment** before mass deployment.
- **Document the XML configuration** — undocumented Office configurations are confusing for future admins.
- **Source files** — for offline scenarios, manage where the source `.cab` and `.dat` files live.
- **Update Office Customization Tool exports** as Microsoft adds new options.
- **Update Channel migration** — moving users between channels has specific procedures.
For Microsoft 365 customers with anything beyond standard Intune-driven deployment, ODT is essential tooling. The XML format, while verbose, gives complete control over Microsoft 365 Apps installation behaviour.
---
# Office Scripts in Excel
URL: https://www.solvingmicrosoft365.com/guides/office-scripts-in-excel
Category: Microsoft Intune (Devices)
Published: 2026-05-01
> Office Scripts is Microsoft's modern automation language for Excel — what it does, where it runs, and how it compares to VBA.
**Office Scripts** is Microsoft's modern automation language for Excel — TypeScript-based, web-first, and integrated with Power Automate. It's the cloud-era replacement for the long-running but Windows-only **VBA macros**, and it's where Microsoft is investing for Excel automation.
Office Scripts are the automation layer [Copilot in Excel](/guides/copilot-in-excel) can generate, run from [Power Automate](/guides/what-is-power-automate), and sit between [Power Query](/guides/power-query-primer) for data shaping and [Office add-ins](/guides/office-add-ins-development) for full solutions.
## What Office Scripts can do
Inside Excel on the web (and increasingly on Windows / Mac):
- **Record and replay actions** — like macros, but in TypeScript that's editable and shareable.
- **Automate workbook tasks** — formatting, formulas, chart creation, table operations, sorting, filtering.
- **Parameterise scripts** — define parameters so a script accepts inputs at run time.
- **Call scripts from Power Automate flows** — trigger script execution as part of a larger workflow.
Scripts run in the cloud against the workbook's cloud copy. No installation, no local execution context.
## The language
Office Scripts uses a small TypeScript subset with a specific Excel object model:
```typescript
function main(workbook: ExcelScript.Workbook) {
const sheet = workbook.getActiveWorksheet();
const range = sheet.getRange("A1:C10");
range.setValues([
["Name", "Score", "Status"],
// ...
]);
}
```
The object model — `Workbook`, `Worksheet`, `Range`, `Table`, `Chart` — is similar in concept to VBA's but rebuilt for the web. The TypeScript editor in Excel for the web provides IntelliSense.
## Compared to VBA
| Aspect | VBA | Office Scripts |
| --- | --- | --- |
| Runs in | Windows desktop Excel | Excel web (and increasingly desktop) |
| Language | Visual Basic | TypeScript |
| File location | Embedded in `.xlsm` | Stored in the user's OneDrive |
| Sharing | Email the file | Share scripts independently |
| Distribution | Local install | Tenant-wide via admin |
| Power Automate integration | Limited | Native |
| Best for | Legacy automation, complex desktop scenarios | New automation, multi-user scenarios, Power Automate flows |
VBA isn't going away in the near term, but new Excel automation should start in Office Scripts.
## Power Automate integration
The most powerful pattern is **flow + script**:
- A scheduled Power Automate flow opens a workbook in OneDrive or SharePoint.
- The flow calls an Office Script that pulls fresh data, formats a report, generates charts.
- The flow emails the workbook to stakeholders or posts it to Teams.
This replaces a lot of the "Excel as a reporting engine" patterns that previously needed a desktop bot.
## Admin and governance
Office Scripts is enabled per tenant in the **Microsoft 365 admin center**. Tenant admins can scope script creation to specific users (typically a "scripters" group), control script sharing, and audit script execution via Purview audit logs.
For organisations using Excel as a workflow tool — finance, operations, supply chain — Office Scripts is the single most valuable new Excel feature in years.
---
# OneDrive for Business vs OneDrive (personal)
URL: https://www.solvingmicrosoft365.com/guides/onedrive-for-business-vs-personal
Category: SharePoint & OneDrive
Published: 2026-05-01
> Two products, one name — the differences between work and consumer OneDrive, and why mixing them is a bad idea.
Microsoft calls two distinct products "OneDrive." They share a name, a logo, and an app, but they're separate services with separate identity systems, capacity, and admin controls. Mixing them is one of the most common sources of confusion in Microsoft 365.
## OneDrive for Business
**OneDrive for Business** is the cloud storage that comes with every Microsoft 365 work or school account. It:
- Belongs to your **organisation's tenant**.
- Authenticates with your **Entra ID** account.
- Is governed by your IT (sharing policies, retention, sensitivity labels, Conditional Access).
- Typically provides **1 TB or more per user** (up to 5 TB or unlimited on higher plans).
- Is built on **SharePoint Online** under the hood.
This is the version you should use for work content.
## OneDrive (personal)
**OneDrive (personal)** is a consumer cloud service that comes with personal **Microsoft accounts**. It:
- Belongs to the **individual**, not an organisation.
- Authenticates with a personal **Microsoft account** (`outlook.com`, `hotmail.com`, `live.com`, or a personal email used as an MSA).
- Has consumer-grade capacity (5 GB free, 100 GB / 1 TB with Microsoft 365 Personal/Family).
- Has separate sharing, security, and admin model.
This is appropriate for personal files at home.
## How they show up on a device
On Windows, the OneDrive client supports **multiple accounts simultaneously** — one work account and one personal account at the same time, each with its own sync folder. They appear in Explorer as separate top-level items. Mobile apps similarly handle both. macOS works the same way.
Visually they look identical. Reading the address bar or the OneDrive icon's tooltip is how you tell them apart.
## Why mixing is risky
- **Data leakage**: dropping a confidential work file into personal OneDrive bypasses every governance control.
- **Compliance**: eDiscovery, retention, and DLP policies don't apply to personal OneDrive.
- **Continuity**: if someone leaves, work content in personal OneDrive isn't recoverable by IT.
- **Licensing**: personal accounts aren't licensed to host work data.
Most organisations either **block the personal OneDrive client** with Conditional Access for unmanaged storage, or block it at the network edge via Defender for Cloud Apps. Make it a deliberate decision.
| | OneDrive for Business | OneDrive (personal) |
| --- | --- | --- |
| Identity | Entra ID (work account) | Microsoft account (MSA) |
| Underlying platform | SharePoint Online | Consumer storage backend |
| Typical capacity | 1 TB+ per user | 5 GB free, up to 1 TB paid |
| Admin visibility | Full (retention, DLP, eDiscovery, Conditional Access) | None |
| Who owns the data | The organisation's tenant | The individual |
| Recoverable after offboarding | Yes, via IT | No |
## Frequently asked questions
**Can IT see or manage a personal OneDrive account?** No — a personal Microsoft account and its OneDrive sit entirely outside the tenant's admin boundary; the organisation has no visibility, no retention control, and no way to recover content from it even if an employee used it for work files.
**What happens if an employee syncs both accounts on a company laptop?** Both appear as separate folders in File Explorer or Finder, and it's easy to drag a file into the wrong one without noticing — which is precisely the scenario that motivates blocking the personal client, or at minimum training staff to check the account label before saving anything sensitive.
**Does Known Folder Move affect personal OneDrive?** No — Known Folder Move redirects Desktop, Documents, and Pictures specifically to the work OneDrive for Business account; it has no equivalent behaviour for a personal account, which is one more reason the two shouldn't be treated as interchangeable on a managed device.
**Is there a way to let staff use personal OneDrive for genuinely personal files on a company laptop without risking work data ending up there?** Some organisations accept this trade-off deliberately rather than blocking the personal client outright — the safer version pairs it with Endpoint DLP policies that flag or block copying sensitivity-labelled files into any location outside the managed OneDrive account, so the personal account remains usable for non-work content while labelled work content specifically is stopped regardless of which OneDrive instance it's dragged toward.
---
# OneDrive Known Folder Move
URL: https://www.solvingmicrosoft365.com/guides/onedrive-known-folder-move
Category: SharePoint & OneDrive
Published: 2026-05-01
> Known Folder Move redirects Desktop, Documents, and Pictures into OneDrive, so user files are backed up by default.
**Known Folder Move (KFM)** is the OneDrive feature that redirects a user's **Desktop**, **Documents**, and **Pictures** folders into their OneDrive. Once it's on, those folders sync to the cloud — so files are backed up, available on other devices, and not stranded on a single laptop.
## Why it's important
Many users never think about where they save files. Without KFM, files end up scattered across `C:\Users\` folders, USB sticks, and old laptops. With KFM, the default Save dialog still points to "Documents" — but those documents are now syncing to OneDrive automatically.
The practical benefits:
- **Device loss protection**: a wiped or stolen laptop loses nothing of value.
- **Device migration**: signing in on a new laptop pulls everything back.
- **Multi-device experience**: same files on home and work machines, on iPad, on phone.
- **Backup story**: files are recoverable from OneDrive's version history and recycle bin.
## How to deploy it
KFM is configured via policy, either Group Policy (`OneDrive.admx`) or **Intune** configuration profiles. The relevant settings:
- **Silently move Windows known folders to OneDrive** — moves Desktop, Documents, Pictures on first sign-in without user prompts.
- **Prompt users to move Windows known folders to OneDrive** — surfaces a one-click prompt.
- **Prevent users from redirecting their known folders to their PC** — locks the choice so users can't undo it.
For Mac, the OneDrive client supports folder backup of Desktop, Documents, and Photos via configuration profiles delivered through Intune or Jamf.
## What KFM doesn't cover
- Files outside Desktop, Documents, and Pictures.
- AppData, custom application data folders, browser bookmarks.
- Network mapped drives.
For wider coverage, pair KFM with **OneDrive sync for shared libraries**, **browser sync** in Edge for bookmarks and passwords, and **Roaming Profile / Enterprise State Roaming** in Entra ID for some Windows settings.
## Common pitfalls
- **Existing files clash**: if a user already has files in `Documents` and there are duplicates in OneDrive, the merge can produce conflicts. Cleanup before KFM helps.
- **OneDrive storage quota**: if a user has 50 GB on their desktop, they need at least that much in OneDrive.
- **Outlook PST files**: still don't sync well over OneDrive — exclude.
KFM is one of the highest-impact, lowest-friction wins in a Microsoft 365 rollout. Turn it on early.
## Rollout sequencing that avoids the worst outcomes
The single biggest source of KFM support tickets is enabling **silent, forced redirection** tenant-wide on day one, against machines nobody has audited for existing Desktop/Documents clutter — a user with 80 GB of old project files dumped on their Desktop over several years suddenly triggers a lengthy, bandwidth-heavy first sync with no warning, and any naming conflict between an existing OneDrive file and a matching local file needs manual resolution the user wasn't expecting. The more reliable sequence is: pilot with the **prompt** (not silent) policy on a small group first, watch for large syncs and conflicts, communicate expected first-sync duration and a recommended pre-clean of Desktop clutter, and only then move to silent enforcement for the broader population — locking the setting with "prevent users from redirecting back" as the final step once the population is confirmed synced cleanly.
## Frequently asked questions
**Does KFM work the same way for Mac users?** Similar outcome, different mechanism — the OneDrive client on Mac supports folder backup for Desktop, Documents, and Photos via a configuration profile (delivered through Intune or Jamf), but it's a separate configuration surface from the Windows Group Policy / Intune settings catalog path, so a mixed Windows/Mac estate needs both configured, not just one.
**What happens if OneDrive sync pauses for a long period while KFM is on?** Files keep being saved locally to the redirected folders as normal — KFM redirection is a folder-location change, not dependent on an active sync connection — but nothing new reaches the cloud until sync resumes, meaning the backup and multi-device benefits are suspended (not the ability to keep working) for the duration of any outage or extended offline period.
**Does KFM affect files that are already stored in a Teams channel or SharePoint library, synced separately?** No — KFM only governs the three specific personal folders (Desktop, Documents, Pictures) redirected to a user's own OneDrive; SharePoint libraries synced separately via "Sync" or "Add shortcut to OneDrive" are a distinct sync relationship with their own storage location and are unaffected by whether KFM is enabled or not.
## Frequently asked questions
**What is Known Folder Move?**
A OneDrive feature that redirects the Windows Desktop, Documents, and Pictures folders into OneDrive so their contents sync to the cloud automatically — giving every user backup and roaming of their working files without changing habits.
**Can Known Folder Move be enforced with Intune?**
Yes. The OneDrive settings in the Intune settings catalog (Silently move Windows known folders to OneDrive, Prevent users from redirecting their known folders back) deploy it silently with the tenant ID; users see a notification and their folders sync.
**What happens to Known Folder Move files when someone leaves?**
They are in the user's OneDrive, subject to the deleted-user retention period (30 days by default, configurable) with manager access. Team content that ended up on someone's Desktop follows the same path, which is a reason to keep team files in SharePoint.
---
# OneDrive sharing and permissions
URL: https://www.solvingmicrosoft365.com/guides/onedrive-sharing-and-permissions
Category: SharePoint & OneDrive
Published: 2026-05-01
> How OneDrive sharing actually works — link types, expiration, external sharing, and the admin controls.
OneDrive sharing looks simple — click Share, type an email, send — but several layers of policy decide what the user can actually do. Knowing the layers helps users share confidently and admins set sane defaults.
## The link types
When a user shares a file or folder, they pick a **link type**:
- **Anyone with the link** — no sign-in needed; the most permissive.
- **People in your organisation** — requires a tenant sign-in.
- **People with existing access** — generates a link for people already permissioned, doesn't grant new access.
- **Specific people** — explicit recipients; the link only works for them.
Each link also has a **permission**: View, Edit, or (for documents) Review / Block download. **Anyone** links can additionally have an **expiration date** and a **password**.
## Tenant defaults
The OneDrive section of the SharePoint admin center sets tenant-wide defaults:
- Maximum external sharing level (Anyone / New and existing guests / Existing guests only / Only people in your organisation).
- Default link type (Anyone / Specific people / People in org).
- Default link permission (View / Edit).
- Anyone-link expiration (e.g. 30 days).
- File-type restrictions.
Defaults are the most impactful lever — most users accept whatever the dialog offers.
## Per-user OneDrive controls
Beyond the tenant defaults:
- **External sharing** can be restricted per user via Entra ID **Conditional Access** policies and OneDrive-specific external sharing policies.
- **Block download** policies (via SharePoint Advanced Management) prevent local copies while still allowing viewing.
- **Sensitivity labels** applied to a file can override what link types are allowed and add encryption/usage rights.
## Recoverability
If a user is offboarded, their OneDrive moves to a **30-day retention** state by default — the manager (or whoever the admin set) becomes the new owner and can recover content. Extending this with **Purview retention policies** (years rather than days) is common where regulatory or HR needs require it.
## Practical guidance
A reasonable baseline for most tenants:
- Default link: **People in your organisation**, **View**.
- Anyone-link expiration: **30 days**.
- Block external sharing of files labelled Confidential or higher.
- Quarterly **access reviews** on high-traffic OneDrives.
Anyone-link sharing isn't inherently bad — it's incredibly useful for "share a deck with a client." But make it a deliberate choice, not the default.
## How sharing links interact with sensitivity labels
A sensitivity label applied to a file can **cap** what a user is offered when they click Share, regardless of the tenant's default link settings — a label configured with encryption and a "content marked confidential can only be shared with people in the organisation" content-sharing restriction removes the Anyone and People-in-org-with-external-guest-eligibility options from that file's Share dialog entirely, rather than merely warning the user against choosing them. This is a meaningfully stronger control than tenant-default link settings alone, because it travels with the specific file rather than depending on whichever library or site it happens to be sitting in — a labelled file downloaded and re-uploaded elsewhere in the tenant keeps the same sharing restriction.
## Frequently asked questions
**Does an "Anyone" link expire if the tenant default expiration is changed after the link was created?** No — the expiration is set at the point the link is generated, using whatever policy was in effect then; changing the tenant default afterward doesn't retroactively shorten or extend links already issued, so a policy tightening needs a separate cleanup pass (via a script or SharePoint Advanced Management reporting) to find and revoke pre-existing longer-lived links if the change is meant to apply universally.
**Can a user see who they've shared a file with, after the fact?** Yes — the "Manage access" panel on any file or folder lists every current link and every person with direct access, and lets the owner revoke a link or remove a person's access at any time; this is also where an admin or SharePoint Advanced Management's permissions reports pull from when auditing who can reach a specific file.
**Does sharing a OneDrive file count against the recipient's own storage quota?** No — sharing a file grants access to the original copy in the owner's OneDrive; it doesn't create a duplicate that consumes the recipient's quota. Only an explicit copy or download-and-re-upload by the recipient creates a second, independent file that would count against their own storage.
---
# OneDrive storage quotas and limits
URL: https://www.solvingmicrosoft365.com/guides/onedrive-storage-quotas-and-limits
Category: SharePoint & OneDrive
Published: 2026-05-01
> How OneDrive storage is allocated, what the per-user and per-tenant limits are, and how to scale beyond 1 TB.
OneDrive's storage model has a few moving pieces — per-user quotas, the tenant's overall capacity, and the rules for getting more than the headline 1 TB. Knowing them avoids unwelcome surprises.
## Default per-user quotas
- **Microsoft 365 Apps for Business** and most Microsoft 365 plans: **1 TB** per user.
- **Microsoft 365 E3 / E5**: starts at **1 TB**, can be expanded.
- **Microsoft 365 F1 / F3** (frontline): **2 GB**.
- **Education plans**: vary by tier.
The quota is set by the admin in the SharePoint admin center under OneDrive → Storage, with a default applied to new users and the option to override per user.
## Expanding beyond 1 TB
For plans that support it, Microsoft expands per-user storage **up to 5 TB by default** if a user's OneDrive crosses 90% utilisation. Beyond 5 TB, an admin must request additional quota through Microsoft support, providing usage justification. Microsoft can grant up to **25 TB per user** for E3/E5 customers.
For unique requirements — media production, scientific data, video archives — Microsoft's typical answer is: keep the largest assets in Azure Blob storage or another purpose-built service, not OneDrive.
## File-size and sync limits
- **Single file size**: up to **250 GB** is supported.
- **File path length**: up to **400 characters** for the full URL (server + library + folders + filename).
- **Filename characters**: `?<>:"|*/\` are still illegal, plus a few reserved names.
- **Item count**: a single OneDrive can hold up to **300,000 items** with good performance; sync clients may slow above that.
## Tenant-wide storage
Each tenant has a **tenant storage pool** calculated as 1 TB plus 10 GB per licensed user, shared across SharePoint. OneDrive storage is **separate** from the SharePoint pool — it's per-user. Tenants typically buy **additional storage** at the per-GB/month rate when SharePoint nears its pool, not when OneDrives fill up.
## Retention and deleted content
- **First-stage recycle bin**: 93 days for deleted items.
- **Second-stage recycle bin**: extends retention up to the site quota.
- **Preservation hold libraries** (driven by Purview retention) keep content indefinitely against the OneDrive's quota — they can quietly inflate usage.
Watch preservation hold size in reports — it's where unexpected OneDrive fullness usually comes from.
## Monitoring
The OneDrive section of the admin center reports active vs total storage, top consumers, and growth trends. Set alerts at 80% to avoid users hitting walls.
## Frequently asked questions
**Does deleting a large file immediately free up quota?** Not immediately in every case — a deleted file moves to the first-stage recycle bin and still counts against the user's quota there; it only stops counting once it's permanently purged, whether by the user emptying the recycle bin, the 93-day window expiring, or (if a retention policy applies) once the preservation hold period also lapses. A user who deletes files specifically to free up space and sees no immediate change is usually looking at recycle-bin or preservation-hold retention, not a sync delay.
**Can a departing employee's OneDrive storage be reassigned to someone else immediately?** The 30-day deleted-user retention period exists specifically to give a manager or admin time to review and migrate content before the account (and its OneDrive) is permanently removed; assigning a replacement's licence doesn't itself unlock or transfer the departed user's storage — that's a separate, deliberate migration or ownership-transfer step, ideally completed within the retention window rather than left until it's about to expire.
**Why does the tenant-wide SharePoint storage pool matter if OneDrive is per-user?** Because the pool is what a tenant actually pays to expand — while each user's OneDrive has its own quota, the underlying SharePoint storage pool (1 TB plus 10 GB per licensed user) is a shared ceiling across all SharePoint sites tenant-wide; a tenant with many active OneDrives and large SharePoint sites can exhaust the shared pool well before any individual OneDrive nears its own per-user limit, which is why capacity planning has to look at both numbers, not just the headline "1 TB per user" figure.
**Does a OneDrive quota increase take effect immediately?** Yes for admin-initiated increases within the standard tiers — raising a specific user's quota in the admin center applies right away; requests beyond the default automatic-expansion ceiling that require a Microsoft support case can take longer, since they involve a manual review rather than a self-service change.
---
# OneDrive sync administration best practices
URL: https://www.solvingmicrosoft365.com/guides/onedrive-sync-admin-best-practices
Category: SharePoint & OneDrive
Published: 2026-05-01
> How to deploy and govern the OneDrive sync client at scale — Intune configuration, Known Folder Move, and operational patterns.
The **OneDrive sync client** is one of the highest-impact Microsoft 365 components — the bridge between cloud storage and the desktop. Deployed and configured well, it transforms how users work with files; deployed badly, it generates help-desk tickets daily. A few admin patterns make the difference.
## Deployment
For Microsoft 365-managed estates:
- **Built-in to Windows 10/11** — OneDrive client comes installed. Verify it's current via Windows Update.
- **macOS** — install via Intune as a managed app, signed installer.
- **Mobile** (iOS, Android) — Intune-managed installation; App Protection Policies for data control.
The OneDrive client autoupdates by default; latest is usually best.
## Silent sign-in configuration
For Entra-joined Windows devices, configure **silent sign-in** so OneDrive automatically signs in with the user's work account at first logon:
Group Policy / Intune setting: **Silently configure OneDrive using the primary Windows account** — enabled.
User signs into Windows; OneDrive signs in automatically; no prompts. Reduces friction substantially.
## Known Folder Move
The most impactful single setting: **Known Folder Move (KFM)** redirects Desktop, Documents, and Pictures into OneDrive.
Configure via Intune:
- **Silently move Windows known folders to OneDrive** — enabled.
- **Prompt users to move known folders if not already moved** — gentle nudge for opt-out scenarios.
- **Prevent users from redirecting known folders to PC** — once moved, prevent un-moving.
Result: every file on Desktop, in Documents, in Pictures is backed up to OneDrive automatically. Device loss doesn't lose data.
## Files On-Demand
By default, OneDrive uses **Files On-Demand** — files appear in Explorer but content downloads on access. Saves local disk space.
For specific users / devices (laptop with small SSD), this is essential. For devices with plenty of storage, can be more aggressive about pre-fetching.
Configure tenant-wide:
- **Always-keep-on-device** for specific folders if needed.
- **Auto-storage-sensor** to release older online-only files when disk is constrained.
## Sync limits and tuning
Default sync limits work for most users but tune for specific scenarios:
- **Per-library limit**: OneDrive handles up to 100,000 items per library reliably. Larger libraries should split.
- **Single file size**: up to 250 GB per file (rarely relevant).
- **Bandwidth limits**: throttle upload / download for users on slow links to prevent saturating their connection.
Bandwidth tuning via Intune:
```
Maximum download rate: 500 KB/s
Maximum upload rate: 200 KB/s
```
Useful for branch offices with limited bandwidth.
## SharePoint library sync
Users can sync SharePoint libraries to their desktop the same way as OneDrive. For wide-ranging libraries:
- **Prefer "Add shortcut to OneDrive"** over full sync — Microsoft's recommended pattern. The library appears as a folder inside OneDrive without separate sync root.
- **Limit sync scope** for huge libraries — sync specific subfolders.
- **Sync to specific devices** rather than all — heavyweight libraries shouldn't go to every device.
## Conflict file management
When two devices edit the same file offline, OneDrive creates **conflict files** — both versions preserved with `-DESKTOPNAME` suffix. Users resolve manually.
Prevent: encourage **co-authoring online** via Office web apps rather than offline editing. Office co-authoring eliminates conflicts.
## Tenant settings worth reviewing
In the **SharePoint admin centre → OneDrive**:
- **External sharing** posture — typically "Existing guests only" or "Only people in your organisation" for safety.
- **Default link type** — "People in your org" rather than "Anyone."
- **Anyone link expiration** — 30 days is reasonable.
- **OneDrive retention** for departed users — 30 days default; extend per policy.
- **Storage limit** per user — typically 1 TB.
## Reporting and monitoring
- **OneDrive usage report** in Microsoft 365 admin centre — see who's syncing how much.
- **OneDrive sync health** via Intune Endpoint Analytics — sync errors at scale.
- **Storage trending** — predict when users approach quotas.
- **Per-user quota review** — power users may need 2 TB or 5 TB allocations.
## Common operational issues
- **Sync stuck on a specific file** — usually filename / path issues. OneDrive client surfaces specific error.
- **Pending uploads** queue growing — bandwidth-constrained user; tune throttling.
- **Sign-in failures** — check Conditional Access policy isn't blocking OneDrive client.
- **Repeated conflict files** — user editing offline regularly; encourage co-authoring.
- **Storage exceeded** — user hit 1 TB; either reclaim content or expand quota.
## Storage governance
For OneDrive storage at tenant scale:
- **Power users** legitimately exceed 1 TB; expand via admin centre.
- **Preservation hold growth** — retention policies preserve deleted content invisibly; can balloon. Monitor.
- **Departed users** — retain OneDrive for 30+ days, then transfer / archive.
## Operational discipline
For OneDrive sync to work well at scale:
- **Standardise the deployment** — same configuration across the fleet.
- **Pilot before broad rollout** of configuration changes.
- **Monitor sync health** centrally.
- **Document the tenant configuration** for future admins.
- **Train help desk** on common diagnostic steps.
For Microsoft 365 customers, OneDrive sync is the most-touched single component. Getting it right transforms user experience; getting it wrong costs help-desk time forever.
---
# OneDrive sync troubleshooting
URL: https://www.solvingmicrosoft365.com/guides/onedrive-sync-troubleshooting
Category: SharePoint & OneDrive
Published: 2026-05-01
> A diagnostic ladder for OneDrive sync issues on Windows and macOS — common causes and how to fix them.
OneDrive sync issues are one of the more common help-desk topics for Microsoft 365 customers. Most issues fall into a handful of categories. A diagnostic ladder lets the help desk resolve them efficiently rather than starting from scratch each time.
## Quick first checks
Before deep troubleshooting:
- **Is the user signed in?** OneDrive icon in the system tray (Windows) or menu bar (Mac); look for sign-in state.
- **Is the device online?** Sync requires network.
- **Is there a service incident?** Check Microsoft 365 Service Health.
- **Has the user's licence changed recently?** Removed Microsoft 365 plan = no OneDrive.
These four checks resolve 30–50% of cases.
## Sign-in problems
The OneDrive client requires sign-in. Common patterns:
- **Modern authentication failure** — Conditional Access blocking the OneDrive client. Check sign-in logs for the failure reason.
- **Multiple accounts** — user signed into a personal OneDrive instead of work. Sign out of personal, sign in to work.
- **Token expired** — sometimes resolves with a sign-out / sign-in cycle.
- **Network proxy blocking** — corporate proxies can block OneDrive endpoints. Bypass for OneDrive's specific URLs.
For repeated sign-in failures, **Reset OneDrive** to a clean state:
```
# Windows
%localappdata%\Microsoft\OneDrive\onedrive.exe /reset
```
Reset preserves the synced files; it just clears the local OneDrive client state.
## Sync stuck or slow
If files aren't uploading or downloading:
- **Files On-Demand state** — a file marked "online-only" doesn't sync to disk. Set to "Always keep on this device" if local copy needed.
- **Large files** — OneDrive supports up to 250 GB per file but very large files take time.
- **Bandwidth limits** — corporate networks may throttle OneDrive; check Quality of Service / bandwidth tuning settings.
- **Long path or invalid character** — paths > 400 chars or files with `?<>:"|*` etc. can't sync. Rename or restructure.
- **Open files** — Outlook with a PST file open, Excel with a workbook open — file locks prevent sync. Close the file.
## File conflicts
When the same file is edited by two devices offline, OneDrive creates a **conflict file** — the original name plus `-DESKTOPNAME` or similar. Both versions are preserved; user picks which to keep.
Prevention: co-author online via Office web apps when collaborating; use Office Cloud Policy to bias toward online editing.
## Known Folder Move issues
KFM redirects Desktop, Documents, and Pictures into OneDrive. Common issues:
- **Initial move slow** — first time KFM kicks in, all content uploads. Can take hours / days for large profiles.
- **Files in restricted locations** — some specific files / folders aren't compatible with redirection.
- **Permission errors** — files locked by other applications can't move during initial KFM.
For users with large existing local content, schedule KFM rollout when they're on fast network and tell them what to expect.
## SharePoint library sync failures
For users syncing SharePoint libraries (rather than just their OneDrive):
- **Library too large** — libraries with hundreds of thousands of items strain the sync client. Consider "Add shortcut to OneDrive" instead of full sync.
- **Permission changes upstream** — if site permissions change, the sync may fail silently. Re-add the library.
- **Deep folder structure** — Windows path limits still bite some apps. Keep paths short.
## Reset and rebuild
When all else fails:
1. **Quit OneDrive**.
2. **Reset OneDrive** with the `/reset` command above.
3. **Sign in fresh** — OneDrive rebuilds sync state.
4. **Re-add SharePoint libraries** that were synced previously.
This is the "reformat-and-reinstall" approach but for OneDrive sync. Often resolves stubborn issues.
## Admin-side investigation
For systemic issues affecting multiple users:
- **OneDrive activity report** in the Microsoft 365 admin center — see who's syncing, how much, errors.
- **Defender XDR alerts** — sometimes blocking malicious files prevents sync.
- **Conditional Access** — check if a recent CA policy is affecting the OneDrive client.
- **Network connectivity** — Microsoft 365 connectivity test from a representative user location.
## Operational tips
- **Document common issues** for the help desk.
- **OneDrive client version** — keep current; older versions have bugs.
- **Monitor sync health** at scale via Intune Endpoint Analytics signals.
- **Communicate to users** about expected sync times for large operations.
For Microsoft 365 customers with significant OneDrive usage, building a diagnostic ladder like this turns a 30-minute help-desk call into a 5-minute one. The cumulative time savings are substantial.
---
# Outlook cached mode and OST files
URL: https://www.solvingmicrosoft365.com/guides/outlook-cached-mode-and-ost-files
Category: Exchange & Outlook
Published: 2026-05-01
> How classic Outlook caches mailbox data locally — what an OST file is, when to use cached mode, and the modern alternatives.
For classic Outlook for Windows, **cached mode** is the local-cache-of-the-mailbox model that has been standard for decades. With cached mode enabled, Outlook downloads mailbox content into a local file (`.ost`) and works against that, syncing with Exchange Online in the background. With it disabled, Outlook talks live to Exchange for every operation. The choice matters more than it used to.
Cached mode is a classic-Outlook concept — see [new vs classic Outlook](/guides/outlook-new-vs-classic-on-windows) — that interacts with [archiving](/guides/exchange-online-archiving-and-litigation-hold) and mailbox sizes from [What is Exchange Online](/guides/what-is-exchange-online); on virtual desktops it is an [AVD](/guides/azure-virtual-desktop-explained) profile-design question.
## What cached mode does
In cached mode, Outlook:
- Downloads a local copy of the mailbox into an `.ost` file (usually in `%LOCALAPPDATA%\Microsoft\Outlook\`).
- Reads and writes against that local copy first.
- Syncs changes to and from Exchange Online over the background.
- Provides snappy UI even on slow networks.
- Allows offline reading and composing.
Cached mode is the default for new Outlook installs.
## When cached mode is right
- **Most knowledge workers** on personal devices benefit from the speed and offline capability.
- **Mobile users** who experience network variability.
- **Users with large mailboxes** where waiting for live-mode response on every click is painful.
## When cached mode causes problems
- **Very large mailboxes (>50 GB)** can produce very large `.ost` files, slow to download initially and prone to corruption.
- **Shared mailboxes** with hundreds of GB of data — auto-mapped to a user's profile in cached mode, the `.ost` can balloon.
- **VDI / shared workstations** — the `.ost` doesn't survive between sessions, so it re-downloads constantly.
- **Disk-constrained devices** — laptops with small SSDs may struggle.
## Cached mode tuning
Group Policy and Intune configuration can:
- **Limit cached time** — only cache the last 1, 3, 6, 12 months instead of everything.
- **Disable shared mailbox caching** so they're live-only.
- **Disable cached mode entirely** for VDI scenarios.
For shared mailboxes specifically: **turn off `CacheOthersMail`** for any user mapped to a multi-GB shared mailbox. They access it live instead, with much better performance.
## The new Outlook for Windows
The **new Outlook for Windows** (replacing classic Outlook over the coming years) takes a different approach: it's a thin web client that talks to Exchange via Microsoft Graph, with much smaller local cache footprint. Cached mode and `.ost` files are no longer the model. For most users, this works well.
The trade-off: heavy users who relied on classic Outlook's behaviour offline (long flights, intermittent connectivity) may notice differences. Microsoft has been adding **offline support** to the new Outlook progressively to close the gap.
## What to do today
- **Classic Outlook with cached mode**: still fine for traditional knowledge workers. Tune retention and shared-mailbox caching as needed.
- **VDI / cloud PC users**: disable cached mode or use new Outlook with cloud-cache features.
- **Planning ahead**: new Outlook is the strategic direction; pilot it now to find any classic-only dependencies.
`.ost` files aren't going extinct soon, but their day-to-day relevance is shrinking.
---
# Outlook calendar delegation
URL: https://www.solvingmicrosoft365.com/guides/outlook-calendar-delegation
Category: Exchange & Outlook
Published: 2026-05-01
> The three ways to share a calendar in Outlook — delegate access, share permissions, and shared calendars.
Outlook supports three distinct ways to share a calendar with someone else. They're often confused, and each has different capabilities and side effects. Knowing which to pick matters.
Delegation is the user-side counterpart to [shared mailboxes](/guides/shared-mailboxes-explained) and [resource mailboxes](/guides/exchange-online-resource-mailboxes); for executives it pairs with [Copilot in Outlook](/guides/copilot-in-outlook) meeting prep, and cross-organisation cases are in [cross-tenant calendar sharing](/guides/cross-tenant-calendar-sharing).
## 1. Delegate access
**Delegate access** gives someone the ability to **act on your behalf** in your mailbox — they can not only read your calendar but **send meeting invitations as you**, accept or decline on your behalf, see private items if you allow it, and read your inbox and tasks if you also delegate those.
Use case: executive assistant for an executive, where the assistant runs the calendar end-to-end.
Configured in Outlook → File → Account Settings → Delegate Access (classic) or in the new Outlook account settings. Permissions levels:
- **Reviewer** — read only.
- **Author** — create items.
- **Editor** — modify any item.
Delegates receive meeting requests on the delegator's behalf; replies sent by delegates show "Sent on behalf of."
## 2. Share permissions
**Share permissions** are simpler — share **just the calendar** with someone, with a defined permission level:
- **Free/busy** — they see when you're busy, but not what.
- **Limited details** — busy + meeting subjects.
- **Full details** — everything except private items.
- **Editor** — they can edit your calendar.
Use case: a peer who needs to see your availability, a project team that should see each other's calendars.
Configured per calendar from the calendar's right-click menu → Share calendar.
## 3. Shared calendars (Microsoft 365 Group)
A **Microsoft 365 Group** has its **own shared calendar** that all group members can see and modify. Use case: a team's "team calendar" — vacations, key dates, on-call rotations.
Distinct from personal-calendar sharing — the group calendar is its own object, not anyone's personal one.
## When to use which
| Need | Option |
| --- | --- |
| Assistant runs an executive's calendar | Delegate access |
| Peer needs to see when you're busy | Share permissions, Limited details |
| Team needs a shared calendar for events | Microsoft 365 Group calendar |
| Project needs an audit-friendly events log | Group calendar |
| Reception needs to book exec time | Delegate access |
## Common operational issues
- **Cached mode and shared calendars** — large shared calendars cached on disk grow OST files. Configure cached mode to skip caching shared calendars when not needed.
- **New Outlook for Windows** — delegation and shared calendars work, but the UI is slightly different from classic Outlook; verify with users before migration.
- **Private items** — by default, delegates see free/busy of private items; they can be granted access to see content if needed.
- **Permissions inheritance** — sharing a top-level calendar doesn't automatically share sub-calendars in the same mailbox.
For organisations with many executive-assistant relationships, **document the delegation pattern** — who is delegate for whom, with what level. Audit periodically; delegations linger after staff changes.
---
# Outlook Focused Inbox and the legacy Clutter folder
URL: https://www.solvingmicrosoft365.com/guides/outlook-focused-inbox-and-clutter
Category: Exchange & Outlook
Published: 2026-05-01
> How Focused Inbox separates important mail from the rest, and what happened to its predecessor Clutter.
Outlook's **Focused Inbox** is the feature that automatically separates likely-important email from likely-noise — newsletters, bulk mail, low-priority threads — into two tabs in the inbox: **Focused** and **Other**. It's been the default in Outlook since 2017 and is still the right answer for most users.
Focused Inbox is a client feature of [Outlook](/guides/outlook-new-vs-classic-on-windows) that users confuse with [anti-spam filtering](/guides/exchange-online-anti-spam-and-anti-phishing) and [quarantine](/guides/defender-quarantine-workflow); it can be controlled alongside [rules and automation](/guides/outlook-rules-and-automation).
## How Focused Inbox works
When mail arrives at the mailbox, Exchange Online's machine learning model classifies it as Focused or Other based on:
- **Past user behaviour** — what the user reads, replies to, deletes, marks as junk.
- **Sender reputation** — bulk senders, automated systems, marketing platforms.
- **Content signals** — headers, subject patterns, recipient lists.
- **Explicit overrides** — users can move messages between Focused and Other, training the model.
The model is per-mailbox and adapts over time. Different users get different sorting based on their own habits.
## Where Focused Inbox shows up
- **Outlook for Windows** (classic and new) — Focused / Other tabs.
- **Outlook on the web** — same.
- **Outlook for Mac** — same.
- **Outlook mobile** — same.
- Notifications respect the Focused / Other split on mobile (Focused gets a notification, Other doesn't, by default).
Users can turn off Focused Inbox per-client and just see a single inbox.
## The legacy Clutter folder
Before Focused Inbox, Microsoft had **Clutter** — a server-side feature that moved likely-unimportant mail into a `Clutter` folder rather than splitting the inbox into two tabs. Clutter was retired in 2020 and replaced by Focused Inbox. Mailboxes that still have a `Clutter` folder from the old era have it as a regular folder, no longer automatically populated.
## Admin controls
Focused Inbox can be configured tenant-wide via PowerShell:
- **Default-on or default-off** for the tenant.
- **Per-user enabled / disabled** via Exchange Online PowerShell.
- **Override policies** that prevent users from changing the setting.
For most tenants, leaving Focused Inbox on by default with users able to opt out works well. Users who don't want the split turn it off; everyone else benefits.
## How it differs from Junk Mail
Junk Mail is a separate filter — server-side anti-spam from EOP that moves likely-spam into the **Junk Email** folder. Focused Inbox is **post-spam-filter** classification: it works on mail that has already cleared the spam filter, sorting wanted-but-low-priority mail away from likely-important mail.
A bulk newsletter sender that's legitimate goes to Other. A phishing attempt goes to Junk (or quarantine). They're complementary, not redundant.
## Tips for getting good Focused-Inbox sorting
- **Train the model** — move messages between Focused and Other deliberately for the first few weeks.
- **Unsubscribe from genuine junk** rather than leaving it to Other forever.
- **Senders you'll always want in Focused** — add to your contacts.
Focused Inbox is one of those quiet features that gets better the more you use it. The instinct to turn it off in the first week is often regretted.
---
# Outlook mobile policies and app protection
URL: https://www.solvingmicrosoft365.com/guides/outlook-mobile-policies
Category: Exchange & Outlook
Published: 2026-05-01
> How to govern Outlook mobile on iOS and Android — app protection policies, security settings, and feature controls.
**Outlook for iOS and Android** is by far the most-used mobile app for Microsoft 365 email — and for many users, the place they spend most of their workday. Governing it well matters both for security and user experience.
Outlook mobile is protected by [Intune app protection policies](/guides/intune-app-protection-policies) as part of [mobile device security](/guides/microsoft-365-mobile-security); [Conditional Access](/guides/entra-id-conditional-access-design) can require the managed app, and a lost phone is handled per [remote wipe with Intune](/guides/how-to-remote-wipe-a-lost-device-with-intune).
## App protection policies (MAM-WE)
The headline control: **Intune App Protection Policies** apply to Outlook mobile on personal and corporate devices alike. Without enrolling the device in MDM, IT can:
- **Require a PIN or biometric** to open the app.
- **Encrypt corporate data** stored by Outlook.
- **Block copy/paste** from Outlook to personal apps.
- **Block screenshots** in some scenarios.
- **Force "open in" managed apps** — attachments open in Word / Excel / PowerPoint with their own MAM policies, not in third-party apps.
- **Conditional launch** — block sign-in if the device is jailbroken, OS is below minimum, or app is older than minimum.
- **Remote wipe** of corporate data inside Outlook without touching the personal device.
A typical baseline: PIN required, encryption on, no copy-paste to personal apps, no save to local files, screenshots blocked, conditional launch on jailbreak. Most users don't notice the restrictions in normal use; the security uplift is significant.
## Outlook-specific mobile configuration
Beyond MAM, Outlook has its own configurable settings:
- **Focused Inbox** on / off / user-choice.
- **Notification settings** — Focused-only notifications, all-mail notifications, or custom.
- **Email signatures** — corporate signature pushed via cloud signatures.
- **Calendar settings** — default reminder times, work hours.
- **External-account restrictions** — block adding personal Gmail / iCloud accounts to the same Outlook instance.
- **Biometric unlock** behaviour.
Configured in **Intune → Apps → App configuration policies**, with the app type set to **Microsoft Outlook**.
## Conditional Access integration
The Conditional Access policy that ties this all together:
> For users accessing **Office 365** from **iOS or Android**, require:
> - **Approved client app** (only Microsoft mobile apps like Outlook, Teams, OneDrive — not native iOS Mail).
> - **App protection policy** required.
With this policy in place, the only path to corporate email on a personal phone is Outlook with MAM. iOS native Mail can't sign in (it doesn't support MAM); third-party email clients can't sign in either.
## Account-restriction options
For organisations with strong BYOD posture, the **multi-account behaviour** of Outlook mobile matters:
- **Restrict to organisational accounts only** — prevent users adding personal Gmail accounts to the same app instance.
- **Force corporate account as primary** — when both work and personal accounts exist.
These prevent data leakage scenarios where users accidentally compose a work email from their personal account or vice versa.
## Common pitfalls
- **Native iOS Mail confusion** — some users prefer it; the right answer is to block it via Conditional Access while making Outlook genuinely good for them.
- **Push notification expectations** — over-aggressive notification policies cause users to disable notifications entirely.
- **Authenticator app dependency** — Outlook mobile relies on the Authenticator app for some MFA scenarios; ensure both are deployed together.
- **Personal Microsoft accounts** — block them on the work app instance if BYOD posture requires.
For Microsoft 365 customers serious about mobile security, Outlook + Intune App Protection + Conditional Access is the standard pattern. Setup is moderate; operational benefit is durable.
---
# Outlook rules and automation
URL: https://www.solvingmicrosoft365.com/guides/outlook-rules-and-automation
Category: Exchange & Outlook
Published: 2026-05-01
> Client-side rules, server-side rules, and Power Automate — the three ways to automate email handling in Microsoft 365.
There are three different "rule" systems for automating email in Microsoft 365. They look similar, behave differently, and have very different scopes. Knowing which to use saves a lot of frustration.
Server-side rules are also where attackers hide, which is why the [compromised account runbook](/guides/entra-id-compromised-account-runbook) and [blocking a compromised account](/guides/how-to-block-a-compromised-account-in-microsoft-365) check them; organisation-wide rules are [transport rules](/guides/transport-rule-examples), and heavier automation belongs in [Power Automate](/guides/what-is-power-automate).
## 1. Server-side rules (Exchange rules)
These rules run on **Exchange Online** itself, against the mailbox, whether or not Outlook is open. They're stored on the mailbox and persist across devices. Triggers and actions include:
- Move messages by sender, subject, content.
- Forward or redirect (admin policies often disable external forwarding).
- Delete or flag.
- Mark as read.
- Apply categories.
Server-side rules are the right choice for almost all per-user automation. They're configured in Outlook (any client) and surface uniformly across devices.
## 2. Client-side rules (classic Outlook only)
Some rules run only inside the **classic Outlook for Windows** application. They depend on Outlook being open and signed in to fire. Typical triggers that force client-side rules: playing a sound, running a script (legacy VBA), starting an application. Client-side rules are increasingly rare and not supported in the new Outlook or on the web.
If you have users on the new Outlook, **client-side rules don't run** — review them before migration.
## 3. Power Automate
For anything beyond simple per-message handling, **Power Automate** is the right tool. Triggers include "When a new email arrives," "When an email is flagged," "When an email arrives in a shared mailbox." Actions span hundreds of connectors: post to Teams, create a Planner task, file to SharePoint, call an HTTP API, send to a ticketing system.
Power Automate also works on **shared mailboxes**, which Outlook rules don't always handle gracefully.
## Message recall
None of the rule systems above undo a message that's already been sent — that's **message recall**, a separate Outlook feature (Sent item → File → Info → Message Recall) for retracting an email after the fact. The modern, cloud-based recall works within a Microsoft 365 tenant regardless of whether the recipient has already opened the message, and reports success or failure per recipient rather than leaving the sender guessing. It only reaches as far as your own tenant, though: once a message has gone to an external recipient or a different Microsoft 365 tenant, there's no recall path back — Microsoft has no reach into a mailbox it doesn't host.
## Transport rules (admin-level)
Don't confuse user-level Outlook rules with **transport rules** (mail flow rules) in the Exchange admin center. Transport rules run on every message passing through the tenant — they're an admin-scoped tool for things like adding disclaimers, redirecting to legal hold, blocking by content, or appending external-sender warnings. They aren't a substitute for per-user rules.
## When to use which
| Need | Tool |
| --- | --- |
| Move newsletter mail to a folder | Server-side rule |
| Create a Planner task when a project email arrives | Power Automate |
| Add a legal disclaimer to all outbound mail | Transport rule |
| Forward urgent messages to a phone | Server-side rule (with caution) |
| Process emails into a SharePoint list | Power Automate |
Start with server-side rules. Reach for Power Automate when the logic crosses into other apps.
---
# Managing Outlook signatures at scale
URL: https://www.solvingmicrosoft365.com/guides/outlook-signatures-management
Category: Exchange & Outlook
Published: 2026-05-01
> How to manage email signatures in Outlook — cloud signatures, transport rules, and third-party tools.
Email signatures are surprisingly hard to manage at scale. Users want consistent branding, legal requires specific disclaimers, marketing wants the latest campaign banner, and individuals want their personal contact info. Microsoft 365 offers several mechanisms — none perfect, all with trade-offs.
Signatures at scale usually mean [transport rules](/guides/transport-rule-examples) or a third-party tool, affect [new and classic Outlook](/guides/outlook-new-vs-classic-on-windows) differently, and carry the [branding](/guides/microsoft-365-branding) decisions; [BIMI](/guides/bimi-and-brand-indicators) is the inbox-level brand signal.
## Cloud signatures (Outlook)
The newest option: **roaming signatures** stored in the user's Exchange Online mailbox. Configured once in Outlook on the web (or new Outlook for Windows), they sync across all the user's Outlook clients — Windows, Mac, web, mobile.
Strengths:
- **Per-user persistent** across devices.
- **No client-side install** to manage.
- **Supports HTML** with images, branding.
Weaknesses:
- **User-managed** — IT can't enforce a corporate standard.
- **Signature is added before send** — the user sees it in their composed message.
## Transport-rule signatures
A Microsoft 365 admin can create an **Exchange transport rule** that **appends a corporate signature to every outbound message** matching defined criteria — for example, all outbound mail from `@yourcompany.com` gets a legal disclaimer footer.
Strengths:
- **Centrally managed** — IT controls the content.
- **Applies universally** regardless of user habits.
- **Can be conditional** — different signatures for different departments, regions.
Weaknesses:
- **Server-side append** — the user doesn't see the signature in their sent items.
- **Limited HTML support** — images and complex layouts can render poorly.
- **No interleaving with user signatures** — typically you end up with the user signature plus the corporate footer at the bottom.
- **Internal vs external** — be careful about which messages get the disclaimer.
Good for legal disclaimers and corporate compliance lines; less good for full branded signatures.
## Third-party signature management
Multiple vendors specialise in Microsoft 365 signature management — **Exclaimer**, **CodeTwo**, **Symprex**, **Letsignit**, **Rocketseed**, others. Each offers:
- **Centrally managed templates** with rich branding.
- **Per-user personalisation** (name, title, photo from Entra ID).
- **Campaign banners** rotated centrally.
- **Departmental variants**.
- **Analytics** on banner click-through.
They work via either Exchange transport rules (server-side stamping with proper rendering) or via Outlook client add-ins (client-side, sees the signature before send).
For organisations serious about email branding, these tools usually pay back the licence cost in saved IT-and-design effort.
## How to choose
- **No corporate branding requirement, individuals manage their own** → cloud signatures, user-managed.
- **Legal disclaimer footer only** → transport rule, no third-party tool.
- **Consistent corporate branding, banners, analytics** → third-party tool.
- **Mixed scenarios** → combine cloud signatures for personal touch + transport rule for the legal footer.
## Operational considerations
- **Test rendering** in major clients — Outlook for Windows, Mac, web, mobile, plus the recipient experience in Gmail, Apple Mail, etc.
- **Avoid embedded base64 images** in signatures — they bloat every email significantly.
- **Linked images** sometimes break (image hosted on a server that goes away) — use a trusted CDN.
- **Don't put critical info in the signature image** — many recipients see images blocked by default.
A consistent signature programme is one of the most visible parts of corporate identity. Treat it as a programme, not a one-off.
---
# PIM operational playbook
URL: https://www.solvingmicrosoft365.com/guides/pim-operational-playbook
Category: Microsoft Entra (Identity)
Published: 2026-05-01
> How to run Privileged Identity Management as a working process — onboarding, activation, approvals, and audit.
Deploying **Privileged Identity Management (PIM)** is the easy part — configure roles, enable users as eligible, you're done. The interesting question is **how PIM works as a daily operation**: how admins activate roles, who approves, how audit happens, when reviews fire. A working operational playbook makes PIM a healthy practice rather than a one-time deployment.
## The basic activation flow
For an eligible admin:
1. They need to perform a privileged operation (assign a licence, modify a Conditional Access policy, restore a deleted user).
2. They go to **Entra admin center → Privileged Identity Management → My roles** (or via `entra.microsoft.com/PrivilegedAccess`).
3. They click **Activate** on the relevant eligible role.
4. PIM may prompt for:
- **MFA** confirmation (even though they signed in earlier).
- **Justification text** — why they need the role.
- **Ticket reference** — link to the change ticket or incident.
- **Approval** — for high-privilege roles, an approver must confirm.
5. Once activated, the role is active for a configured duration (typically 1–8 hours).
6. After duration, the role automatically deactivates.
## Configuration recommendations
For each Entra ID role, configure:
- **Maximum activation duration** — match to the work duration. 4 hours is a reasonable default; less for very sensitive roles.
- **MFA at activation** — yes, always.
- **Justification required** — yes. Force admins to articulate why.
- **Ticket information** — yes, where you have a ticket system. Helps audit.
- **Approval required** — for Global Administrator, Privileged Role Administrator, and similar high-power roles. Multiple approvers prevent single-approver bottlenecks.
## Approval design
For approval-required roles, **who approves matters**:
- **Peer approval** — another eligible admin in the same role. Fastest; some risk of mutual approval ("I approve yours, you approve mine").
- **Manager approval** — the admin's manager. Slower but adds organisational oversight.
- **Security team approval** — dedicated approval pool. Slowest, strongest oversight.
A pragmatic approach: peer approval for common cases (User Administrator, etc.), security team approval for the strongest roles (Global Administrator).
## Break-glass accounts
PIM doesn't eliminate the need for **break-glass accounts** — emergency-access accounts excluded from CA policies, with very strong unique credentials stored offline. PIM eligibility chains can have circular failures (the only PIM approver is unreachable, so nobody can activate). Break-glass solves that.
Document break-glass procedures. Monitor for unauthorised use. Rotate credentials periodically.
## Access reviews
The other half of PIM is **access reviews** — periodic recertification of who's eligible for what.
Configure for each privileged role:
- **Recurrence** — quarterly is common; semi-annual for less sensitive roles.
- **Reviewer** — the admin themselves (self-attestation), their manager, or a named security reviewer.
- **Action on no response** — typically "remove eligibility" so absent attestation defaults to removal.
Access reviews prevent the slow drift where someone gets a role for one project and keeps it indefinitely.
## Audit and reporting
PIM activity logs in the Entra audit log:
- Every activation request (approved or denied).
- Every approval action.
- Every access review outcome.
- Every role assignment change.
Pull these into your SIEM / Microsoft Sentinel for cross-correlation with other signals.
## Operational metrics
A healthy PIM practice produces measurable signals:
- **Time-to-activate** — should be under 5 minutes for self-activation, under 30 minutes for approver-needed.
- **Approval rate** — most should be approved (otherwise eligibility is wrong); high denial rate means scope problem.
- **Active hours per admin per month** — actual usage; suggests right-sizing.
- **Standing assignments** — should be near zero except for break-glass.
For Microsoft 365 tenants with serious security posture, PIM with this operational discipline is one of the highest-leverage controls available. Standing admin access is one phish away from disaster; PIM makes it not.
## Frequently asked questions
**How often should PIM role assignments be reviewed?**
Quarterly for Global Administrator and other high-impact roles, twice a year for the rest, using PIM access reviews with auto-apply so unreviewed access is removed. The review cadence is what stops eligible assignments accumulating the way permanent ones used to.
**What should the activation duration be for admin roles?**
As short as the task allows: two to four hours for Global Administrator, up to eight for roles used through a working day. Users can re-activate when it expires. Longer durations defeat the purpose; shorter ones with approval requirements cause admins to hoard activations.
**What PIM alerts should be turned on?**
Roles assigned outside PIM, roles activated too frequently, too many Global Administrators (threshold five or fewer), potential stale accounts in privileged roles, and roles that do not require MFA on activation. Route them to the security channel, not an individual.
---
# Power Apps — canvas vs model-driven
URL: https://www.solvingmicrosoft365.com/guides/power-apps-canvas-vs-model-driven
Category: Power Platform
Published: 2026-05-01
> The two main Power Apps types — what each is good at, and how to pick.
Power Apps has two distinct app types: **canvas apps** and **model-driven apps**. They share licensing and tooling, but they're fundamentally different products with different best uses. Picking the right one up front saves a lot of rework.
## Canvas apps
A **canvas app** is designed visually. You start with a blank screen, drop controls (labels, buttons, galleries, forms), connect them to data sources, and bind their behaviour with **Power Fx** — an Excel-like formula language.
Strengths:
- **Total layout freedom** — design any UI you can imagine.
- **Phone-first or tablet-first** orientations native.
- **Heterogeneous data sources** — SharePoint, Dataverse, SQL, Excel, custom connectors all work.
- **Embedding** — canvas apps can be embedded in Teams, Power BI, SharePoint, model-driven apps, web pages.
- **Fast to start** — a useful app in an afternoon.
Best for:
- **Task-oriented apps**: inspections, audits, approvals, expense capture, asset tagging.
- **Mobile-first scenarios** for frontline workers.
- **Form replacements** for paper or PDF processes.
- **Custom views** on top of existing data.
Weaknesses:
- Complex many-screen apps get **hard to maintain** as Power Fx logic spreads across controls.
- **Performance** can suffer with large datasets if not designed carefully.
- **Per-screen design** doesn't scale well to record-management apps with many entity types.
## Model-driven apps
A **model-driven app** generates its UI from a **Dataverse data model**. You define tables, fields, relationships, business rules, forms, and views; the app surface follows. You build by configuring **forms** (the layout of a single record) and **views** (the layout of a list).
Strengths:
- **Built-in CRUD** experience — list, detail, edit, search, filter — without writing UI.
- **Excellent for record management** — customers, orders, cases, contracts.
- **Business process flows** guide users through multi-stage processes.
- **Dataverse security** — row-level, field-level, hierarchical.
- **Same engine as Dynamics 365**, with rich extensibility.
- **Scalable** to apps with hundreds of tables.
Best for:
- **CRM-like scenarios** — customers, leads, opportunities, cases.
- **Workflow-heavy apps** with structured processes.
- **Apps with many entity types** that need consistent navigation.
- **Apps that may grow into Dynamics 365 territory**.
Weaknesses:
- **Less visual flexibility** — the UI is largely prescribed.
- **Requires Dataverse** — adds cost and complexity.
- **Steeper learning curve** for first-time makers.
## Power Pages
**Power Pages** is the third app type — externally facing **websites** with authenticated users and Dataverse-backed data. Used for portals, customer self-service, partner extranets, event registration. Behind the scenes it's a model-driven app extended with a Liquid-templating-based public site.
## How to choose
| Need | App type |
| --- | --- |
| Custom UI, mobile-first, task focused | Canvas |
| Record management, many tables | Model-driven |
| External user portal | Power Pages |
| Already using Dynamics 365 | Model-driven |
| Small app, SharePoint data | Canvas |
| Big app, Dataverse data | Model-driven |
When in doubt, prototype both. The exploration takes hours and saves weeks.
---
# Power Apps canvas app performance tuning
URL: https://www.solvingmicrosoft365.com/guides/power-apps-performance-tuning
Category: Power Platform
Published: 2026-05-01
> Common reasons canvas apps are slow and the patterns that fix them.
Power Apps canvas apps are easy to build but easy to build slowly. A handful of patterns separate apps that feel snappy from apps that take 10 seconds to load and 3 seconds to respond to every tap. Performance tuning is a craft, not a mystery.
## Causes of slow apps
A non-exhaustive list of the usual suspects:
### Too many data fetches at startup
Apps with many `OnVisible` calls to data sources, or many controls each fetching their own data, take long to render. Worst case: an app that opens with 15 simultaneous SharePoint list queries.
**Fix**: load common data once into a **collection** at app start (`OnStart`), reference the collection from controls. Update the collection when needed.
### Non-delegable queries on large data sources
A `Filter()` against a 100,000-row data source that isn't delegable returns only the first 500 rows. Beyond performance, this is a correctness bug — but it also creates slow client-side processing on the partial result.
**Fix**: use delegable operators (`=`, `<`, `>`, `StartsWith`, etc. — the editor warns when delegation breaks). Restructure logic to push filters server-side.
### Heavy logic in control properties
Complex expressions in `Items`, `Visible`, `Text` properties recalculate frequently. If a label's `Text` does a `LookUp` over 50,000 rows on every render, the app feels sluggish.
**Fix**: precompute values into context variables or collections. Reference the variables in control properties.
### Image-heavy galleries
A gallery of 200 customer records each with a profile image fetched at gallery load is slow — 200 HTTP requests just to render.
**Fix**: paginate, use a smaller image dimension, lazy-load images, or use blob references rather than embedded images.
### `OnStart` is bloated
A long `OnStart` makes the app slow to open. Users see a blank screen until `OnStart` completes.
**Fix**: move non-essential setup to `OnVisible` of screens that need it. Use `Concurrent()` to parallelise independent operations. Defer heavy operations until after the first screen is visible.
### Connections without caching
Each call to a connector goes over the network. For data that doesn't change often, cache it locally rather than refetching.
**Fix**: load into a collection on `OnStart` (or first use); refresh only when necessary.
## Tools
The Power Apps **Monitor** tool — accessible from the app's Advanced menu — records every action in the app at runtime, with timing and source attribution. Pin Monitor on a second window, do an action in the app, see what fired and how long it took. Almost every performance investigation starts here.
## The `Concurrent()` function
For independent operations at startup, `Concurrent()` runs them in parallel:
```
Concurrent(
ClearCollect(colCustomers, Customers),
ClearCollect(colProducts, Products),
ClearCollect(colOrders, Orders)
)
```
Without `Concurrent`, they run sequentially. With it, they run in parallel — 3x faster for three independent data loads.
## Best practices summary
- **Load shared data once**, into collections, on `OnStart` or first use.
- **Verify delegation** — fix any non-delegable warnings.
- **Keep control properties simple** — precompute, don't recompute.
- **Minimise `OnStart`** — first-screen visibility before everything else.
- **Paginate galleries** — gallery with 5,000 records is slow no matter how good your data layer is.
- **Use `Concurrent`** for parallel independent operations.
- **Measure with Monitor** — guesswork is unreliable.
## When to rebuild instead of tune
Some apps are slow because of architectural choices that no amount of tuning will fix:
- **Wrong data source** — SharePoint list with 200,000 items where Dataverse would be appropriate.
- **Overly complex single-screen design** — too many controls, too much logic.
- **Should be a model-driven app** — for many-table CRUD scenarios, canvas isn't the right tool.
If tuning yields marginal improvements after honest effort, consider whether you're optimising the wrong shape.
For most canvas apps that feel slow, applying the patterns above takes them from "annoyingly sluggish" to "responsive enough." The hard part is having the discipline to measure rather than guess.
---
# Power Automate cloud flows — a deep dive
URL: https://www.solvingmicrosoft365.com/guides/power-automate-cloud-flows-deep-dive
Category: Power Platform
Published: 2026-05-01
> The architecture, triggers, actions, and patterns of cloud flows — and the licensing rules that catch many users out.
**Cloud flows** in Power Automate are the bread and butter of low-code workflow automation in Microsoft 365. Beyond simple "when email arrives, post to Teams" scenarios, they support sophisticated orchestration — parallel branches, error handling, approvals, child flows — that can replace a surprising amount of custom development.
## The three trigger types
- **Automated** — fires on an event (new email, new SharePoint item, file upload, message in Teams). The most common type.
- **Instant** — triggered manually by a button (in Power Automate mobile, from Teams, from a Power App).
- **Scheduled** — runs on a timer (every hour, every Tuesday at 09:00).
Each cloud flow has one trigger.
## Actions and connectors
After the trigger come **actions**: connector calls that read, write, or transform data. Microsoft ships hundreds of **connectors** for Microsoft 365 services, Azure, Dynamics 365, SAP, Salesforce, ServiceNow, Twilio, Stripe, and so on. Custom connectors let you call any REST API.
Connectors are split into **standard** (in-suite, included with Microsoft 365) and **premium** (Dataverse, SQL, HTTP, custom). Premium requires Power Automate or Power Apps premium licensing.
## Control flow
Cloud flows support the usual control structures:
- **Conditions** with if/then branches.
- **Switch** on a value.
- **Apply to each** loops.
- **Do until** loops with explicit exit conditions.
- **Parallel branches** for independent steps.
- **Scope** blocks for grouping and error handling.
- **Run after** configuration on any action — run only if the previous failed, succeeded, was skipped, or timed out.
Error handling is where many flows fall down. Configure **Run after** on key actions so failure paths log to a SharePoint list, post to Teams, or escalate to a human.
## Child flows
A **child flow** is a flow that another flow can call. They live in **solutions** (a packaging unit), accept parameters, and return values. Use them to factor out reusable patterns — "send a notification," "create a ticket" — once and call them everywhere.
## Approvals
The **Approvals** action triggers an approval request that the recipient can act on from Outlook, Teams, or the Power Automate mobile app. Approvals can be sequential or parallel, with multiple approvers and configurable response options. Built on a shared Dataverse table behind the scenes.
## Licensing gotchas
The licensing model has changed several times:
- **Standard connectors** in-suite are included with Microsoft 365, with a fairly generous per-user run allowance.
- **Premium connectors** (SQL, HTTP, the on-premises data gateway, Dataverse) require **Power Automate Premium** licensing. The **on-premises data gateway** is the small Windows service that lets a cloud flow reach an on-prem SQL Server, file share, or internal API without exposing it to the internet — install it on a server with reliable connectivity (not a laptop that sleeps), and for anything beyond a single-user proof of concept use **standard mode**, which supports multiple users and data sources through one gateway rather than the single-user **personal mode**.
- **Per-flow licensing** is available for flows shared by many users where buying per-user doesn't fit.
- **Pay-as-you-go** through an Azure subscription is increasingly the pragmatic answer.
The most common surprise: a flow that uses a premium connector consumes premium runs from anyone who invokes it — and they all need licensing.
## Patterns that work
- Use **scope blocks** for error handling.
- Send a **Teams adaptive card** for approvals instead of email — better UX, richer responses.
- For long-running flows, prefer **state in Dataverse** over flow variables.
- For high-volume scenarios, **child flows with parallel runs** scale better.
- Always **log to a known place** so flow failures are visible.
Cloud flows are how a tenant's Microsoft 365 quietly becomes much more automated. Treat them as code: version-controlled in solutions, tested, monitored.
---
# Power Automate desktop flows and RPA
URL: https://www.solvingmicrosoft365.com/guides/power-automate-desktop-flows-rpa
Category: Power Platform
Published: 2026-05-01
> Desktop flows automate UI on Windows machines — Microsoft's robotic process automation capability inside Power Automate.
**Desktop flows** are Power Automate's **robotic process automation (RPA)** capability. They automate the **user interface** of Windows applications — clicking buttons, typing text, navigating menus, extracting data — for systems that don't have a proper API. They're the bridge between modern API-driven automation and legacy thick-client apps that aren't going away soon.
## What desktop flows can do
A desktop flow runs as a sequence of **actions** that operate on a Windows session:
- **UI automation** — click, type, drag, focus, wait for, find — against Windows apps (Win32, UWP, Java, mainframe terminals).
- **Browser automation** — drive Edge, Chrome, Firefox to fill forms, click links, scrape data.
- **Excel automation** — open files, read/write cells, run macros.
- **File and folder operations** — manipulate files, ZIP archives, PDFs.
- **OCR and document parsing** — extract data from PDFs and images.
- **Email** — Outlook desktop COM-level automation.
- **Database queries** — direct SQL connections.
- **Scripting** — embed PowerShell, Python, JavaScript, VBScript.
The authoring tool is **Power Automate for desktop** — a separate Windows app, not the browser-based cloud flow designer.
## Attended vs unattended
- **Attended** — the flow runs interactively on the user's signed-in machine. Good for assisted scenarios where the user kicks off a flow and stays nearby.
- **Unattended** — the flow runs on a dedicated machine without a user signed in. Used for true RPA — overnight batch processes, hands-off automation. Requires a Power Automate Unattended RPA add-on.
## Machine management
Unattended flows run on **machines** registered with Power Automate. The machines are typically dedicated Windows VMs in your network. Each machine signs in to the Power Automate service and accepts run requests. **Machine groups** distribute load across pools.
## Hosted RPA
A newer option: **Power Automate Hosted RPA** runs unattended flows on **Microsoft-hosted Windows machines** — no infrastructure for you to manage. Best for low-to-medium throughput scenarios where the cost of running your own RPA VMs outweighs the per-run cost of hosted execution.
## Where desktop flows shine
- Legacy systems with no API (SAP green-screen, AS400 emulators, ancient ERP).
- Excel-heavy back-office processes.
- Tools where vendors charge a fortune for API access.
- Sequences that span multiple apps with no common integration.
## Where to be cautious
- Desktop flows are **brittle** by nature. A UI change in the target system can break the flow.
- They're **single-threaded** on a machine — RPA throughput scales by adding machines.
- They require **monitoring** because failures aren't always obvious.
- They don't replace proper integration work — they're a stop-gap.
A good principle: if the target system has an API, use a cloud flow with a custom connector. Use RPA only when there's no other way.
## Licensing
Desktop flows attended mode is included with **per-user Power Automate licensing**. Unattended mode requires the **Unattended RPA add-on** or pay-as-you-go pricing. Each unattended bot is licensed separately.
For tenants with significant legacy software, desktop flows can be transformative. Treat them as the legacy-bridging tool they are.
---
# Power Automate error handling patterns
URL: https://www.solvingmicrosoft365.com/guides/power-automate-error-handling
Category: Power Platform
Published: 2026-05-01
> How to make flows robust to failure — Run After, Try/Catch, retries, logging, and alerting.
Power Automate flows that work in development but break in production usually fail because of **inadequate error handling**. Network timeouts, API rate limits, missing data, permissions changes — production reality is full of edge cases that dev environments don't surface. Robust flows handle them deliberately.
## The Run After mechanism
Every action in a flow has a **Run After** setting that controls when it executes based on the previous action's outcome:
- **Is successful** (default) — run only if previous succeeded.
- **Has failed** — run only if previous failed.
- **Is skipped** — run only if previous was skipped.
- **Has timed out** — run only if previous timed out.
Setting **Run After Has failed** on a logging action gives you a "catch" branch:
```
[Action that might fail]
├── (default) → continue with main flow
└── (run after failure) → log to SharePoint, notify Teams, exit gracefully
```
## Scopes as try/catch blocks
A **Scope** action groups several actions. The whole scope can have a Run After configuration. This gives you try/catch:
```
Scope: Try
Action 1
Action 2
Action 3
Scope: Catch (Run after Try fails)
Log failure
Notify owner
Scope: Finally (Run after Try succeeds OR Catch runs)
Cleanup
```
The pattern matches familiar try/catch/finally from imperative languages. Use it liberally; most production flows benefit.
## Retry policies
Most connector actions have built-in **retry policies** for transient failures (network blips, throttling). Configurable per action:
- **Default** — Microsoft's recommended retries.
- **None** — no retries.
- **Exponential** — exponential backoff with configurable initial interval and max retries.
- **Fixed** — fixed-interval retries.
For idempotent actions (reading data, creating records that won't duplicate), enable generous retries. For non-idempotent actions (sending email, posting to Teams), be careful — retries can produce duplicates.
## Throttling and rate limits
Microsoft 365 connectors throttle aggressively at scale. A flow that runs once an hour is fine; a flow processing 10,000 records concurrently will throttle.
Mitigations:
- **Use Apply to each with concurrency control** to limit parallel execution.
- **Add delays** between iterations.
- **Batch operations** where the connector supports it.
- **Cache data** so you're not re-reading the same source repeatedly.
## Idempotency
Design flows so re-running them produces the same result as running once. For actions that change state:
- **Check if already done** before doing — "is this Planner task already created? if so, update; if not, create."
- **Use idempotency keys** — append a unique identifier to operations so retries don't duplicate.
This makes recovery from partial failures easy: just rerun the flow.
## Logging
Production flows benefit from a **structured logging** pattern:
- Send all errors to a **central SharePoint list** or Dataverse table — date, flow name, error message, affected record.
- **Notify the owner** for critical failures via Teams or email.
- **Dashboard the log** in Power BI — visibility into flow health.
Power Automate's built-in run history is per-flow; centralising errors makes them easier to spot across many flows.
## Alerting
Critical flows need active alerts on failure, not just logs. Patterns:
- **Teams notification** to a dedicated channel.
- **PagerDuty / Opsgenie** for incident response.
- **Email to the owner**.
Configure these in the catch scope.
## Monitoring as code
For mature deployments, the **CoE Starter Kit** provides cross-flow monitoring dashboards. Logic Apps and Application Insights integration gives even deeper telemetry for high-volume flows.
## When to graduate to a real platform
Power Automate excels at low-to-medium-volume orchestration with rich connectors. For very high-volume, latency-sensitive, complex error-handling scenarios:
- **Azure Logic Apps** — same engine, more enterprise features.
- **Azure Durable Functions** — for orchestrations requiring code.
- **Custom services** — for the highest-volume real-time scenarios.
For most Microsoft 365 automation, Power Automate plus good error-handling patterns is enough. The investment in robust patterns pays back the first time a critical flow fails at 2am.
---
# Power Automate Process Mining
URL: https://www.solvingmicrosoft365.com/guides/power-automate-process-mining
Category: Power Platform
Published: 2026-05-01
> Process Mining analyses event-log data to discover real-world business processes and identify automation opportunities.
**Power Automate Process Mining** (the merged successor of **Minit** and the older Process Advisor) is the Power Platform's tool for **discovering business processes from event log data**. Where Power Automate is for **building automation**, Process Mining is for **figuring out what to automate** by looking at how work actually happens, not how anyone thinks it happens.
## How process mining works
The tool takes an **event log** — a table of events with at least:
- A **case ID** (an order number, a ticket ID, a customer interaction).
- An **activity name** (the step that happened).
- A **timestamp**.
…plus any other contextual fields (who performed the activity, region, value, status). From this, the engine reconstructs the **actual process flow** — every variation, every loop, every bottleneck.
The result is a **process map** that shows:
- The **happy path** — the most common variation.
- All the **other paths** — the long tail of deviations, exceptions, rework loops.
- **Bottlenecks** — steps that take disproportionate time.
- **Conformance** — how often the actual process matches the documented process.
- **Cost and time** drivers — which paths and variations consume the most resources.
This is usually a revelation. The documented process always looks linear and tidy; the actual process has dozens of variations the documented version doesn't mention.
## Two flavours
- **Task Mining** — a Power Automate Desktop client records what users actually do on their screens (with their consent), turning UI activity into an event log. Discovers desktop tasks ripe for RPA automation.
- **Process Mining** — uses pre-existing event logs from business systems (ERP, CRM, ticketing systems, custom apps). Discovers end-to-end processes for redesign or automation.
Often used together: process mining identifies the slow process; task mining identifies the manual UI work inside it.
## What it's used for
- **Identifying automation targets** — what's the highest-ROI process to automate?
- **Process improvement projects** — re-engineering existing processes based on real data.
- **Audit and compliance** — proving that a process actually follows its documented controls.
- **M&A integration** — comparing process variations between merged organisations.
- **Customer journey analysis** — turning customer event logs into journey maps.
## Where Process Mining fits in the Power Platform
The product line:
- **Process Mining** discovers the process.
- **Power Automate cloud flows** automate the digital parts.
- **Power Automate desktop flows** automate the UI parts (RPA).
- **Power Apps** replaces manual UIs with purpose-built apps.
- **Copilot Studio agents** add AI-driven assistance to the process.
A typical project: mine the process, identify the slowest manual steps, automate them with cloud flows + RPA, replace the worst manual UI with a Power App, and add a Copilot for the human-judgement steps. Then re-mine to measure improvement.
## Licensing
Process Mining requires a **Power Automate Premium** licence or a standalone Process Mining add-on. Task Mining is typically bundled with Power Automate Premium plans. Cloud capacity for processing event logs has separate consumption pricing.
For organisations with significant operational processes — finance close, order-to-cash, hire-to-retire, complaint handling — process mining often reveals more automation opportunities than years of internal improvement work surfaced.
---
# Power BI content certification and endorsement
URL: https://www.solvingmicrosoft365.com/guides/power-bi-certification-and-endorsement
Category: Power Platform
Published: 2026-05-01
> How endorsement and certification surface trusted content in Power BI and Fabric — and the operational programme behind it.
In organisations with mature Power BI usage, dozens to hundreds of reports and semantic models exist. Users struggle to know which are **authoritative** — which to use, which to trust, which to build on. **Endorsement** is the Power BI / Fabric mechanism for designating trusted content; **certification** is the most formal level. Used well, it dramatically improves report-discovery and reduces "everyone builds their own version of revenue."
## The endorsement levels
Power BI / Fabric supports three states:
### Not endorsed
The default — content the author created, not formally vetted. Most content sits here. Fine for personal exploration; doesn't carry weight as authoritative.
### Promoted
Content the author or their team **promotes** as a useful broader resource. Self-service endorsement — the content owner says "this is worth others using." No formal review required.
Useful for:
- **Team-shared models** the team uses internally.
- **Departmental content** of broader interest.
### Certified
Content **certified by a designated authority** (typically the Power BI / Fabric admin team or a Centre of Excellence) as authoritative.
Used for:
- **Single source of truth** semantic models that the organisation should standardise on.
- **Reports and dashboards** with executive consumption.
- **Reference dataflows** centrally maintained.
Certified content carries the strongest endorsement and is what users should default to using.
## Why endorsement matters
Without endorsement:
- **Five different "revenue" reports** exist; users don't know which to trust.
- **Multiple teams rebuild** the same data preparation.
- **Decisions get made on stale or unrepresentative data**.
- **New users wander** through content with no guidance.
With endorsement:
- **Certified content surfaces** prominently in user search.
- **Promoted content** appears next.
- **Users know** which content to start from.
- **Authoritative source** is unambiguous.
## The certification programme
Setting up certification requires operational discipline:
### Define standards
What does "certified" mean in your organisation? Examples:
- **Documented business rules** — model logic clearly explained.
- **Data lineage** — source-of-truth traceable.
- **Refresh schedule** verified and reliable.
- **Security model** implemented appropriately.
- **Performance** acceptable for expected user load.
- **Owner accountable** for the content.
### Designate certifiers
Who can certify content?
- **Power BI / Fabric administrators** — typically a small group.
- **CoE team** — Centre of Excellence designation.
- **Business-domain experts** in some organisations.
Configure in **Power BI admin portal → Tenant settings → Certification**.
### Submission and review process
For content to become certified:
1. **Author submits** content with documentation.
2. **Certifier reviews** against standards.
3. **Feedback** if changes needed.
4. **Certification applied** when standards met.
5. **Periodic recertification** — annual review.
Without process discipline, certification either doesn't happen or proliferates.
### Communicate the programme
- **Documentation** of what certification means and how to get it.
- **Training** for authors on the certification path.
- **Onboarding new authors** explaining the programme.
## Operational considerations
- **Don't over-certify** — if everything is certified, certification means nothing.
- **Don't under-certify** — too few certified items means users still wander.
- **Maintain certified content** — certified content that goes stale erodes trust.
- **Recertification cadence** — at least annually.
- **Decertification path** — content that no longer meets standards gets demoted.
## Featured content
Beyond endorsement, **featured content** is a separate concept:
- Specific content **pinned** as visible to all users.
- Shows up in users' Home / Featured sections.
- Used for organisation-wide priority content.
Featured + certified is a powerful combination — high-trust, high-visibility.
## Sensitivity labels for analytics
Combine endorsement with **sensitivity labels** on semantic models and reports:
- Certified models with appropriate sensitivity labels.
- Labels travel with exports (Excel exports inherit the label).
- DLP policies can act on labelled analytics content.
This produces a coherent governance picture — content is endorsed AND classified.
## Cultural shift
The biggest barrier to a certification programme isn't tooling — it's culture. Common challenges:
- **Authors don't want certification overhead**.
- **No clear owner** for the certification process.
- **Standards too strict** — nobody gets certified.
- **Standards too loose** — everything gets certified.
- **No enforcement** — uncertified content gets used anyway.
A working programme balances rigor with accessibility. Iterate.
## Where this fits
For organisations with 10+ Power BI authors and many shared reports, certification is one of the highest-leverage governance investments. The cost is operational (the review process); the benefit is durable trust in shared analytics.
For organisations still in early Power BI adoption, certification can wait — first establish the practice; then add governance.
Power BI / Fabric certification programmes mature over time. Start with promoted content (low overhead); evolve to formal certification as your analytics culture matures.
---
# Power BI dataflows and Fabric dataflows
URL: https://www.solvingmicrosoft365.com/guides/power-bi-dataflows
Category: Power Platform
Published: 2026-05-01
> How dataflows centralise data preparation across many Power BI semantic models and reports.
**Dataflows** in Power BI / Microsoft Fabric centralise **data preparation** logic so many downstream semantic models can consume the same shaped, cleaned data without re-doing the work. For organisations with mature BI practice, dataflows are where ETL lives — once authored, reused everywhere.
## What a dataflow is
A dataflow is essentially **Power Query running in the cloud** on a schedule:
- **Source connections** to your data (SQL Server, SharePoint, REST APIs, dozens of other sources).
- **Transformations** in Power Query M language (filter, transform, merge, calculated columns).
- **Refresh schedule** (hourly, daily, etc.).
- **Output** as **entities** that semantic models can query.
The pattern: dataflow produces **clean, modelled tables**; multiple semantic models import or DirectQuery from those tables; reports build on the models. Dataflow logic isn't repeated across every model.
## Power BI dataflows vs Fabric Dataflow Gen2
The dataflow product has evolved:
### Power BI dataflows (Gen1)
The original Power BI dataflows. Stored in:
- **Workspace's underlying storage** (typically a Common Data Service Lake or Azure Data Lake Storage Gen2 in Premium scenarios).
- Outputs are **entities** consumed by Power BI Desktop or other dataflows.
Still supported; broadly used.
### Dataflow Gen2 in Fabric
The newer dataflow capability in Microsoft Fabric:
- **Same Power Query authoring** experience.
- **Destination flexibility** — output to OneLake lakehouses, Fabric warehouses, Azure SQL, Azure Data Lake, on-prem SQL Server.
- **Direct Lake mode** for downstream semantic models.
- **Better performance** for larger datasets.
- **Integrated with Fabric workspace** and pipeline scheduling.
For new development in Fabric tenants, Gen2 is the strategic choice. Existing Gen1 dataflows continue working.
## Common use cases
### Centralised dimension data
A **Date table** consumed by every analytical model:
- Author once as a dataflow.
- Refreshes daily.
- Every model imports the same Date table.
- Consistent date hierarchies across all reports.
Beats every model creating its own date table.
### Pre-shaped fact tables
A **Sales fact table** at standardised granularity:
- Source from raw sales database with multiple joins.
- Apply business rules (currency conversion, regional groupings).
- Output as a clean fact table.
- Multiple sales reports build on the same dataflow output.
### Combined source data
Customer data from CRM + ERP + customer-service system, combined into one clean Customer table.
### Slowly Changing Dimensions (SCD)
Type 2 SCD handling in dataflows produces correct historical-attribute versioning that downstream models inherit.
## Authoring
Dataflows are authored in the **Power BI Service** or **Microsoft Fabric** browser experience:
1. **Create dataflow** in the relevant workspace.
2. **Connect to sources** — same connector library as Power BI Desktop.
3. **Apply transformations** using Power Query M.
4. **Save and refresh** to populate the entities.
Power Query Desktop can be used for some development and import; the cloud-hosted authoring is the standard.
## Refresh schedule
Dataflows refresh on schedule independently from downstream semantic models:
- **Dataflow refreshes nightly** at 02:00.
- **Semantic models that consume it** refresh at 03:00 — they get the freshly-prepared data.
- **Reports** built on the semantic models reflect current data when users open them.
Layered refresh schedule keeps the pipeline current.
## Linked entities
A dataflow's output can be **consumed by another dataflow** — chain transformations:
- **Source dataflow** ingests raw data.
- **Transformation dataflow** further processes.
- **Final dataflow** applies business-specific shaping.
Useful for separating concerns — source ownership vs business modelling vs report-ready data.
## Operational considerations
- **Workspace governance** — who can create / edit dataflows, who can consume.
- **Refresh monitoring** — failures should alert.
- **Performance** — large dataflows can take hours; tune Power Query for query folding.
- **Cost** — Fabric capacity consumes CUs during refresh; Premium dataflows use Premium capacity.
- **Source-of-truth labelling** — document which dataflows are authoritative.
## When dataflows aren't the right tool
- **One-off transformations** for a single model — just do it in the model, no dataflow needed.
- **Real-time data** — dataflows refresh on schedule, not streaming. For real-time, use Real-Time Analytics in Fabric.
- **Heavy data engineering** at petabyte scale — use Spark notebooks or warehouses in Fabric.
For organisations with multiple analysts authoring related reports, dataflows are how you avoid the "every report has its own ETL" problem. Author once; consume everywhere; standardise across the BI estate.
---
# Power BI deployment pipelines
URL: https://www.solvingmicrosoft365.com/guides/power-bi-deployment-pipelines
Category: Power Platform
Published: 2026-05-01
> How to manage Power BI content lifecycle with deployment pipelines — dev, test, production.
For Power BI content used by many people, treating reports as production artefacts — with development, testing, and controlled promotion — beats the "edit in production" approach that's the default for casual users. **Deployment pipelines** in Power BI provide a structured dev-test-prod model for semantic models and reports.
## What a pipeline gives you
A Power BI deployment pipeline has three stages:
1. **Development** — authors edit semantic models and reports.
2. **Test** — content is promoted here for validation; testers verify accuracy without touching production data.
3. **Production** — consumers see content here; minimal change frequency.
Each stage is a **separate Power BI workspace** with the same set of content. Content is **promoted** from dev to test to prod via the deployment pipeline UI or API.
## The promotion model
Promoting content does several things:
- **Copies** the dataset and report from the source stage to the target stage.
- **Rebinds data source connections** based on **deployment rules** — e.g., dev points at the dev database, prod points at the prod database.
- **Preserves identity** of content — the production report's URL doesn't change just because a new version was promoted; users stay bookmarked.
- **Audits** the change with who, when, what.
This is fundamentally different from the "edit in place in production" workflow that's the default. With pipelines, production gets explicit, reviewed updates.
## Deployment rules
The trick to making pipelines work for multi-environment data sources is **deployment rules**:
- **Data source rules** rebind connections per stage — dev semantic model connects to dev SQL; on promotion to prod, it rebinds to prod SQL.
- **Parameter rules** substitute parameter values per stage.
Without deployment rules, you'd have separate semantic models per stage with hard-coded connections. With them, one model file moves through stages with appropriate environment-specific config.
## When pipelines are right
Pipelines are most valuable for:
- **Production-critical reports** consumed by many users.
- **Reports built on multi-environment data** (dev SQL, prod SQL).
- **Regulated environments** requiring documented change control.
- **Teams of report authors** needing collaboration without stepping on each other.
For ad-hoc personal reports or one-off analyses, pipelines add overhead without benefit. Use them where the cost-benefit clearly tilts toward structure.
## Workspace structure
The pipeline stages each live in a separate workspace. Naming conventions help:
- `MarketingDashboard [Dev]`
- `MarketingDashboard [Test]`
- `MarketingDashboard [Prod]`
Consumers only know about Prod. Authors work in Dev. Testers validate Test.
## Permissions
Each workspace has its own permissions:
- **Dev** — authors edit.
- **Test** — testers (often the authors plus business stakeholders) validate.
- **Prod** — consumers view; only specific people can promote into prod.
This is the right pattern for production governance.
## Source control and pipelines
A newer evolution: **Microsoft Fabric Git integration** lets the dev workspace sync to a Git repository. Authors work in feature branches, commits PR-reviewed before merging. This is **source-controlled BI development** finally arriving — the missing piece that's bedevilled Power BI deployments for years.
Combined with pipelines, the workflow becomes: code review the change in Git, deploy to test via the pipeline, validate, promote to prod. All audited.
## Licensing
Deployment pipelines require **Power BI Premium** capacity, **Premium Per User (PPU)**, or **Microsoft Fabric capacity** — same tier that's needed for many other production BI features.
For organisations with multiple report authors and production-critical Power BI content, deployment pipelines plus Git integration are how Power BI is finally maturing into a real production-engineering platform.
---
# Power BI, Microsoft Fabric, and semantic models
URL: https://www.solvingmicrosoft365.com/guides/power-bi-fabric-and-semantic-models
Category: Power Platform
Published: 2026-05-01
> How Power BI fits inside Microsoft Fabric — semantic models, Direct Lake, OneLake, and the unified data platform.
In 2023 Microsoft launched **Microsoft Fabric** — a unified data platform that subsumes Power BI alongside the rest of the Azure data stack. For Microsoft 365 customers using Power BI, Fabric isn't a replacement but a superset: Power BI capacity is now Fabric capacity, and new architectural patterns are built on Fabric primitives.
The platform underneath is described in [Microsoft Fabric explained](/guides/microsoft-fabric-explained); licensing is in [Power BI Pro vs PPU vs Fabric capacity](/guides/power-bi-pro-vs-ppu-vs-fabric), data preparation in [dataflows](/guides/power-bi-dataflows), and model design in [semantic model design](/guides/power-bi-semantic-model-design).
## What Fabric provides
Fabric bundles several previously separate Microsoft data products into one platform:
- **OneLake** — a single unified data lake for the whole tenant, automatically organised by workspace.
- **Data Factory** — pipelines and dataflows for data integration.
- **Synapse Data Warehouse** — SQL-based warehouse.
- **Synapse Data Engineering** — Spark notebooks and lakehouses.
- **Synapse Data Science** — ML workflows.
- **Real-Time Analytics** — KQL-based streaming.
- **Power BI** — reports and semantic models.
- **Data Activator** — event-driven actions on data thresholds.
All run on shared **Fabric capacity** (F-SKUs), licensed by capacity rather than per-user for many features.
## Semantic models
What were called **datasets** in Power BI are now **semantic models** in Fabric. A semantic model is the reusable definition of tables, relationships, measures, and calculations that one or many Power BI reports consume.
The naming change isn't cosmetic — Microsoft is pushing semantic models as **first-class enterprise data products**, not just per-report artefacts. Features include:
- **Composite models** — mix imported and DirectQuery data in one model.
- **Calculation groups** — reusable calculation patterns (time intelligence, currency conversion).
- **Hybrid tables** — recent data DirectQuery for freshness, historical data imported for performance.
- **Object-level security** — hide entire tables or columns from specific users.
- **Row-level security (RLS)** — filter rows per user role.
## Direct Lake
**Direct Lake** is a Fabric-only mode for Power BI semantic models: instead of importing data (long refresh times, copy of data) or DirectQuery (live but slower), the semantic model **reads OneLake Parquet files directly into memory** on demand. The result is import-like performance with live data freshness, scaling to very large datasets.
For models built against Fabric Lakehouses or Warehouses, Direct Lake is the default and usually the right choice.
## OneLake and shortcuts
**OneLake** is the unified data lake automatically provided by Fabric, organised hierarchically by tenant and workspace. **Shortcuts** let you mount external data (Azure Data Lake Storage, S3, Google Cloud Storage, Dataverse) into OneLake without copying — Fabric reads through them.
This makes Power BI semantic models source-agnostic: the lakehouse can be a mix of native Fabric data and external lakes, and the model doesn't care.
## What changes for Power BI customers
If you're running Power BI Pro and Premium today:
- **Power BI Pro** stays a per-user licence for sharing and viewing.
- **Premium Per User (PPU)** continues for individual contributors needing premium features.
- **Premium capacities (P-SKUs)** are being replaced by **Fabric capacities (F-SKUs)** — same compute but consolidated billing and access to all Fabric workloads.
- **New features** are increasingly Fabric-only — Direct Lake, Data Activator, Copilot in Fabric.
For organisations with serious analytics ambition, planning a path to Fabric is increasingly the default. For lighter Power BI use, the existing per-user model still works.
---
# Power BI paginated reports
URL: https://www.solvingmicrosoft365.com/guides/power-bi-paginated-reports
Category: Power Platform
Published: 2026-05-01
> Paginated reports cover the print-and-export scenarios that interactive Power BI reports don't — invoices, statements, fixed-layout reporting.
**Paginated reports** in Power BI cover the report category that interactive Power BI reports don't handle well: **pixel-precise, fixed-layout, multi-page reports** suitable for printing or exporting to PDF. Invoices, statements, regulatory filings, multi-page financial reports, formal exports — paginated is where they live.
## Paginated vs interactive
Power BI's flagship product is interactive dashboards — drill, filter, slicer, visual exploration. That's fundamentally different from paginated:
- **Interactive reports** — slice and dice in the browser, exploratory, no fixed pagination.
- **Paginated reports** — every record gets its own page (or pages), with strict layout control, perfect for print or PDF export.
A monthly invoice with a fixed header, line items table, and totals footer for each customer is a paginated report. A sales dashboard exploring trends across regions is an interactive report.
## Origins and tooling
Paginated reports are the successor to **SQL Server Reporting Services (SSRS)** reports. The file format (`.rdl`) is the same; SSRS .rdl files can be deployed to Power BI's paginated report service largely unchanged.
Authoring is done in **Power BI Report Builder** — a free Windows desktop tool, distinct from Power BI Desktop. Report Builder is designed for fixed-layout report authoring with bands (header, body, footer), tables, charts, sub-reports, and an expression language for dynamic content.
## When paginated is the right tool
- **Invoices and statements** — one per customer, generated on demand or in batch.
- **Multi-page financial reports** — balance sheets, P&Ls with controlled layout.
- **Regulatory filings** — fixed-format reports for compliance.
- **Letter/email generation** — mail-merge-style document creation.
- **Long detailed exports** — multi-page reports with thousands of records, paginated for navigation.
- **Print scenarios** — where the report must look right on paper.
For these, paginated is the only good option; trying to do them in interactive Power BI is awkward at best.
## When interactive is the right tool
- **Dashboards** — KPIs, trends, drill-down.
- **Exploratory analysis** — slicers, filters, what-ifs.
- **Mobile consumption** — interactive responds to mobile; paginated assumes paper-shaped output.
Most Power BI consumers spend their time in interactive reports. Paginated covers the specific scenarios interactive doesn't fit.
## Licensing
Paginated reports require:
- **Power BI Premium capacity**, **Premium Per User (PPU)**, or **Microsoft Fabric capacity** for consumption.
- **Power BI Report Builder** (free Windows app) for authoring.
Not available in standard Power BI Pro consumption — a sometimes-surprising licensing constraint.
## Deployment
Authored `.rdl` files are uploaded to Power BI workspaces (same as PBIX files). Permissions, sharing, and pipelines work the same as interactive reports.
For organisations migrating from SSRS to Power BI, paginated reports are the bridge — your existing SSRS .rdl portfolio largely runs as-is in Power BI's paginated service.
## Operational realities
- **Performance** — paginated reports executing against large queries can be slow; design for set-based queries and avoid row-by-row processing.
- **Subscriptions** — paginated reports can be subscribed to for scheduled email delivery as PDF / Excel / Word.
- **API automation** — Power BI REST APIs let you trigger paginated report rendering programmatically; great for bulk PDF generation.
For Microsoft 365 customers with reporting needs that exceed interactive Power BI's scope, paginated reports are a mature, capable option for the print-and-export half of the business intelligence problem.
---
# Power BI Pro vs Premium Per User vs Fabric capacity
URL: https://www.solvingmicrosoft365.com/guides/power-bi-pro-vs-ppu-vs-fabric
Category: Power Platform
Published: 2026-05-01
> Choosing between Power BI licensing tiers — Pro, PPU, and Microsoft Fabric capacity for different scenarios.
Power BI licensing has three main forms — **Pro**, **Premium Per User (PPU)**, and **Microsoft Fabric capacity (F-SKUs)**. Each fits different scenarios. Knowing which to pick saves money and avoids capability gaps.
## Power BI Pro
The baseline shared-content licence:
- **Per-user per month** — affordable.
- **Authoring rights** — create and share reports.
- **Consumption rights** — view shared reports.
- **Workspace sharing** with other Pro users.
- **Sharing with consumers** — recipients need Pro to view (unless Premium / Fabric is in play).
What Pro **doesn't** include:
- Advanced features like incremental refresh on large models, AI features, paginated reports, deployment pipelines.
- Sharing with users who don't have a Power BI licence.
The right tier for **collaborative BI within small-to-medium teams** where all users have Power BI licences.
## Power BI Premium Per User (PPU)
A step up from Pro at higher per-user cost:
- **Everything Pro includes**.
- **Advanced features** — incremental refresh, larger models, paginated reports, AI features.
- **Deployment pipelines**.
- **XMLA endpoint** for external-tool access.
What PPU **doesn't** include:
- Sharing with users who don't have a Power BI licence (PPU isn't enough; consumers still need PPU or Pro or capacity).
The right tier for **individual heavy users** wanting Premium-level features without needing dedicated capacity. Useful for analyst teams who author complex content but don't need to share with non-licensed consumers.
## Microsoft Fabric Capacity (F-SKUs)
Dedicated shared compute backing many workloads:
- **Capacity-based** rather than per-user — pay for the compute, license fewer users.
- **Includes Power BI Premium capabilities**.
- **Plus the broader Fabric platform** — Data Factory, Synapse Data Warehouse, Synapse Data Engineering, Real-Time Analytics, Data Activator.
- **Sharing with non-licensed consumers** — when content is in a Fabric-capacity workspace, you can share with users who don't have Power BI Pro / PPU.
Capacity sizes: **F2, F4, F8, F16, F32, F64, F128, F256, F512, F1024, F2048** — corresponding to Capacity Units.
Can be **paused** when not in use (no charges); resumed on demand. Scale up / down between sizes.
The right tier for:
- **Large user populations** where licensing everyone per-user is more expensive than capacity.
- **Organisations building on the broader Fabric platform** — data engineering, real-time analytics, warehouse alongside BI.
- **Sharing with broad audiences** including unlicensed users.
## How to choose
| Scenario | Right licensing |
| --- | --- |
| Small analyst team sharing reports among themselves | Power BI Pro |
| Individual analyst needing Premium features | PPU |
| Heavy report consumer base with 500+ viewers | Fabric capacity (F64+) |
| Building on Fabric for data engineering | Fabric capacity |
| Mixed authoring and consumption | Pro for authors, capacity for consumption |
## Per-user vs capacity break-even
A rough rule:
- **Under ~50 viewers per Pro author** — per-user Pro is cheaper.
- **More than ~50 viewers per author** — capacity becomes cheaper because viewers don't need individual licences.
Real break-even depends on actual user counts, viewer engagement, and current pricing. Calculate explicitly.
## Microsoft Fabric SKU sizing
Fabric capacity sizing depends on workload:
- **Reporting only** — small Fabric capacity (F8–F64) often sufficient for hundreds of report consumers.
- **Plus dataflows and modelling** — larger (F128+) to handle the compute.
- **Plus data engineering / warehousing** — F256+ for substantial workloads.
Microsoft provides capacity-planning calculators. Start smaller, scale up based on observed usage.
## Migration paths
- **From Pro to PPU** — add the PPU licence to specific users wanting advanced features.
- **From Pro to Fabric capacity** — assign workspaces to the Fabric capacity. Users keep Pro for authoring; viewers stop needing licences.
- **From Premium P-SKU to Fabric F-SKU** — Microsoft has migration paths; the new F-SKUs supersede the old P-SKUs.
## Operational considerations
- **Capacity utilisation monitoring** — Fabric admin centre tracks utilisation; over-utilised capacities throttle, under-utilised waste money.
- **Workspace placement** matters — assigning workspaces to capacities is the operational lever.
- **Pause unused capacities** — auto-pause during off-hours saves significantly.
- **License usage audit** — track who's actually authoring vs consuming; right-size accordingly.
For organisations growing serious Power BI investment, the licensing decision is consequential. Start with Pro; add PPU for heavy users; move to Fabric capacity when viewer counts justify it.
---
# Power BI row-level and object-level security
URL: https://www.solvingmicrosoft365.com/guides/power-bi-rls-and-ols
Category: Power Platform
Published: 2026-05-01
> How RLS and OLS restrict what users see in Power BI semantic models — the patterns and the pitfalls.
For Power BI semantic models shared across many users, controlling **what each user is allowed to see** is essential. Two related features handle different cases: **Row-Level Security (RLS)** filters rows; **Object-Level Security (OLS)** hides entire tables or columns.
## Row-Level Security (RLS)
RLS filters the rows visible to a user based on a **DAX expression** that runs in the user's context. Common patterns:
- A salesperson sees **only their own customers** — `[SalesRep] = USERNAME()`.
- A regional manager sees **only their region** — `[Region] = LOOKUPVALUE(...)`.
- An executive sees **all rows** — granted a role with no filter.
### How RLS works
RLS is defined in Power BI Desktop with **roles**:
1. Modelling tab → Manage roles → New role.
2. Define a **DAX filter** on each table where rows should be filtered.
3. Assign **users or Entra ID groups** to roles in the Power BI Service.
When a user opens a report, Power BI evaluates which roles they're in, applies the union of their filters, and filters every visual accordingly.
### Static vs dynamic RLS
- **Static RLS** — role assignment is by user group. "Sales East role" filters to East region.
- **Dynamic RLS** — the filter uses `USERNAME()` or `USERPRINCIPALNAME()` and looks up the current user's permitted scope from a security table in the model.
Dynamic is more flexible — adding a new sales rep doesn't require touching role definitions. Just add them to the security table.
### Testing RLS
Power BI Desktop lets you **view the report as a specific role or user** before publishing. Essential for validation.
### Common pitfalls
- **DirectQuery RLS** — works but each visual generates filtered SQL; performance varies.
- **Cross-filtering relationships** — RLS on one table propagates via relationships; verify the expected filtering occurs everywhere.
- **Many-to-many** complexity — RLS interacts with composite filter logic in non-obvious ways. Test thoroughly.
- **Service principals and embedded scenarios** — RLS evaluates differently when the report is embedded in an app via a service principal. Use the **effective identity** feature in the embedding code.
## Object-Level Security (OLS)
OLS hides **entire tables or columns** from users in specific roles, rather than filtering rows.
Use cases:
- **HR salary data** — hide the salary column from non-HR users.
- **Internal cost data** — hide cost tables from sales users.
- **Confidential metadata** — hide auditing columns from regular users.
### How OLS works
Defined in **Tabular Editor** (an external tool, free): mark specific tables or columns as visible only to specific roles. Users not in those roles can't even see the column exists — visuals referencing it would fail.
For users in roles where a column is hidden, **measures referencing the hidden column also fail**. This can break dashboards in non-obvious ways; verify carefully.
### When OLS is right
- Truly confidential columns / tables that some users shouldn't even know exist.
- Compliance scenarios where filtered rows aren't enough — the field itself must be invisible.
### When OLS isn't right
- If filtering would suffice — RLS is simpler.
- If "out of scope" means "show as null/N/A" — a calculated column with conditional logic is friendlier than OLS.
## Combined RLS + OLS
The two can be combined: filter rows AND hide columns based on role. A sales rep sees their own customers (RLS) and doesn't see the cost column (OLS).
## Operational considerations
- **Source-of-truth security tables** — for dynamic RLS, the security table should be authoritative and well-maintained. Stale data here means wrong access.
- **Documentation** — document the role definitions and the security model. Without docs, future maintainers won't know how access works.
- **Audit** — Power BI logs which users access which reports; combined with role memberships, you can audit who saw what.
- **Service principals** — for embedded scenarios, the embedding app's code controls the effective identity. Get this right.
For Power BI semantic models with mixed-sensitivity data shared across heterogeneous audiences, RLS and OLS are how you serve everyone without proliferating the model. Built once, applied consistently, audited centrally.
---
# Power BI semantic model design
URL: https://www.solvingmicrosoft365.com/guides/power-bi-semantic-model-design
Category: Power Platform
Published: 2026-05-01
> How to design Power BI / Fabric semantic models for performance, usability, and reuse — star schemas, measures, and best practices.
A **Power BI semantic model** (formerly called a dataset) is the reusable data layer that reports and dashboards build on. Designed well, a semantic model serves many reports with consistent semantics and fast queries. Designed badly, every report is slow and inconsistent, and analysts hate it.
## Star schema as the foundation
The single most important design principle: **star schema**. Centre **fact tables** (transactional / event data) surrounded by **dimension tables** (descriptive lookup data):
- **Fact table**: Sales (one row per sale, with foreign keys to dimensions plus measures like quantity and revenue).
- **Dimension tables**: Date, Product, Customer, Region, SalesRep.
Avoid **flat denormalised tables** with everything joined together. Avoid **snowflake schemas** with dimensions normalised into multiple tables. Star schema beats both for Power BI's storage and query engine.
## Modelling principles
- **One fact table per business process** — Sales fact, Inventory fact, Orders fact. Don't try to combine.
- **Many fact tables can share dimensions** — Date dim shared across Sales, Inventory, Orders.
- **Dimensions before facts** — design the dimensions first; facts hang off them.
- **Surrogate keys** — integer keys in dimensions; foreign keys in facts. Better performance than natural keys.
- **Slowly changing dimensions (SCDs)** — when dimension values change (customer moves), decide whether to overwrite (Type 1) or version (Type 2).
## DAX measures vs calculated columns
Two ways to add calculations:
- **Calculated columns** — computed once per row, stored in the model. Use for row-level attributes that don't change with filter context.
- **Measures** — computed at query time based on current filter context. Use for aggregations and most analysis.
**Prefer measures over calculated columns** in almost all cases. Measures are recalculated efficiently; calculated columns bloat the model and don't respond to user filters.
## Naming conventions
- **Tables** — `Customer`, `Product`, `Sales` (singular, not `Customers`).
- **Columns** — `Customer Name`, `Product Category`, `Sales Amount` (proper case with spaces, user-facing).
- **Measures** — `Total Sales`, `YTD Sales`, `Sales Growth %` (descriptive, in their respective measure tables).
- **Hidden columns** — keys, internal columns hidden from users.
Good naming is the difference between a usable model and a confusing one.
## Measure tables
A common pattern: create a **measures table** (an empty placeholder table) and put all measures there. The model browser groups them visibly, separated from columns. For complex models with hundreds of measures, multiple measure tables organised by domain make navigation easier.
## Storage modes
Three modes per table:
- **Import** — data loaded into Power BI's in-memory engine. Fast queries, requires refresh.
- **DirectQuery** — queries pushed to the source server live. Always-current but slower per query.
- **Direct Lake** (Fabric only) — reads OneLake Parquet files directly into memory. Import-like performance with live freshness.
Choose per table. **Composite models** mix modes — fact table in Direct Lake (large, current), dimensions in Import (small, fast).
## Performance tuning
For models that feel slow:
- **Reduce model size** — remove unused columns; columns are the main memory consumer.
- **Disable auto date/time** — adds hidden date tables that bloat the model.
- **Use proper datatypes** — integer keys, not strings; date types, not datetime if time isn't needed.
- **Aggregation tables** — for large fact tables, pre-aggregated tables answer common queries faster.
- **Incremental refresh** — large fact tables refresh only the recent partition, not the whole table.
## Documentation
For semantic models consumed by many people:
- **Model description** in the workspace.
- **Column descriptions** for each column the user sees.
- **Measure descriptions** explaining what each measure means and how it's calculated.
- **Synonyms** for Q&A natural-language queries.
Good documentation lets users explore the model independently rather than asking the modeller every time.
## Reuse via dataflows
For shared transformations across many models, use **dataflows**:
- Define source queries and transformations once in a dataflow.
- Many semantic models consume the dataflow as their source.
- Refresh the dataflow once; all downstream models benefit.
For mature deployments, **dataflows feed certified semantic models which feed many reports**. Layered architecture; reuse at every layer.
## Certification
For enterprise-wide models, **promote** them to **Promoted** or **Certified** status in the workspace. Certified models appear in the user's quick-access list and signal "this is the right model to use" — reducing model sprawl.
## Operational considerations
- **Version control** — Power BI Desktop files (`.pbix`) are binary; treat as source artefacts. Microsoft Fabric Git integration changes this for the better.
- **Testing** — validate measure values against source data before publishing.
- **Capacity planning** — large models in Premium / Fabric capacities consume memory; track utilisation.
- **Refresh failures** — set up alerts for refresh failures.
For organisations doing serious Power BI at scale, semantic model design is the foundational craft. Time invested here pays back across every downstream report.
---
# Power BI workspace design
URL: https://www.solvingmicrosoft365.com/guides/power-bi-workspace-design
Category: Power Platform
Published: 2026-05-01
> How to structure Power BI workspaces for sharing, lifecycle, and governance at scale.
For organisations with serious Power BI usage — analysts publishing dozens to hundreds of reports — **workspace design** is one of the most consequential decisions. Wrong structure makes content hard to find, permissions hard to manage, and lifecycle a permanent burden. Right structure scales gracefully.
## What a workspace is
A **workspace** in Power BI / Microsoft Fabric is a container for content — reports, semantic models, dataflows, lakehouses, notebooks. It has:
- **Members** with roles (Admin, Member, Contributor, Viewer).
- **A capacity** — Pro, PPU, Premium, or Fabric F-SKU.
- **A region** — data residency.
- **A lifecycle** — creation, content, deprecation.
## Common workspace patterns
### Per-team workspace
Each business team has its own workspace where their analysts author and consume.
- Pros: clear ownership, simple permissions.
- Cons: cross-team content sharing requires careful planning.
### Per-domain workspace
A workspace per business domain (Finance, Marketing, HR, Operations).
- Pros: aligns to organisational structure, often more stable than per-team.
- Cons: cross-domain consumption needs explicit sharing.
### Layered architecture (data-source / semantic / report)
For mature deployments, separate concerns:
- **Source workspaces** with dataflows and lakehouses — the raw and shaped data.
- **Semantic model workspaces** — certified semantic models on top of the source data.
- **Report workspaces** per audience — reports built on the semantic models.
Layered separation lets data engineers own sources, modellers own semantics, and report authors own audience-facing reports. Promotes reuse.
### Per-project workspace
A workspace per project, deprecated when the project ends.
- Pros: clear lifecycle.
- Cons: cross-project content sharing painful.
Most organisations use a hybrid — domain workspaces for stable content, project workspaces for short-term work.
## Capacity assignment
Workspaces are assigned to a capacity tier:
- **My Workspace** — personal, Pro / PPU per user.
- **Pro workspace** — backed by Pro licenses; suitable for general team content.
- **Premium Per User (PPU)** — for individual heavy users wanting Premium features without dedicated capacity.
- **Premium / Fabric capacity** — dedicated capacity, shared by many workspaces; required for some advanced features.
For larger deployments, capacity planning becomes its own discipline — sizing the Fabric capacity for actual workload, monitoring utilisation, scaling up or out as needed.
## Permissions and access
The workspace roles:
- **Admin** — full control, including delete workspace.
- **Member** — manage content, publish, share.
- **Contributor** — publish content, but not manage workspace.
- **Viewer** — read-only access to content.
Best practice: **assign roles to Entra ID groups**, not individual users. Add and remove via group membership.
## Deployment pipelines
For production-critical content, **deployment pipelines** stage workspaces:
- `Marketing Dashboard [Dev]` — authors edit.
- `Marketing Dashboard [Test]` — testers validate.
- `Marketing Dashboard [Prod]` — consumers view.
Content promotes through stages with rebound data sources. Discussed in detail in the deployment pipelines guide.
## Workspace metadata and discoverability
For users searching for content:
- **Workspace name** matters — descriptive and unique.
- **Workspace description** appears in search; populate it.
- **Sensitivity labels** on workspaces govern external sharing and downstream content.
- **Featured content** promotes specific workspaces / reports for organisational visibility.
## Governance
- **Naming convention** — `[Domain]-[Audience]-[Purpose]`, e.g., `Finance-Executives-Monthly-Reports`.
- **Owner per workspace** — accountable for content quality.
- **Lifecycle policies** — orphaned workspaces (no owner) flagged and reviewed.
- **Audit** — track who creates workspaces, what's published, who accesses.
## Anti-patterns
- **One huge "Reports" workspace** — fine for 5 reports, untenable for 500.
- **Workspace per report** — too granular; lots of workspaces, hard to find anything.
- **Mixing dev and prod content** in the same workspace — leads to consumers seeing draft / broken content.
- **No owner** — orphaned workspaces accumulate without governance.
- **Personal workspaces holding production content** — fine for prototyping; risky for shared content (departures lose access).
For organisations scaling Power BI from a handful of reports to many, workspace design becomes a make-or-break decision. The investment is one-time; the operational benefit is permanent.
---
# Power Fx primer
URL: https://www.solvingmicrosoft365.com/guides/power-fx-primer
Category: Power Platform
Published: 2026-05-01
> A practical introduction to Power Fx, the formula language used across Power Apps and the Power Platform.
**Power Fx** is the formula language used across Power Apps canvas apps, increasingly in Power Automate, Dataverse formula columns, Copilot Studio, and Microsoft Fabric. Modelled on Microsoft Excel formulas, it's declarative, strongly-typed, and designed for non-developers. Learning a small Power Fx subset unlocks much of the Power Platform.
Power Fx is the formula language of [Power Apps](/guides/what-is-power-apps) canvas apps ([performance tuning](/guides/power-apps-performance-tuning) is mostly Power Fx hygiene), of [Copilot Studio](/guides/copilot-studio-explained), and increasingly of [Power Automate](/guides/what-is-power-automate); it borrows heavily from [Excel](/guides/copilot-in-excel-formulas-tables-and-charts) formulas.
## The mental model
A Power Fx formula is an **expression** — it evaluates to a value. You bind expressions to control properties: a button's `OnSelect`, a label's `Text`, a gallery's `Items`, a field's default value.
Excel users will find much familiar:
- `Sum(Numbers, Value)` totals a column.
- `If(condition, then, else)` conditional logic.
- `Concatenate(A, " ", B)` string joining (modern equivalent: the `&` operator).
- `Filter(Customers, Status = "Active")` filters a table.
- `LookUp(Orders, OrderID = thisID)` finds a single row.
## Core functions
A handful of functions cover most scenarios:
- **`Filter(table, condition)`** — return rows matching a condition.
- **`LookUp(table, condition)`** — return the first row matching a condition (or a specific field of it).
- **`Sort(table, expression)`** — sort.
- **`SortByColumns(table, "Column", SortOrder.Descending)`** — sort with explicit direction.
- **`First(table)` / `Last(table)`** — first / last row.
- **`Count(table)` / `CountRows(table)`** — count.
- **`Sum(table, expression)`** — total an expression across rows.
- **`Patch(table, baseRecord, updateRecord)`** — update a row in a data source.
- **`Collect(collection, item)`** — add to a local collection.
- **`ClearCollect(collection, source)`** — replace a collection.
- **`UpdateContext({var: value})`** — set local variables.
- **`Set(GlobalVar, value)`** — set global variables.
## Working with data
Connect a canvas app to a data source (SharePoint, Dataverse, SQL), and the source appears as a table you query with Power Fx:
```
// On a gallery's Items property:
SortByColumns(
Filter(Customers, Status = "Active" && Region = ddRegion.Selected.Value),
"Name",
SortOrder.Ascending
)
```
That's a complete query of an Active customers filtered by selected region and sorted by name — all in one expression.
## Variables and scope
Three variable scopes:
- **Context variables** (`UpdateContext`) — scoped to the current screen.
- **Global variables** (`Set`) — scoped to the whole app.
- **Collections** (`Collect`, `ClearCollect`) — table-shaped local data.
Use the right scope. Globals are tempting but make the app harder to reason about. Prefer context variables when possible.
## Delegation
A critical concept: **delegation** is when Power Fx pushes a filter/sort back to the data source's server (SharePoint, SQL, Dataverse) rather than fetching everything and filtering client-side. Without delegation, your app might fetch only the first 500 rows and filter those — missing data the user expects.
The Power Apps editor warns when a formula isn't fully delegable. Pay attention; rewrite the formula to use delegable operators where possible.
## Common patterns
- **`If(IsBlank(field), "Required", "")`** — show a validation message.
- **`Patch(Datasource, Defaults(Datasource), {Field1: value1, Field2: value2})`** — create a new record.
- **`Navigate(NextScreen, ScreenTransition.Cover)`** — go to another screen.
- **`Reset(Control)`** — reset a control to its default.
## Learning approach
The fastest way to learn Power Fx: build a simple app from a SharePoint list, then progressively add filter, sort, search, edit, delete. Each step uses a few more Power Fx functions and patterns. In a week of regular practice, the basics stick.
For developers coming from imperative languages, the declarative model takes adjustment — Power Fx isn't sequential statements; it's expression bindings that recalculate when their dependencies change. Treat it like a spreadsheet, not like JavaScript.
---
# Power Platform Center of Excellence (CoE) Toolkit
URL: https://www.solvingmicrosoft365.com/guides/power-platform-coe-toolkit
Category: Power Platform
Published: 2026-05-01
> Microsoft's free toolkit of apps and flows for governing Power Platform at scale.
The **Power Platform Center of Excellence (CoE) Starter Kit** is Microsoft's free, open-source toolkit of Power Apps, Power Automate flows, and Power BI dashboards for **governing the Power Platform at scale**. For any tenant with more than a handful of makers, deploying the CoE Toolkit is one of the highest-ROI governance investments available.
The toolkit implements the governance in [Power Platform environments and governance](/guides/power-platform-environments-and-governance) and [DLP policies](/guides/power-platform-dlp-policies), reports on [licensing](/guides/power-platform-licensing-explained) consumption, and belongs to the organisation's wider [Center of Excellence](/guides/microsoft-365-coe).
## What the CoE Toolkit provides
A connected set of tools that together give an organisation visibility and control over Power Platform usage:
### Inventory
- **Apps** — every Power App across every environment, with owner, last-used, sharing posture.
- **Flows** — every Power Automate flow, with trigger, connector usage, run status.
- **Bots and agents** — Copilot Studio bots in the tenant.
- **Environments** — list of every environment, type, capacity usage.
- **Connections** — every connection used by apps and flows.
### Analytics
- **App and flow usage trends** over time.
- **Top makers** by app / flow count.
- **Top apps** by user count.
- **Orphaned resources** — owned by departed users or disabled accounts.
- **Risky apps** — using premium connectors without licensing.
### Governance
- **Maker compliance** — onboarding processes for new citizen developers.
- **App reviews and approvals** — workflows for promoting apps to production.
- **Bulk operations** — disable many flows, clean up many apps, reassign owners.
- **Communication tools** — message makers about policy changes.
### Adoption
- **Maker scoring** — gamification of citizen-developer adoption.
- **Centre of excellence newsletter** templates.
- **Training tracker** integrated with Microsoft Learn.
## How it works
The CoE Toolkit is itself built on Power Platform — it's a collection of Power Apps, flows, and Power BI dashboards that consume Microsoft Graph and the Power Platform admin APIs to discover and analyse. Installation:
1. Download from the **Microsoft 365 PnP CoE Starter Kit GitHub repository**.
2. Set up a **dedicated environment** for the CoE Toolkit.
3. Import the solution.
4. Configure connections to Microsoft Graph and the Power Platform admin API.
5. Initial inventory runs — typically takes hours for larger tenants.
6. Schedule ongoing inventory updates.
7. Customise the included Power BI dashboards.
Microsoft publishes detailed deployment guidance, plus a community of practitioners actively contributing improvements.
## Why it matters
Without the CoE Toolkit, governing Power Platform usage requires:
- **Manual inventory** via PowerShell — error-prone and incomplete.
- **Per-environment access** for each maker's environment — unwieldy.
- **No tenant-wide visibility** into who's building what.
The result: Power Platform sprawls. Hundreds of apps and flows exist that nobody can find or attribute. Premium connector usage creeps up. Orphaned resources accumulate. Eventually a governance review forces a painful clean-up.
The CoE Toolkit lets you avoid that. Stand it up early; review monthly.
## Roles in a Power Platform CoE
The CoE Toolkit is most useful when paired with a **CoE team** — usually small (1–3 people for a mid-size organisation):
- **Programme lead** — owns the CoE strategy, reports to leadership.
- **Technical lead** — owns the CoE Toolkit itself, governance configurations.
- **Adoption lead** — runs the maker community, training, champions network.
For larger organisations, separate roles for app reviews, security reviews, and architecture standards may exist.
## What the CoE Toolkit doesn't do
- **It doesn't enforce policies automatically** — it surfaces information for humans to act on.
- **It doesn't replace DLP policies** — DLP is enforced; the toolkit reports on what exists.
- **It doesn't manage user training directly** — it tracks training, but the actual training happens elsewhere.
## Licensing
The CoE Toolkit is **free**, but it does use premium connectors and Dataverse, so the **CoE environment itself needs Power Apps Premium licences** for the CoE team using it. Typical cost: a handful of premium licences for the CoE staff.
For Microsoft 365 customers with serious Power Platform adoption — say 50+ makers — deploying the CoE Toolkit early is essentially mandatory. Without it, governance becomes a permanent crisis.
---
# Power Platform custom connectors
URL: https://www.solvingmicrosoft365.com/guides/power-platform-custom-connectors
Category: Power Platform
Published: 2026-05-01
> How to build custom connectors for Power Automate and Power Apps — wrapping any REST API as a Power Platform connector.
Power Platform ships **hundreds of pre-built connectors** for Microsoft 365 services, Azure, Dynamics 365, and major third-party SaaS apps. When the system you need isn't covered, **custom connectors** let you wrap **any REST API** as a Power Platform connector — making it usable from Power Automate flows, Power Apps, and Copilot Studio agents.
Connectors extend [Power Automate](/guides/what-is-power-automate) and [Power Apps](/guides/what-is-power-apps) to any API, usually authenticated through an [Entra app registration](/guides/entra-id-app-registrations-and-enterprise-apps) and governed by [DLP policies](/guides/power-platform-dlp-policies); the Graph-backed ones follow [Graph API basics](/guides/microsoft-graph-api-basics).
## What a custom connector is
A custom connector is essentially a **manifest for a REST API** described in **OpenAPI (Swagger) format** with Power Platform-specific extensions:
- **Authentication** — how the connector authenticates (API key, OAuth, basic auth, no auth).
- **Operations** — endpoints the connector exposes (Get-customer, Create-order, etc.).
- **Parameters** — what each operation accepts.
- **Responses** — what each operation returns.
- **Triggers** — events the connector can subscribe to (for Power Automate).
Once registered in a Power Platform environment, the connector appears in the connector list alongside built-in connectors — users select it, fill in actions, build flows or apps.
## Common use cases
### Wrap an in-house API
Your company has internal services exposing REST APIs. Build a custom connector and Power Platform users can call those services without writing code:
- Customer-management API.
- Internal pricing service.
- Custom workflow system.
### Wrap a third-party API without a built-in connector
Many SaaS apps don't have built-in Microsoft connectors but expose REST APIs. Wrap them yourself.
### Add authentication or transformation to an existing API
Sometimes the built-in connector exists but doesn't support a specific auth method or response transformation. A custom connector wraps the API with your specific requirements.
## Building a custom connector
The typical flow:
1. **Have a REST API** with documented endpoints.
2. **Provide an OpenAPI definition** — or use the Power Platform connector designer to define operations manually.
3. **Configure authentication** — OAuth 2.0, API key, basic auth.
4. **Define actions** in the connector designer.
5. **Define triggers** (for Power Automate) if the API supports webhooks.
6. **Test** with the built-in test tool.
7. **Share** the connector with the environment's users.
Configured in the **Power Platform admin centre** or **Power Apps maker portal → Custom connectors**.
## Authentication
The most-used auth types:
- **OAuth 2.0** — the API supports OAuth. Configure client ID, secret, scopes; users authenticate with the API the first time they use the connector.
- **API key** — single key shared across the connector. Users may or may not see the key.
- **Basic** — username and password.
- **No auth** — public APIs.
OAuth is the modern norm; configure carefully.
## Connection references
A connection reference is the **runtime mapping** of a connector to a specific account or credential. Multiple users of the connector each have their own connection reference (their own OAuth token, their own API key).
For shared / service-account scenarios, **service principal authentication** lets the connector authenticate as an identity rather than a user.
## Premium classification
Custom connectors are **premium connectors** in licensing terms — users invoking a custom connector need **Power Platform Premium licensing** (per-user, per-app, or pay-as-you-go).
This catches some organisations off-guard: build a useful custom connector and find that scaling it to many users requires premium licences across the board.
## Connector certification
Microsoft offers a **connector certification** process for ISVs publishing connectors to all Power Platform customers. Once certified, the connector appears in the public catalogue alongside Microsoft's first-party connectors. For internal-only connectors, certification isn't necessary.
## Limitations
- **Response size** — connectors have response-size limits; very large API responses may need pagination.
- **Latency** — connector overhead adds milliseconds to API calls.
- **Retry behaviour** — connector retry policies apply per call.
- **API rate limits** — the underlying API's rate limits apply; connectors don't magically scale.
## Operational considerations
- **Connector ownership** — assign an owner per connector.
- **Documentation** — describe each operation, especially edge cases.
- **Version management** — when the underlying API changes, update the connector definition.
- **Monitor usage** — see who's using which connector via the CoE Toolkit.
For organisations building meaningful Power Platform solutions on top of internal or third-party APIs, custom connectors are essential. The investment in defining the connector is one-time; the connector is then reusable across every Power App, flow, and agent in the environment.
---
# Power Platform DLP policies
URL: https://www.solvingmicrosoft365.com/guides/power-platform-dlp-policies
Category: Power Platform
Published: 2026-05-01
> How Power Platform DLP policies govern which connectors apps and flows can combine — for data protection at the platform layer.
**Power Platform DLP policies** govern which connectors apps and flows can combine — preventing scenarios where a Power Automate flow could, for example, read SharePoint files and post them to a personal Dropbox account. They're the foundational governance layer for any tenant doing serious Power Platform work.
## How DLP policies work
Power Platform DLP isn't content-based DLP (that's **Purview DLP**). It's **connector-based DLP** — restricting how apps and flows can combine data sources.
Each connector is classified as:
- **Business** — appropriate for corporate data (SharePoint, Outlook, Dataverse, internal systems).
- **Non-business** — restricted (Twitter, Gmail, personal Dropbox, personal social media).
- **Blocked** — not allowed at all.
A DLP policy says: **apps and flows cannot combine Business and Non-business connectors in the same artifact**. A flow reading SharePoint (Business) cannot also write to Twitter (Non-business). They must be in separate groups.
## Default classification
Microsoft ships **default classifications** for all connectors based on typical use:
- **Microsoft 365 connectors** — Business by default.
- **Major SaaS apps** (Salesforce, ServiceNow, Workday) — typically Business.
- **Consumer services** (Facebook, Twitter, Dropbox personal) — typically Non-business.
- **Premium connectors** — vary.
Admins can override per connector for specific tenant policy.
## Tenant-wide vs environment-specific
DLP policies apply at two scopes:
- **Tenant-wide policies** — apply across all environments.
- **Environment-specific policies** — apply to specific environments.
Tenant-wide first, then environment-specific overrides. Typical pattern:
- **Restrictive tenant-wide baseline** — strong defaults for default and ungoverned environments.
- **Permissive environment-specific overrides** for trusted environments (production CoE environments).
## Common policy patterns
### Strict default
For the **default environment** (where citizen developers experiment):
- Microsoft 365 connectors → Business.
- Dataverse → Business.
- Major enterprise SaaS → Business.
- Consumer services → Blocked.
- HTTP / custom connectors → Blocked.
Prevents users from connecting corporate data to consumer services.
### Production environments
For specific production environments where Power Apps and flows are deployed:
- All approved Business connectors → Business.
- Specific Non-business connectors allowed when justified.
- HTTP connectors allowed for explicit integration scenarios.
### Developer environments
For developer environments (per-maker private environments):
- More permissive — developers need flexibility to experiment.
- HTTP and custom connectors allowed.
- Restricted on what can be built in the production environments later.
## What about specific connector versions
Connectors have **endpoint filtering** — you can allow a connector but only to specific endpoints:
- **SharePoint connector**: allow only to your tenant's SharePoint, not others.
- **HTTP connector**: allow only to specific approved URLs.
- **Custom connector**: allow only when registered by specific publishers.
Granular control without blocking entire connectors.
## Enforcement
DLP policies are **enforced at runtime**:
- Apps and flows **using non-compliant combinations fail** when invoked.
- Apps already deployed **show errors** when DLP policies tighten.
- Maker UI **warns at design time** about policy violations.
For tenants tightening policies, identify and update existing artefacts before enforcement.
## CoE Toolkit integration
The **Power Platform CoE Starter Kit** provides DLP-related visibility:
- **Inventory** of which apps and flows use which connectors.
- **DLP violation reports** if policies tighten.
- **Maker notification flows** when their app would be blocked.
For organisations enforcing DLP at scale, the CoE Toolkit is essentially required.
## Operational considerations
- **Test policy changes** in a non-production environment before tenant-wide rollout.
- **Inventory before enforcing** — know what will break.
- **Communicate to makers** — give them time to adjust.
- **Allow exceptions through approval** — specific scenarios need specific exceptions.
- **Periodic review** — connector landscape changes; policies should evolve.
## Common pitfalls
- **Policies too permissive** — defeats the purpose.
- **Policies too restrictive** — breaks legitimate scenarios.
- **No environment-specific overrides** — one-size-fits-all DLP doesn't fit production scenarios.
- **No communication** — makers surprised by sudden policy changes.
- **No inventory** — surprise breakage when policy enforces.
For organisations doing serious Power Platform development, Power Platform DLP is one of the few non-optional governance controls. Without it, citizen developers will eventually connect corporate data to consumer services in ways that surprise legal / compliance. With it, the boundary is enforced automatically.
---
# Power Platform environments and governance
URL: https://www.solvingmicrosoft365.com/guides/power-platform-environments-and-governance
Category: Power Platform
Published: 2026-05-01
> Environments are the unit of isolation in Power Platform. Designing them well prevents most governance problems.
A **Power Platform environment** is a container for apps, flows, agents, and Dataverse — and it's the unit of isolation between projects, teams, and lifecycle stages. Designing environments well prevents most Power Platform governance problems before they happen.
The governance toolkit is the [CoE Starter Kit](/guides/power-platform-coe-toolkit) with [DLP policies](/guides/power-platform-dlp-policies) and [licensing](/guides/power-platform-licensing-explained) as the levers; the maker-side guides — [custom connectors](/guides/power-platform-custom-connectors), the [Power Fx primer](/guides/power-fx-primer), [AI Builder document processing](/guides/ai-builder-document-processing), [Power Automate error handling](/guides/power-automate-error-handling), [Process Mining](/guides/power-automate-process-mining), and [canvas app performance tuning](/guides/power-apps-performance-tuning) — are what governance exists to enable.
## What an environment contains
Each environment has:
- A **Dataverse instance** (optional but common).
- **Canvas apps**, **model-driven apps**, and **Power Pages** sites.
- **Power Automate flows** and **desktop flows**.
- **Power Virtual Agents / Copilot Studio** bots.
- **AI Builder models**.
- **Connections** to external services.
- A **security model** with environment roles and Dataverse security roles.
- A **region** (data residency boundary).
- Optional **data loss prevention (DLP) policies** that limit which connectors can be combined.
Environments are not free — Dataverse capacity, dedicated Dataverse capacity, and (sometimes) per-app licensing usage are scoped per environment.
## Standard environment types
- **Default environment** — every tenant has one, automatically created. Every user can create apps here. **Don't run production workloads here.** It can't be deleted and grows unmanaged.
- **Production environments** — created intentionally for specific apps or business units.
- **Sandbox environments** — for development and testing; cannot be promoted directly to production but can be copied.
- **Developer environments** — free per-user environments for individual learning and experimentation.
- **Trial environments** — short-lived, for evaluating features.
- **Default-with-Teams environments** — auto-created when someone adds a Power App to a Teams team (limited capabilities, but they multiply if not governed).
## A simple environment strategy
For most organisations:
- **Default** — locked down, no premium connectors, no Dataverse, monitored.
- **Developer environments** — provided to citizen developers for experimentation.
- **Dev / Test / Prod per major app or business unit** — proper ALM with **solution** packaging moving between them.
- **Shared CoE environment** — for the Centre of Excellence toolkit and shared utilities.
## Solutions and ALM
Moving an app or flow from dev to test to prod isn't a copy-paste exercise — it's a **solution** export and import. A solution is the packaging unit holding the apps, flows, Dataverse tables, connectors, and environment variables that make up a release. **Unmanaged solutions** are the working, editable format used in a dev environment while a maker is actively building; **managed solutions** are the locked, deployable format imported into test and production, where components can't be casually edited by whoever has access to that environment. Environment variables inside a solution let the same package hold, say, a "SharePoint site URL" value that's parameterised per environment rather than hardcoded, so the identical managed solution promotes cleanly from test to prod without manual find-and-replace. Pushing unmanaged changes directly into a production environment — editing a flow live in prod because a solution pipeline felt like overhead — is the single most common way Power Platform governance quietly breaks down.
## DLP policies
**DLP policies** decide which connectors can be combined in apps and flows. Each connector is categorised: **Business**, **Non-business**, or **Blocked**. Connectors in different categories can't be used together — preventing, say, a flow from reading SharePoint (Business) and posting to Twitter (Non-business).
Policies apply at the tenant level or to specific environments. A good baseline: a tenant-wide policy with strict defaults, plus per-environment overrides for apps that need exceptions.
## Centre of Excellence (CoE) Toolkit
Microsoft's **CoE Starter Kit** is a free set of apps and flows for governance: inventory of every app, flow, and bot in every environment; usage analytics; orphaned-resource cleanup; developer adoption tracking. For any tenant with more than a handful of makers, deploy it on day one.
## Licensing implications
- **Premium connectors and Dataverse** require Power Apps premium licensing in the environment where they're used.
- **Power Automate premium flows** also require licensing.
- **Pay-as-you-go** alternatives exist for unpredictable workloads.
Environment design is where governance succeeds or fails. Spend time on it before users start building.
---
# Power Platform licensing explained
URL: https://www.solvingmicrosoft365.com/guides/power-platform-licensing-explained
Category: Power Platform
Published: 2026-05-01
> The Power Platform licensing model — what's free, what's premium, and how to plan for it.
Power Platform licensing is famously confusing, partly because the model has changed several times, partly because it spans four products (Power Apps, Power Automate, Power BI, Power Pages, plus Copilot Studio and Dataverse). A clear map saves a lot of money and angry calls to Microsoft.
## What's "free" with Microsoft 365
Microsoft 365 subscriptions include limited Power Platform usage:
- **Power Automate** — cloud flows using **standard connectors** only (in-suite: Outlook, SharePoint, Teams, Office, etc.), with per-user run allowances.
- **Power Apps** — canvas apps using standard connectors, no Dataverse.
- **Power BI** — read-only access to reports shared with you, plus authoring of personal workspaces (Pro is required to share with others).
This is enough for many simple scenarios but it's strictly limited. The moment you reach for SQL, HTTP, on-premises gateway, Dataverse, or anything premium, you need additional licensing.
## Standalone licensing
The main standalone SKUs:
- **Power Apps Premium** — per-user, per-month. Unlimited custom apps, Dataverse, premium connectors. The default for serious citizen developers.
- **Power Apps per-app** — licence specific users for specific apps. Better when many users use one app.
- **Power Automate Premium** — premium connectors, unlimited flows, business process flows.
- **Power Automate Process** — unattended RPA, per-bot.
- **Power Pages** — per authenticated user or per anonymous user per site.
- **Copilot Studio Messages** — billed in packs of messages.
- **AI Builder credits** — for OCR, document parsing, prediction models.
- **Power BI Pro** — per-user, sharing rights.
- **Power BI Premium Per User (PPU)** — per-user, premium features.
- **Microsoft Fabric capacity (F-SKUs)** — capacity-based, replaces Power BI Premium P-SKUs.
## Pay-as-you-go
For unpredictable workloads, **pay-as-you-go** plans bill against an Azure subscription:
- **Power Apps PAYG** — per active user per month.
- **Power Automate PAYG** — per cloud flow run.
- **Copilot Studio PAYG** — per message.
PAYG is often cheaper for sporadic use and trivial for enterprise IT to administer. The trade-off is forecasting cost.
## Capacity-based items
Some products license by capacity, not user:
- **Dataverse database capacity** (in GB) — pooled across the tenant.
- **Dataverse file capacity**.
- **Dataverse log capacity**.
- **Fabric capacity** (F-SKUs, scaling by compute units).
Tenants get a small default allocation; large estates buy more.
## How to plan licensing
A pragmatic approach:
1. **Inventory** what's being built today (use the CoE Starter Kit).
2. **Classify** each app/flow as standard-only or premium.
3. **Identify users** of premium content.
4. **Compare** per-user vs per-app vs PAYG for each premium scenario.
5. **Negotiate** at Microsoft renewal — Power Platform licences are commonly part of EA discussions.
The biggest cost trap is **viral adoption** — citizen developers build apps that quietly need premium connectors, and the licence requirement creeps up. The CoE Toolkit's monitoring is essential for catching this early.
For most Microsoft 365 customers, Power Platform pays back many times over once the licensing is sorted. Don't let the model deter you — just plan deliberately.
---
# Power Query primer
URL: https://www.solvingmicrosoft365.com/guides/power-query-primer
Category: Power Platform
Published: 2026-05-01
> Power Query is the data import and transformation engine inside Excel and Power BI. Here's the model.
**Power Query** is the data import and transformation engine that appears throughout Microsoft's data and analytics tools — Excel, Power BI, Power Automate dataflows, Microsoft Fabric, Dataverse, and SQL Server Analysis Services. Once you know it, the same skill applies across the stack.
## What Power Query does
Power Query is fundamentally an **ETL** (Extract, Transform, Load) tool:
- **Connect** to a data source — Excel files, CSV, SQL, SharePoint lists, Web APIs, Azure Data Lake, hundreds more.
- **Transform** the data — remove columns, filter rows, group, pivot, unpivot, merge, append, type conversions, custom calculations.
- **Load** the transformed data into the destination — Excel sheet, Power BI model, Dataflow, etc.
Every step you take in the UI is recorded as a step in the **Applied Steps** pane, which you can reorder, edit, or remove. Steps are stored as expressions in the **M language** — Power Query's functional language.
## The M language
The UI generates M behind the scenes, but learning a little M unlocks much more:
```m
let
Source = Excel.Workbook(File.Contents("C:\sales.xlsx"), null, true),
Sales = Source{[Item="Sales",Kind="Table"]}[Data],
Filtered = Table.SelectRows(Sales, each [Region] = "EMEA"),
Grouped = Table.Group(Filtered, "Country", {{"TotalRevenue", each List.Sum([Revenue]), type number}})
in
Grouped
```
M is **functional** and **lazy** — operations describe a transformation pipeline, not imperative steps. The engine optimises and pushes work down to the source when possible ("query folding").
## Query folding
For SQL, OData, and many other sources, Power Query can push transformations **back to the source server** — generating a `SELECT` with `WHERE` clauses, joins, and aggregations rather than fetching everything and filtering client-side. This is **query folding**. When it works, performance is dramatically better.
Steps that don't fold (custom M functions, certain transformations) break the chain, so order matters.
## Where you'll meet Power Query
- **Excel** → Data → Get Data — most common entry point.
- **Power BI Desktop** → Transform Data — same engine, deeper modelling.
- **Power BI / Fabric Dataflows** — Power Query running in the cloud, shared across reports.
- **Power Automate dataflows** — automating data shaping into Dataverse.
- **Microsoft Fabric** — Dataflow Gen2 and Pipelines surface Power Query for warehouse-class ETL.
## When to use what
- For **one-time data wrangling** in Excel — Power Query in Excel is perfect.
- For **Power BI report sources** — Power Query in Power BI Desktop or, for shared scenarios, **Dataflows**.
- For **enterprise data engineering** at scale — Power Query in **Microsoft Fabric** Dataflow Gen2 or hand off to Spark / SQL.
Once you've internalised the Applied Steps mental model and the M language, Power Query becomes one of the most useful skills in the Microsoft data stack.
## Why query folding is worth understanding, not just query-writing
The performance difference query folding makes is large enough that it's worth actively checking, not just hoping for. In Power Query's editor, right-clicking a step and looking for a greyed-out "View Native Query" option is the quickest way to confirm whether a transformation is still folding back to the source — if it's available, the step is generating a native query the source database executes; if it's greyed out, everything from that point onward runs client-side in Power Query's own engine, pulling the full unfiltered dataset across the network first. The practical implication for query design: put filtering, column removal, and aggregation steps as **early** as possible in the applied-steps sequence, before any custom M function or unusual transformation that's likely to break folding — reordering steps that are logically independent of each other can be the difference between a refresh that takes seconds and one that takes many minutes against a large source table.
## Frequently asked questions
**Is Power Query the same product in Excel, Power BI, and Fabric, or just similar?** It's genuinely the same underlying engine and M language across all of them — a query built in Excel can be copied (via the Advanced Editor's M code) into Power BI or Fabric with little to no modification, which is exactly what makes the skill transferable rather than needing to be relearned per tool.
**Can Power Query handle real-time or streaming data?** No — it's fundamentally a batch ETL tool that refreshes on a schedule or on demand, not a streaming engine; scenarios needing genuinely real-time data (a live dashboard updating second-by-second) need a different tool in the stack, such as a Power BI streaming dataset or an Azure Stream Analytics pipeline, with Power Query remaining the right choice for everything that can tolerate a refresh interval.
---
# Microsoft Purview audit retention
URL: https://www.solvingmicrosoft365.com/guides/purview-audit-and-retention
Category: Microsoft Purview (Compliance)
Published: 2026-05-01
> How long Microsoft 365 retains audit logs by default, what Audit (Premium) adds, and how to think about retention.
The **Microsoft Purview audit log** records administrative and user activity across Microsoft 365 — mailbox access, file activity, sign-ins, permission changes, Copilot interactions, eDiscovery operations. **How long that data is retained** matters for compliance and incident investigation. Different licence tiers offer dramatically different defaults.
## Default retention by tier
- **Microsoft 365 / Office 365 E3** — **180 days** of audit log retention.
- **Microsoft 365 / Office 365 E5** — **1 year** of audit log retention.
- **Audit (Premium) add-on** — **10 years** of retention with longer-term storage and additional events.
The difference between 180 days and 1 year is whether you can investigate something that happened 7 months ago. The difference between 1 year and 10 years matters for long-running compliance regimes (financial services record-keeping, healthcare audit).
## What's logged
Hundreds of event types across:
- **Exchange** — message send, receive, delete, mailbox sign-in, mailbox permission change, transport rule, eDiscovery hold actions.
- **SharePoint and OneDrive** — file access, edit, share, sync, permission change.
- **Microsoft Teams** — channel and chat events, meeting events, app installs.
- **Entra ID** — sign-ins (also in Entra-specific logs), role assignments, application consent, conditional access policy changes.
- **Power Platform** — environment, flow, app activity.
- **Microsoft 365 Copilot** — prompts and grounding (with appropriate Purview audit configuration).
- **Compliance and security operations** — eDiscovery, sensitivity label applications, DLP detections.
## Audit (Premium)
The **Audit (Premium)** add-on extends beyond basic retention with:
- **10-year retention** (vs 1 year on E5).
- **High-bandwidth Office 365 Management Activity API** — faster export to SIEM at scale.
- **Critical events** — additional event types (Mail Read for example, useful in BEC investigations).
- **Customisable audit log retention policies** — set different retention per event type and user group.
For tenants subject to long-term record-keeping rules — SEC 17a-4, FINRA, MiFID II — Audit (Premium) is typically required.
## Custom retention policies
With Audit (Premium), you can define custom retention policies that override the defaults. Examples:
- **Executives** get audit log retention of 10 years.
- **General users** get 1 year.
- **Privileged operations** (admin actions) retained 10 years.
- **Regular file activity** retained 1 year.
Policies are configured in **Purview portal → Audit → Audit retention policies**.
## Operational considerations
- **Audit log isn't free of cost** — Audit (Premium) adds licensing per user.
- **Search performance** — large queries over years of data can be slow; use targeted searches.
- **API access** — for high-volume integrations with SIEM or analytics tools, use the Office 365 Management Activity API.
- **Audit deletion** — there's no manual delete; retention expiration is the only path to removal.
- **Long-term storage** — for retention beyond 10 years, export to your own long-term storage.
## Default policy after April 2024
Microsoft now turns audit logging **on by default** in all new tenants. Tenants created before that may need to verify it's enabled (`Search-UnifiedAuditLog` in Exchange Online PowerShell tests it). If it's off, turn it on immediately — you can't audit historical events you didn't log.
## Practical advice
For most Microsoft 365 customers:
- **Verify audit is on** in the tenant.
- **Know your retention** — 180 days (E3), 1 year (E5), or 10 years (Audit Premium).
- **Configure your SIEM** to ingest the audit log via the Management Activity API for cross-tenant correlation and longer retention.
- **Test investigation queries** — practice running a query for a specific event so you can do it under pressure.
Audit logging is the kind of feature whose value only becomes apparent during an incident. Make sure it's ready before you need it.
## Frequently asked questions
**How long does Microsoft 365 keep audit logs?**
180 days for Audit (Standard), one year for users with Audit (Premium) — included in E5 and E5 Compliance — and up to ten years with the 10-Year Audit Log Retention add-on. Retention is set per record type and user through audit retention policies.
**Does audit retention apply retroactively?**
No. Events are retained according to the licence and policies in place when they were logged. Buying Audit Premium today does not recover events that already expired under the 180-day rule.
**What does Audit Premium add beyond retention?**
Higher-value events such as MailItemsAccessed, Send, SearchQueryInitiated in Exchange and SharePoint, and higher API bandwidth for exporting audit data to a SIEM — the events investigators need to answer 'what did the attacker read'.
---
# Purview auto-labelling policies
URL: https://www.solvingmicrosoft365.com/guides/purview-auto-labelling-policies
Category: Microsoft Purview (Compliance)
Published: 2026-05-01
> How auto-labelling applies sensitivity and retention labels automatically based on content match — and the operational realities.
User-applied sensitivity and retention labels rely on users picking the right label at the right time. That works for engaged users but leaves substantial volumes of content unlabelled — and oversharing in Copilot becomes "the file was never labelled, so Copilot treated it as Internal." **Auto-labelling policies** in Purview fill this gap by applying labels automatically based on content match.
## Two flavours: client-side and service-side
### Client-side auto-labelling
Office apps (Word, Excel, PowerPoint, Outlook) **recommend or apply a label** as users work, based on what the content contains. Example: "this document contains 100+ customer SSNs; we recommend the Confidential label" — and the user can accept or override (depending on policy).
Configured as **auto-labelling settings** on each sensitivity label. Applies in real time at the user's device.
### Service-side auto-labelling
The Purview service **scans existing content** in SharePoint, OneDrive, and Exchange Online mailboxes, applying labels to content matching the rules — independent of user action. Useful for **labelling content at rest** without waiting for users to do it.
Configured as **auto-labelling policies** in the Purview portal. Runs on a schedule.
## What can trigger labelling
Match conditions include:
- **Sensitive information types** — credit card patterns, SSNs, government IDs, custom regex.
- **Trainable classifiers** — ML-based content category detection (legal docs, source code, healthcare records).
- **Keyword phrases**.
- **Content properties** — SharePoint column values, document properties.
- **Sender / recipient** patterns (Exchange-specific).
Conditions are AND/OR combinable. The Purview rule editor handles complex predicates.
## Where this matters most
Auto-labelling is particularly valuable for:
- **Copilot readiness** — labelled content gives Copilot signal about sensitivity, affecting what it includes in grounding and what it warns about in output.
- **DLP enforcement** — DLP policies keyed to labels work better when more content is labelled.
- **Retention enforcement** — auto-applied retention labels handle compliance retention without user action.
- **Historical content cleanup** — apply correct labels to years-old content that nobody is going to manually relabel.
## Operational rollout
A common pattern:
1. **Start with simulation mode** — service-side auto-labelling policies have a simulate option. Run a simulation, review what would be labelled, validate the matches.
2. **Tune the rules** — false positives in classifier or SIT matching are common. Refine the conditions.
3. **Enable the policy** — start labelling. Schedule incremental scans.
4. **Monitor** — Purview reports on labelled-vs-unlabelled volumes, classifier confidence, user overrides on client-side recommendations.
5. **Iterate** — add rules as new sensitive data types emerge.
## Limits and caveats
- **Service-side auto-labelling** processes ~25,000 files per day per policy initially, scaling up over time. Initial backlog processing can take weeks for large tenants.
- **Trainable classifiers** require training and validation cycles — they're not magic.
- **Client-side auto-labelling** works only when users are signed into Office apps with the right licence.
- **Encryption** applied by auto-labelling can break legacy workflows — pilot carefully on labels that encrypt.
## Licensing
Auto-labelling (both flavours) requires **Microsoft 365 E5**, **Microsoft 365 E5 Compliance**, or the **Information Protection and Governance** add-on.
For tenants serious about information protection and Copilot readiness, auto-labelling is a fundamental investment. User-applied labelling alone leaves too much content unmanaged in any non-trivial tenant.
## Frequently asked questions
**What is the difference between auto-labelling in Office apps and auto-labelling policies?**
Client-side auto-labelling (configured on the label) applies or recommends a label as a user works in Word, Excel, PowerPoint, or Outlook, based on sensitive information found. Service-side auto-labelling policies label content at rest in SharePoint, OneDrive, and Exchange without user involvement, in simulation first.
**Which licence is needed for auto-labelling?**
Microsoft 365 E5, E5 Compliance, or the Information Protection and Governance add-on. E3 covers manual labelling only.
**Why should auto-labelling run in simulation mode first?**
Simulation shows which files would be labelled and why without changing anything, over a sample of the tenant. Auto-labelling with encryption applied to the wrong content locks users out of files and breaks external workflows; simulation is where you catch a sensitive information type that matches invoice numbers.
---
# Purview eDiscovery — standard vs premium
URL: https://www.solvingmicrosoft365.com/guides/purview-ediscovery-standard-vs-premium
Category: Microsoft Purview (Compliance)
Published: 2026-05-01
> How Purview eDiscovery finds, preserves, and exports content for legal cases — and what premium adds.
**Purview eDiscovery** is the toolset for legal teams to find, preserve, review, and export Microsoft 365 content for litigation, regulatory requests, and internal investigations. Microsoft offers two tiers — **Standard** and **Premium** — and the difference matters a lot for serious cases.
## Standard eDiscovery
Available in **Microsoft 365 E3 / Office 365 E3**, Standard eDiscovery provides:
- **Content search** across Exchange mailboxes, SharePoint sites, OneDrive accounts, Teams chats, and Viva Engage.
- **Case management** to organise searches.
- **Hold** on specific mailboxes and sites, preserving content for the case.
- **Export** to PST and to standard formats.
It's enough for basic compliance work — a regulator asks for emails between two parties about a specific topic, you search, hold, and export.
## Premium eDiscovery
Available in **Microsoft 365 E5** and as a Purview add-on, Premium adds:
- **Custodian management** — tracks individuals, their associated data sources, and hold notifications.
- **Legal hold notifications** with acknowledgment tracking.
- **Communication compliance integration** to follow conversations across workloads.
- **Advanced indexing** of file content and email metadata.
- **Conversation reconstruction** — Teams chats reassembled into a coherent conversation, not isolated messages.
- **Near-duplicate detection** and **email threading** to reduce review volume.
- **Predictive coding** — ML-driven relevance ranking that trains on reviewer decisions.
- **Review sets** with annotations, redactions, and tagging.
- **Working set** management for very large cases (millions of items).
- **Export with metadata** in load files for downstream review tools (Relativity, etc.).
For large cases — where review volume is high and the cost of manual review dominates — Premium is dramatically more efficient.
## Cloud Attached eDiscovery
For organisations using third-party eDiscovery platforms like Relativity, **Cloud Attached eDiscovery** keeps Microsoft 365 as the source of truth: data is preserved and processed in Purview, and only the relevant subset is exported to the review platform.
## Operational tips
- **Practice with non-case data** before a real matter arrives. eDiscovery isn't intuitive on day one.
- Build **named saved searches** for common scenarios (a specific user's mail over six months).
- Set up **role groups** so legal and compliance teams have eDiscovery roles without broader admin rights.
- Combine with **retention policies** — eDiscovery searches content that exists, including in preservation hold from retention.
- For **Teams chat**, ensure retention is sufficient — chats default to 30-day retention on some plans.
## Licensing
- **eDiscovery (Standard)** — Microsoft 365 / Office 365 E3 and above.
- **eDiscovery (Premium)** — Microsoft 365 E5, Office 365 E5, or Microsoft 365 E5 Compliance add-on.
- Some advanced features require per-user "eDiscovery user licences" rather than tenant-level entitlement.
For legal teams in regulated industries, Premium is rarely optional. For SMBs handling occasional requests, Standard plus a thoughtful retention design is usually enough.
## Decision matrix — Standard, Premium, or third-party
| Situation | Recommendation |
|---|---|
| One or two matters a year, mostly a single custodian | Standard. Practise the search-hold-export loop on a training case first. |
| Regulated industry with steady request volume | Premium. Custodian management and hold notifications are the difference between "we responded" and "we can prove we responded." |
| Large litigation with millions of items and outside counsel | Premium plus Cloud Attached — process in Purview, export the relevant subset to Relativity or your review platform. |
| You already run Relativity or a similar review tool tenant-wide | Cloud Attached eDiscovery. Do not duplicate review UX in Purview when your reviewers already live in the third-party tool. |
| E3 tenant, single-request annual regulator | Standard is enough — but review Teams chat retention because 30 days is not enough if the request lands late. |
## Wrong-fit warnings
- **eDiscovery is not backup.** A hold preserves content against deletion for a case; it does not restore a corrupted mailbox or a wiped SharePoint site. If someone loses a file to a bad workflow, that is a retention/recovery problem, not an eDiscovery one.
- **Standard's export is not review-tool-friendly.** You get PST and native files; if downstream counsel wants a load file with control numbers and metadata, that is Premium.
- **Holds do not preserve everything forever automatically.** A hold covers the specified custodians and locations. New locations added mid-case need explicit hold updates.
- **Predictive coding is not a substitute for a review protocol.** It ranks relevance based on reviewer decisions — garbage in, garbage out. Train a coder against a defensible seed set, not against yesterday's coffee-fuelled tagging.
## Worked example — a regulator asks for six months of correspondence
*Scenario:* E5 tenant. Regulator requests all correspondence between four named employees and an external counterparty domain over the last six months, plus any shared documents.
- **Day 1:** Open a Premium case. Add the four employees as custodians, capturing their mailboxes, OneDrive, Teams chat, and any team memberships they own. Legal hold notifications go out; acknowledgments track in the case.
- **Day 2:** Draft a collection query — recipient / sender domain match, date range, plus keywords the counterparty is likely to have used. Preview the collection to check volume and refine before commit.
- **Day 3:** Commit the collection to a review set. Turn on near-duplicate detection and email threading — usually reduces the raw item count by 30–60%.
- **Day 4–7:** Reviewers tag responsive / privileged / redact. Redactions burn into the produced copy; the source stays intact.
- **Day 8:** Export with load file. Hand-off to outside counsel or produce direct to the regulator per the request format.
- **Day 30:** Release the hold once the response is accepted and the retention rules allow. Document the release in the case timeline for defensibility.
## FAQ for MSPs
- **Can we run eDiscovery on behalf of a customer?** Yes, if you hold the reviewer / manager role in their tenant and the customer's legal has approved the delegation in writing. Delegated Access via GDAP is usually enough; add role assignments in each tenant explicitly.
- **Does eDiscovery show up in Lighthouse?** No first-class view. You will operate per-tenant.
- **A customer without E5 needs Premium for one case — options?** Buy the Purview eDiscovery add-on per-custodian, run the case, drop the add-on afterwards. Cheaper than blanket upgrades for a one-off matter.
- **How do we avoid touching customer data ourselves?** Restrict your role to case configuration and hold administration; assign the customer's own legal team as reviewers so they see and tag content — you do not.
## Frequently asked questions
**What is the difference between eDiscovery Standard and Premium?**
Standard: cases, holds on mailboxes and sites, searches, and export of results. Premium: custodian management, legal hold notifications, collection with review sets, processing (OCR, threading, near-duplicates), tagging, redaction, predictive coding, and export in load-file formats — the tooling a legal team expects.
**Which licence do I need for eDiscovery Premium?**
Microsoft 365 E5, E5 Compliance, or the eDiscovery and Audit add-on. Custodians must be licensed; the reviewers need access to the Purview portal roles.
**Has Microsoft replaced Content Search?**
The classic Content Search and Core/Advanced eDiscovery tools were unified into the new Purview eDiscovery experience during 2025, with Standard and Premium as feature tiers within it. Old cases were migrated; the cmdlets remained available for a period.
---
# Purview Information Barriers
URL: https://www.solvingmicrosoft365.com/guides/purview-information-barriers
Category: Microsoft Purview (Compliance)
Published: 2026-05-01
> Information Barriers prevent specific groups of users from communicating or collaborating — for regulatory, ethical, or legal reasons.
**Information Barriers (IB)** in Microsoft Purview prevent specific groups of users from communicating or collaborating with each other across Microsoft 365. The classic use case is **ethical walls** in financial services — research analysts must not collaborate with investment banking — but they apply equally to legal, healthcare, M&A, and any scenario where two groups must be kept apart.
Barriers are one of the conduct controls in [What is Microsoft Purview](/guides/what-is-microsoft-purview) alongside [Communication Compliance](/guides/purview-communication-compliance) and [Insider Risk Management](/guides/purview-insider-risk-management); they act on the [Teams channels](/guides/microsoft-teams-channels-explained) and [SharePoint sites](/guides/sharepoint-permissions-explained) the segments use, and email separation needs [transport rules](/guides/transport-rule-examples).
## What barriers actually block
When two users are on opposite sides of an active barrier, they cannot:
- **Chat in Teams** (one-to-one or group).
- **Be in the same Teams team** or **Microsoft 365 Group**.
- **Be in the same channel** (including shared and private channels).
- **Share files** via OneDrive or SharePoint between the segments.
- **Schedule meetings** with each other.
- **Call** each other in Teams.
- **Find each other** in people search or directory lookups.
The user experience is mostly invisible — the other party doesn't appear in search, and shared content is blocked. From a workflow standpoint, the segments operate as if the other doesn't exist.
## The model: segments and policies
Information Barriers are configured with two object types:
- **Segments** — groups of users defined by an Entra ID attribute query (department, country, function).
- **Policies** — rules between two segments: **block** or **allow**.
A typical configuration:
- Segment: **Research Analysts** (where `Department = "Research"`).
- Segment: **Investment Bankers** (where `Department = "IBD"`).
- Policy: block communication between **Research** and **IBD**.
Multiple policies layer to express complex matrices.
## SharePoint and IB Modes
For SharePoint sites and OneDrive accounts, **IB modes** define how barriers apply:
- **Open** — no IB enforcement (the default).
- **Implicit** — site automatically reflects the segment of its owner.
- **Explicit** — site has explicit segments, only those segments can access.
- **Owner-moderated** — owners explicitly invite cross-segment members.
This lets a site be tightly scoped to one segment while another is shared between two.
## Operational considerations
- IB is **disruptive** — once active, in-flight conversations between blocked users break. Roll out with HR and stakeholder communication.
- **Service accounts and admins** typically need exceptions.
- **Existing memberships** must be reconciled — Teams or sites with mixed-segment members will need owners or content moved.
- **Federation with other tenants** complicates IB — Microsoft 365 federation policies and Cross-Tenant Access Settings need to mirror the model.
## Audit and reporting
IB has its own audit trail — every blocked attempt is logged for compliance reporting. Regulators in financial services often request this evidence directly.
## Licensing
IB requires **Microsoft 365 E5**, **Microsoft 365 E5 Compliance**, or the **Information Protection and Governance** add-on. Standalone IB licensing is also available.
## When you need it
For financial services firms with research/IBD separation, M&A advisory firms, and any organisation with regulatory firewall requirements, IB is essentially mandatory. For most other organisations, it's overkill — simpler permissions models and sensitivity labels cover similar use cases at lower operational cost.
## Frequently asked questions
**What are information barriers in Microsoft 365?**
Policies that prevent defined groups of users from communicating or sharing with each other in Teams, SharePoint, and OneDrive — for ethical walls between deal teams and research, or between students and staff — enforced by blocking chat, calls, meetings, and site access between the segments.
**Do information barriers block email?**
No. Information barriers cover Teams, SharePoint, and OneDrive. Email separation uses Exchange transport rules or address book policies; a complete ethical wall combines the two.
**Which licence do information barriers need?**
Microsoft 365 E5, E5 Compliance, or the Insider Risk Management add-on. Segments are defined by user attributes, so directory data must be accurate.
---
# Purview Insider Risk Management
URL: https://www.solvingmicrosoft365.com/guides/purview-insider-risk-management
Category: Microsoft Purview (Compliance)
Published: 2026-05-01
> Insider Risk Management detects risky internal behaviour — data theft, IP leakage, policy violations — with built-in privacy controls.
**Microsoft Purview Insider Risk Management (IRM)** detects risky behaviour by users inside the tenant — data theft, intellectual-property leakage, policy violations, security incidents — using built-in policy templates, machine learning, and privacy-preserving design.
Insider risk sits in the E5 tier described in [What is Microsoft Purview](/guides/what-is-microsoft-purview) with [Communication Compliance](/guides/purview-communication-compliance) and [Information Barriers](/guides/purview-information-barriers); its signals come from [DLP](/guides/purview-data-loss-prevention-deep-dive), [Defender for Endpoint](/guides/defender-for-endpoint-explained), and the [offboarding process](/guides/microsoft-365-offboarding-process) (leaver signals), and the specialist alternative is discussed in [Purview vs Varonis](/guides/purview-vs-varonis).
## What IRM looks for
Out-of-the-box policy templates cover the most common scenarios:
- **Data theft by departing users** — unusual download or copy activity by someone who's resigning.
- **General data leaks** — large outbound transfers, sensitive content to unmanaged destinations.
- **Healthcare data misuse** — patterns specific to healthcare regulatory regimes.
- **Security policy violations** — repeated failed sign-ins, malware events, defender alerts.
- **Risky browser usage** — unsanctioned cloud apps, anonymous file uploads.
- **Risky AI usage** — sensitive content shared with non-corporate AI assistants.
Each template combines **signals** from across Microsoft 365 — sign-in events, email activity, file operations, Defender alerts, HR events — to surface unusual patterns.
## How IRM preserves privacy
A common concern with insider-risk tooling is over-reach. IRM is designed to mitigate that:
- **Anonymised display** — user identities are masked by default in the analyst surface (pseudonyms).
- **Tiered access** — analysts can see redacted data; investigators with higher roles can de-anonymise after due process.
- **HR / Legal in the loop** — policy templates assume HR and Legal sign-off before access escalation.
- **Configurable scope** — choose which users are in scope (typically users with sensitive role flags from HR).
## HR connector and event-driven signals
A **HR data connector** ingests events from HR systems — resignation dates, performance review states, change of role — that drive **adaptive risk scoring**. A user with a recent resignation date who suddenly starts copying customer data has a different risk profile from the same activity by a stable employee.
## Investigation workflow
The analyst surface includes:
- **Alerts** with severity scoring and contributing indicators.
- **Case management** — investigations bundled with related alerts and notes.
- **Content explorer** — the actual files and emails involved (with appropriate role gates).
- **User activity timeline** — the sequence of events leading to the alert.
- **Defender XDR integration** — IRM cases can correlate with broader incidents.
## Operational realities
IRM is unlike most security tools because it involves the **HR and Legal functions deeply**:
- Define policies with HR and Legal sign-off.
- Train analysts on privacy-preserving investigation.
- Establish escalation paths so de-anonymisation only happens with documented authorisation.
- Communicate the existence of IRM to employees as part of acceptable-use policies.
## Licensing
IRM requires **Microsoft 365 E5**, **Microsoft 365 E5 Compliance**, or the Purview Insider Risk Management standalone licence. Per-user licensing is typical.
For regulated industries — finance, pharma, intellectual-property-heavy sectors — IRM is rapidly becoming standard. For organisations with lighter obligations, it's a deliberate decision driven by risk appetite, not a default deployment.
## A worked example: departing-employee policy
The most common insider-risk pattern in mid-market tenants — a departing employee exfiltrating IP in their notice period.
- **Signal.** HR posts the notice date into the HR connector; IRM inflates the risk score of that user for the window [notice - 30 days, last day + 15 days].
- **Indicators.** Downloading unusually many files from SharePoint, copying to USB, uploading to unmanaged personal cloud storage, printing volumes above baseline, emailing large attachments to personal domains, sensitivity-labelled content leaving the tenant.
- **Alert threshold.** Two indicators inside a rolling 24-hour window, or one indicator involving Confidential-labelled content.
- **Workflow.** Alert to the IRM analyst queue; anonymised in the queue by default (name, role, department masked). Analyst reviews evidence, escalates or dismisses. Escalation removes anonymisation and creates a case with an HR business partner and the security lead.
- **Communications compliance tie-in.** For cases involving suspected policy breach, a parallel Communications Compliance policy inspects mail/Teams for keywords tied to that scenario (competitor names, "final version", "personal email"), reviewed by a separate reviewer group.
The unglamorous parts are the HR connector wiring and the anonymisation review. Both take about a week of stakeholder alignment before you touch the console.
## Decision matrix: which IRM policy first
| Business risk | Policy template |
| --- | --- |
| Departing employees taking IP | **Data theft by departing users** |
| Accidental leaks of sensitive files | **General data leaks** or **Data leaks by users** |
| Privileged-role misuse | **Data leaks by priority users** (with priority user group) |
| Insider trading, market-abuse patterns | Financial-services templates (US-market focused, may not fit EU) |
| Ransomware precursor behaviours | **Risky browser usage**, **Malicious activity** (endpoint-DLP driven) |
| Unauthorised AI use with tenant data | **Risky AI usage** (where available; requires Purview AI Hub) |
## When IRM is the wrong tool
- **You do not have a mature response process.** IRM produces alerts; without an analyst who knows what to do with them, alerts pile up unreviewed and any subsequent case is undermined ("you saw this and did nothing").
- **You lack works-council / HR alignment.** In many EU jurisdictions IRM cannot lawfully be enabled without prior consultation with employee representatives. Deploying anyway is a legal and cultural mistake.
- **You've disabled Audit or DAG connectors.** IRM depends on the unified audit log and, for endpoint indicators, on Defender for Endpoint. If those are off or partially deployed, IRM's signal quality is poor.
- **You want DLP instead.** DLP blocks the action; IRM detects the pattern. If the goal is to prevent exfiltration in real time, [Purview DLP](/guides/purview-data-loss-prevention-deep-dive) is the tool, and IRM complements it.
## MSP checklist
- **Legal preflight first.** Confirm in writing with the client (and their counsel, in EU) that IRM is authorised. This is not "click accept in the console"; it is a document.
- **Roles.** Set up separate IRM Investigators, Analysts, and Auditors groups. Do not put security engineers straight into Investigators — least-privilege applies here too.
- **Anonymisation on by default** for every new tenant. It's a one-toggle change to disable when a case escalates; being off by default is the wrong posture.
- **Tune before you subscribe.** Run each policy in Test mode for 30 days. Real-world tuning cuts alert volumes by 60–90% and prevents analyst burnout on day one.
- **Response runbook.** Ship a documented case runbook per policy template — who reviews, what evidence they collect, where cases live, what escalation path exists.
## Frequently asked questions
**What does Insider Risk Management detect?**
Patterns that suggest data theft, leaks, or policy violations by insiders: mass downloads before resignation (from HR data), exfiltration to USB or personal cloud, unusual sharing, and risky browser activity — scored across signals from Microsoft 365, Defender, and optionally HR and third-party systems.
**Is Insider Risk Management surveillance of employees?**
It is designed with pseudonymised user names, role-separated investigations, and audit of investigator actions to satisfy works councils and privacy regulators. Policies should be reviewed with HR and legal; the product is a risk-detection tool, not an activity monitor.
**What licence does Insider Risk Management need?**
Microsoft 365 E5, E5 Compliance, or the Insider Risk Management add-on. Some signals (endpoint activity) also require devices onboarded to Defender for Endpoint.
---
# Microsoft Purview records management
URL: https://www.solvingmicrosoft365.com/guides/purview-records-management
Category: Microsoft Purview (Compliance)
Published: 2026-05-01
> Records management is retention with teeth — declaring content as a record locks it for legal/regulatory compliance.
**Records management** in Microsoft Purview is the structured way to declare specific content as a **record** — making it immutable, preserving it for a defined period, and disposing of it through a formal process. It's retention with teeth, designed for the kinds of compliance regimes where "we kept the document for 7 years" needs to be defensible in court.
## What declaring a record does
When a retention label has the "Mark items as a record" setting and a user (or a policy) applies it:
- The item becomes **immutable**: no edits, no deletions, no renames.
- Some metadata is **locked** to the value at declaration.
- The label can only be removed by a user with the right privileges, and only to specific other labels.
- A **disposition review** can be required before final deletion at the end of retention.
A **regulatory record** is even stronger: once applied, the label cannot be removed by anyone (including admins), and content can never be unlocked.
## The records management workflow
1. **Define a file plan** — a hierarchy of record categories with retention periods, triggers, and disposition rules. Purview's File Plan view lets you import a file plan from spreadsheet.
2. **Publish retention labels** mapped to record categories.
3. **Apply labels** — manually by users, or automatically by content match, machine-learning classifier, or trainable classifier.
4. **Trigger retention** — by content creation date, last-modified date, or **event-based retention** (e.g., a customer contract is closed; retention starts then).
5. **Disposition review** — at the end of retention, named reviewers approve deletion, extension, or relabel.
6. **Audit trail** — every record action is logged.
## Event-based retention
A particularly useful capability: retention triggers from an **event** like contract closure, employee departure, or product end-of-life. The event is typically published by an external system (Dataverse, an HR system) via the Microsoft Graph. When the event fires, the timer on relevant records starts.
This means "retain for 7 years after the project ends" is enforceable, where a static creation-date trigger would fail.
## Auto-application
To minimise reliance on user behaviour, labels can be **auto-applied** to content matching:
- **Sensitive information types** (regex + context).
- **Trainable classifiers** (ML categorisation).
- **Keywords or properties** (a SharePoint column value, a content type).
Auto-application is the practical way to apply records management at scale.
## Licensing
Basic retention labels are included in **Microsoft 365 E3**. Records management — declaring records, event-based retention, disposition review — requires **Microsoft 365 E5** or the Purview Records Management add-on.
## When you need it
For industries with statutory record-keeping (finance, healthcare, public sector, legal, energy), records management is essential. For organisations with looser obligations, **retention policies** plus **sensitivity labels** are usually enough — records management adds operational overhead that needs to be justified.
When you do need it, document the file plan as carefully as you would any legal artefact. The whole point is defensibility, and undocumented decisions don't defend themselves.
## A worked example: a 12-year retention plus a legal hold
A financial-services firm needs to keep all client correspondence for **12 years** after the client relationship ends, and to place a **legal hold** on a subset when a matter opens.
- **File plan.** One record label per business function (Client Correspondence, Investment Advice, Compliance Attestations). Not one per team.
- **Retention rule.** Record; retain for 12 years starting from a **date-triggered event** ("Client offboarded") published from CRM into an event-based retention topic.
- **Immutability.** Regulatory record where the regulator requires it (locks the label from modification/deletion by anyone, including tenant admin); standard record where it doesn't. This choice is one-way — a regulatory record cannot be downgraded.
- **Disposition.** Manual disposition review by the compliance officer; a second-approver rule for anything over a stated financial threshold.
- **Legal hold.** When a matter opens, an eDiscovery hold is placed on relevant custodians. This overrides deletion behaviours until the hold is released, without changing the underlying retention rule.
The unglamorous part is the CRM-to-Purview event topic wiring. Getting the "offboarded" signal to Purview reliably is what makes date-triggered retention work; without it, retention rolls forward from the file's create date and everything expires too early.
## Decision matrix: retention policy vs. retention label vs. record label
| You need to… | Use |
| --- | --- |
| Keep everything in a container (site, mailbox, Team) for N years | **Retention policy** |
| Apply different rules to specific items based on classification | **Retention label** (non-record) |
| Prevent deletion/modification of specific items with disposition | **Record label** |
| Meet SEC 17a-4/FINRA WORM requirements | **Regulatory record label** |
| Trigger the retention clock on a business event (contract end, client offboarded) | **Event-based retention** on any label type |
| Support one-off legal preservation independent of the retention rules | **eDiscovery hold** |
## When records management is the wrong tool
- **You have no statutory obligation.** Retention labels or plain retention policies do the job at a fraction of the operational cost.
- **You cannot commit to disposition review.** A disposition queue that nobody triages is worse than no records programme at all — the whole point is a defensible chain of decisions.
- **You are still on OneDrive/SharePoint with no site classification.** Fix information architecture and sensitivity labels first ([SharePoint IA](/guides/sharepoint-information-architecture), [sensitivity labels deep dive](/guides/purview-sensitivity-labels-deep-dive)); records without a target is theatre.
- **Users would need to classify every item manually.** That fails everywhere it's been tried. Auto-application by container, sensitive-info type, or trainable classifier is the only sustainable posture.
## MSP checklist
- **Do not ship a records programme without a records officer named on the client side.** Records management is a governance function first; the tooling only executes decisions someone accountable made.
- **Sizing.** For a mid-market client, plan on 6–8 record labels, not 60. Start with client correspondence, contracts, financial records, HR files.
- **Auto-apply pilot.** Publish records auto-apply against a subset of sites (one department) for at least one full retention cycle before extending tenant-wide. Bad classification at scale is enormously painful to undo.
- **Disposition workflow.** Give the client a documented monthly cadence for disposition review with named roles. The default queue in the compliance portal is fine for small volumes; hand off to eDiscovery for anything requiring a defensible export before disposal.
- **Regulator evidence.** Keep the file plan, the auto-apply rules, and the disposition reasons in the same document set. When the auditor arrives, this is what you hand over.
## Frequently asked questions
**What is the difference between a retention label and a record?**
A retention label sets retention and deletion behaviour on an item and can be changed or removed. Marking a label as a record makes the content immutable in defined ways — it cannot be deleted, and editing is blocked or limited — until the retention period ends. Regulatory records go further and cannot be unlocked at all.
**What is disposition review?**
A workflow at the end of a record's retention period where designated reviewers decide whether to delete, extend, or relabel the content before disposal. It provides the audit trail regulators and records managers expect.
**Does records management need E5?**
Retention labels with basic retention are in E3. Records management — declaring records, regulatory records, disposition review, event-based retention, the file plan — needs E5, E5 Compliance, or the Information Protection and Governance add-on.
---
# Purview retention policies explained
URL: https://www.solvingmicrosoft365.com/guides/purview-retention-policies-explained
Category: Microsoft Purview (Compliance)
Published: 2026-05-01
> How Microsoft Purview retention policies keep and delete content across Microsoft 365 — the model and the gotchas.
A **retention policy** in Microsoft Purview keeps content for a defined period across one or more Microsoft 365 workloads, and optionally deletes it at the end. Used well, retention policies are the legal/regulatory keystone of a tenant; used poorly, they hide files where users can't find them.
## The model
A retention policy has three things:
- **Locations** — Exchange mailboxes, SharePoint sites, OneDrive accounts, Microsoft 365 Groups, Skype, Teams chats, Teams channel messages, Teams meeting recordings, Viva Engage.
- **Scope** — which mailboxes / sites / users (static or adaptive).
- **Actions**:
- **Retain only** — preserve for N years, then do nothing.
- **Retain then delete** — preserve for N years, then delete.
- **Delete only** — let users keep content as long as they want, but delete after N years.
The retention period starts from a **trigger date** — when the content was created, last modified, or labelled (depending on policy configuration).
## How retention overrides user actions
When a retention policy applies to a location, content is **preserved** even if a user deletes it. For Exchange, deleted items move to a hidden **preservation hold** folder. For SharePoint and OneDrive, deleted items go to a hidden **Preservation Hold Library**. Users don't see preserved content but it counts against site / mailbox quota.
This is the most common surprise: "the site is full" and the reason turns out to be 200 GB of preserved-but-deleted content sitting invisibly in the preservation hold.
## Adaptive vs static scope
- **Static scope** — manually pick the sites, users, or groups. Fine for small scopes.
- **Adaptive scope** — query-based, scoped by Entra ID attributes (department, country, group membership). Membership updates automatically.
Adaptive is the right default for any non-trivial tenant.
## Retention labels vs retention policies
Two related but distinct features:
- **Retention policies** apply at the **container level** (mailbox, site).
- **Retention labels** apply at the **individual item** level.
Labels are richer: each label has its own retention period, can be triggered by content, and can be auto-applied. Use policies for the broad baseline and labels for specific records (contracts, HR files, financial records).
## Order of precedence
When multiple retention settings apply, Microsoft uses a deterministic precedence:
1. **Retention wins over deletion**.
2. **Longer retention wins**.
3. **Explicit wins over implicit**.
4. **Shorter deletion wins** (once retention is satisfied).
This means a policy retaining for 7 years overrides a deletion policy at 3 years.
## Licensing
Basic retention policies are included in **Microsoft 365 E3**. Adaptive scopes, advanced records management, and trainable classifiers for auto-labelling require **E5** or specific Purview add-ons.
## Practical advice
- Start with a **single tenant-wide policy** at a sensible default (3–7 years), then layer specific overrides.
- Always **document the policy decision** somewhere durable (a SharePoint site, your governance register).
- Monitor **preservation hold size** in OneDrive and SharePoint reports.
- Pair retention with **sensitivity labels** for end-to-end governance.
Retention is paperwork that protects the organisation. Set it once, review annually, document it forever.
## Frequently asked questions
**What does a Purview retention policy do?**
It keeps content for a set period even if users delete it, deletes it after the period, or both — applied automatically to whole locations (mailboxes, sites, OneDrive, Teams chat). Users see no difference; deleted items are held in hidden locations until the period ends.
**What happens when retention policies conflict?**
The principles of retention apply: retention wins over deletion, the longest retention period wins, explicit (labels, specific locations) wins over implicit (org-wide), and the shortest deletion period wins among deletion-only policies. Content is never deleted while any retention policy or hold still requires it.
**Can users tell a retention policy is applied?**
Not directly. Retention labels are visible on items and can be applied by users; retention policies are invisible. Users notice only when they cannot find a Teams message older than the deletion period, or when eDiscovery returns something they deleted.
---
# Ransomware preparedness for Microsoft 365
URL: https://www.solvingmicrosoft365.com/guides/ransomware-preparedness-for-microsoft-365
Category: Microsoft Defender (Security)
Published: 2026-05-01
> How to harden a Microsoft 365 tenant against ransomware — prevention, detection, response, and recovery.
Ransomware against Microsoft 365 tenants targets cloud content directly — encrypting SharePoint sites, OneDrive accounts, mailboxes, or destroying access via credential theft and admin-account compromise. Even cloud SaaS doesn't make you immune. The good news: Microsoft 365 has strong defences built in, and Microsoft provides specific tooling for recovery. The hard part is having it ready *before* it happens.
Prevention is [Defender for Endpoint](/guides/defender-for-endpoint-explained), [attack surface reduction](/guides/defender-xdr-and-attack-surface), and [compliant-device Conditional Access](/guides/how-to-require-compliant-devices-with-conditional-access); recovery is [Microsoft 365 backup and recovery](/guides/microsoft-365-backup-and-recovery) and the [mass-delete recovery runbook](/guides/sharepoint-mass-delete-recovery-runbook), and the plan lives in [disaster recovery planning](/guides/microsoft-365-disaster-recovery-planning).
## Prevention
### Identity hardening
- **MFA enforced** for everyone, **phishing-resistant** (FIDO2 / passkeys) for admins.
- **Conditional Access** blocking legacy auth, requiring device compliance.
- **PIM** for every privileged role — no standing Global Admins.
- **Identity Protection** policies blocking high-risk sign-ins.
- **Break-glass admin accounts** stored offline, MFA-exempt but with very strong unique credentials.
### Endpoint hardening
- **Defender for Endpoint** onboarded everywhere, **Tamper Protection on**.
- **Attack Surface Reduction** rules in block mode for high-confidence rules.
- **Local admin removed** for most users (Intune EPM for elevation).
- **Patch SLA** kept short — Defender Vulnerability Management drives priority.
### Email hardening
- **Defender for Office 365 P2** with Strict preset policies.
- **DMARC at p=reject**.
- **Attack Simulation Training** running monthly.
- **OAuth consent restrictions** — limit user consent to risky scopes.
## Detection
- **Defender XDR** monitoring with alerting on critical signals.
- **Automatic Attack Disruption** enabled.
- **Microsoft Sentinel** for cross-product correlation and longer retention.
- **Microsoft Defender for Identity** sensors on every domain controller.
- **Unusual activity alerts** for mass-download patterns, mass-share-link creation, unusual sign-in countries.
The earlier you detect, the smaller the impact. Microsoft's case data consistently shows that fast disruption changes outcomes dramatically.
## Response
When ransomware is suspected or confirmed:
1. **Isolate affected devices** via Defender for Endpoint.
2. **Disable affected accounts** in Entra ID, revoke sessions.
3. **Stop active sharing links** — sometimes mass-share is the attack pattern.
4. **Snapshot SharePoint / OneDrive sites** that are still healthy to capture recoverable state.
5. **Engage Microsoft Support** — for severe incidents, Microsoft has incident-response support.
6. **Document the timeline** as you go.
## Recovery
This is where many organisations were unprepared in past incidents:
### Native SharePoint and OneDrive recovery
- **Version history** — every file in SharePoint and OneDrive has version history. For ransomware that encrypts files, **previous versions** are typically still healthy.
- **Recycle bin** — two-stage recycle bin retains deleted content for 93 days.
- **Restore your OneDrive** — built-in feature lets users restore their OneDrive to a point in time (up to 30 days back). The single most useful per-user recovery feature.
- **SharePoint site restore** — admin can restore a site to a point in time.
### Microsoft 365 Backup
For larger and structured recovery, **Microsoft 365 Backup** provides:
- Point-in-time restore at SharePoint / OneDrive / Exchange scale.
- **Hourly snapshots** retained per configured policy.
- **Rapid restore** measured in items / hour — orders of magnitude faster than typical third-party restore.
For tenants subject to ransomware risk, Microsoft 365 Backup is increasingly part of the baseline.
### Third-party SaaS backup
For **air-gapped** off-platform copies (insurance against a tenant-wide compromise), third-party SaaS backup tools (Veeam, Druva, AvePoint, Acronis, Barracuda, others) provide additional resilience.
The right answer for most organisations is **both**: Microsoft 365 Backup for fast in-platform recovery, plus a third-party off-platform copy.
## Operational readiness
The single most underrated activity: **test restoration**. Run a quarterly tabletop exercise where you actually restore a SharePoint site, a OneDrive, a mailbox to verify the procedure works. The only backup that matters is one you've recovered from.
Document the runbook. Train the team. Hope you never need it.
## Frequently asked questions
**Can ransomware encrypt files in SharePoint and OneDrive?**
Yes, through a synced device: malware encrypts the local copies and the sync client uploads them as new versions. Versioning, the recycle bin, and Files Restore (which rolls a whole OneDrive or library back to a point in time within 30 days) are the recovery path; Defender for Endpoint and app control are the prevention path.
**What is Files Restore?**
A OneDrive and SharePoint feature that restores an entire library to its state at any point in the last 30 days, undoing mass changes from ransomware, a bad sync, or a script. It uses version history, so libraries with versioning disabled cannot use it.
**Do I need third-party backup to recover from ransomware in Microsoft 365?**
Not necessarily for SharePoint and OneDrive files if versioning and Files Restore are in place and you act within 30 days; Exchange has Recoverable Items and holds. Backup (Microsoft 365 Backup or third-party) adds longer windows, faster large-scale restore, and coverage for gaps — most organisations with compliance obligations add it.
---
# SAML SSO with Entra ID
URL: https://www.solvingmicrosoft365.com/guides/saml-sso-with-entra-id
Category: Microsoft Entra (Identity)
Published: 2026-05-01
> How to set up SAML single sign-on between a third-party app and Microsoft Entra ID.
**SAML 2.0** is one of the two main standards (along with OpenID Connect / OAuth 2.0) for federated single sign-on between identity providers and applications. Microsoft Entra ID acts as a SAML identity provider for thousands of SaaS apps. Knowing the moving parts saves a lot of debugging.
## The SAML flow
When a user signs into a SAML-enabled app:
1. User clicks **Sign in** in the app.
2. The app redirects the browser to Entra ID's **SAML sign-in URL**, with a request for an assertion.
3. Entra ID **authenticates the user** (password, MFA, Conditional Access).
4. Entra ID generates a **SAML assertion** — an XML document with claims about the user — signed with Entra's private key.
5. The browser **POSTs the assertion** back to the app's **Assertion Consumer Service (ACS)** URL.
6. The app validates the signature using Entra's public key, reads the claims, creates a session.
The user sees a single-sign-on experience; under the hood, two redirects and an XML POST happened.
## Setting it up in Entra ID
For each SAML app, you create an **Enterprise application** in Entra ID (either from the gallery or as a non-gallery app), then configure **Single sign-on → SAML**:
1. **Identifier (Entity ID)** — a URI provided by the app, identifying the app to Entra.
2. **Reply URL (ACS URL)** — where Entra POSTs the assertion.
3. **Sign-on URL** — optional, where users go for IdP-initiated SSO.
4. **User attributes & claims** — what claims to include in the assertion (email, name, groups, custom fields).
5. **SAML signing certificate** — Entra's certificate that the app uses to verify assertions. Download and upload to the app.
6. **Login URL / Logout URL** — what Entra exposes for the app to redirect to.
Once configured, **assign users / groups** to the application — only assigned identities can SSO in.
## Common pitfalls
- **Clock skew** — SAML assertions have validity windows. If the app's clock is significantly off, assertions fail.
- **NameID format mismatches** — the app expects a specific identifier format (email, UPN, custom); Entra needs to send it correctly.
- **Required claims missing** — the app needs a claim Entra isn't sending; configure attribute mappings.
- **Certificate rotation** — Entra signing certs have expiration dates; rotate them deliberately with the app's awareness.
- **SP-initiated vs IdP-initiated** — apps may support only one; understand which flow the app expects.
## SAML vs OIDC
For modern apps, **OpenID Connect (OIDC) / OAuth 2.0** is increasingly the right choice over SAML:
- **OIDC** uses JSON over HTTPS (cleaner than XML).
- **OIDC** is mobile and SPA-friendly out of the box.
- **OIDC** scopes are richer for API access.
- **SAML** is still ubiquitous for legacy enterprise SaaS.
Most SaaS vendors support both. Pick OIDC for new integrations where available; SAML for legacy apps that require it.
## Operational considerations
- **Conditional Access** policies apply to SAML sign-ins — gate the app by MFA, device compliance, location.
- **Audit logs** in Entra show every SAML sign-in attempt and result.
- **Just-in-time (JIT) provisioning** lets some apps auto-create user records on first SAML sign-in; for others, pair SAML with SCIM provisioning.
## JIT provisioning vs SCIM
**Just-in-time provisioning** creates the user's account in the target app the moment they first sign in via SAML, using the attributes carried in the SAML assertion (name, email, department) to populate the new record — no separate provisioning step needed before the user's first sign-in. It's simple and requires no extra configuration beyond the SAML integration itself, but it's also a one-way, sign-in-triggered operation: JIT only fires *on* sign-in, so it doesn't proactively deprovision an account when someone leaves, doesn't push attribute updates on a schedule, and won't create the record ahead of time for an app that needs pre-provisioning (a seat reserved before day one, say). **SCIM provisioning** is the fuller alternative — Entra ID actively pushes create, update, and deactivate events to the app on its own schedule (typically every 20–40 minutes) based on group membership or assignment, independent of whether the user has signed in at all. For apps that support both, the two aren't mutually exclusive: some organisations use JIT purely to get an account into existence at first login, with SCIM handling the ongoing lifecycle — attribute sync and, critically, deprovisioning when access is unassigned — afterward. Apps that only support JIT and not SCIM need a separate, deliberate offboarding process, since nothing will automatically deactivate the account when the person leaves.
SAML is mature, well-understood, and unlikely to disappear — but it's not where Microsoft or modern SaaS vendors are investing for new features.
## Frequently asked questions
**How do I set up SAML SSO for an app in Entra ID?**
Add the app from the gallery (or create a non-gallery app), open Single sign-on → SAML, set the identifier (entity ID) and reply URL from the app's documentation, map the required claims (usually user principal name or email as NameID), download Entra's federation metadata or certificate, and configure the app with it. Assign users or groups, then test with the built-in tester.
**Why does SAML SSO fail with an audience or reply URL error?**
Because the entity ID or reply URL in Entra does not exactly match what the service provider sends — trailing slashes, http vs https, and a staging vs production URL are the usual culprits. The Entra sign-in log's error code and the app's own SAML trace name the mismatch.
**What happens when the SAML signing certificate expires?**
Sign-in to that app fails for everyone. Entra creates a new certificate on request and lets you activate it after the app has been updated; set the notification email on the SAML page and calendar the expiry, or use the Graph-based reports to find certificates expiring soon.
---
# SCIM provisioning to Entra ID
URL: https://www.solvingmicrosoft365.com/guides/scim-provisioning-to-entra-id
Category: Microsoft Entra (Identity)
Published: 2026-05-01
> How SCIM auto-provisions users from HR and identity systems into Entra ID and downstream SaaS apps.
**System for Cross-domain Identity Management (SCIM)** is an open standard for automating user lifecycle across identity providers and SaaS applications. Microsoft Entra ID supports SCIM both **inbound** (provisioning into Entra ID from an HR system) and **outbound** (provisioning from Entra ID into third-party SaaS apps).
## SCIM outbound — Entra ID to SaaS apps
This is the more common scenario. Entra ID acts as the source of truth, and changes — user created, attributes updated, user disabled — sync automatically to SaaS apps via SCIM:
- **User created in Entra ID** → user auto-provisioned in Salesforce, ServiceNow, Slack, GitHub, AWS, etc.
- **Attribute change** (job title, department, manager) → propagated to all downstream apps.
- **User disabled** → user deprovisioned in all SCIM-connected apps within minutes.
- **Group membership change** → role assignment updated in the target app.
This is how a mature Entra ID tenant achieves **automated joiner-mover-leaver**: HR triggers a change in Entra, and the change flows everywhere automatically.
## Configuration
In the Entra admin center, find the **Enterprise application** for the SaaS app and choose **Provisioning**:
1. Configure **Admin Credentials** — the SCIM endpoint URL and bearer token from the SaaS app's setup.
2. Configure **Mappings** — how Entra attributes map to SaaS attributes.
3. Configure **Scope** — assigned users / groups, or all users.
4. Start the provisioning job.
Entra evaluates the scope periodically (every 40 minutes by default) and reconciles state. Logs show every action with success / failure detail.
## SCIM inbound — HR to Entra ID
The reverse pattern: an HR system (Workday, SAP SuccessFactors, Oracle HCM) pushes employee data to Entra ID via SCIM, creating and updating users automatically. Specific HR connectors exist for major systems; generic SCIM 2.0 inbound provisioning supports any SCIM-compliant HR source.
This pattern means **HR is the source of truth** for employee data. New hires appear in Entra ID before their first day; departures disable accounts on the right day.
## Cross-tenant synchronization
A specialised form of inbound SCIM: **Cross-tenant synchronization** auto-provisions B2B guest users between Entra ID tenants in a **Multi-Tenant Organisation**. Configured in the Entra admin center, it keeps guest user objects in sync between tenants in the MTO without manual invitation.
## SCIM vs SAML vs OIDC
These are different concerns:
- **SAML / OIDC** is for **authentication** — when a user signs into an app.
- **SCIM** is for **provisioning** — when an account is created/updated/deleted in an app.
Most SaaS apps use SAML or OIDC for SSO **and** SCIM for provisioning, configured independently in the same Entra ID enterprise app.
## Operational considerations
- **Attribute mappings** are the most common source of issues — wrong mapping = wrong data downstream. Test thoroughly.
- **Cycle frequency** is fixed at 40 minutes — important changes still take time to propagate. Combined with **Conditional Access** revocation for urgent disables.
- **Manual invitations** and **automated SCIM** can conflict — pick one as the source of truth per app.
For tenants growing their SaaS footprint, SCIM is the difference between "one new SaaS app, one new manual provisioning process" and "everything connects automatically."
## Frequently asked questions
**What is SCIM provisioning in Entra ID?**
Automatic creation, update, and deactivation of user accounts in a SaaS app based on assignments in Entra, using the SCIM standard. Assign a group to the app and users appear in the app; remove them and they are disabled. It replaces manual account admin in the app.
**Why are users not provisioning to my SaaS app?**
The user is not assigned to the app, the attribute mapping produces an invalid value (a missing required attribute such as email), the app rejected the request (check the provisioning logs), or the provisioning cycle has not yet run — initial cycles can take up to 40 minutes and incremental ones run about every 40 minutes.
**Can SCIM provisioning deprovision users when they leave?**
Yes — when a user is unassigned, deleted, or soft-deleted in Entra, the provisioning service disables (or deletes, depending on the app) the account in the target app on the next cycle. Combined with Lifecycle Workflows or HR-driven provisioning, this is how leavers lose SaaS access automatically.
---
# Microsoft Sentinel analytic rules
URL: https://www.solvingmicrosoft365.com/guides/sentinel-analytic-rules
Category: Microsoft Defender (Security)
Published: 2026-05-01
> How analytic rules work in Sentinel — types, tuning, and writing custom detections.
**Analytic rules** are the detection engine of Microsoft Sentinel — KQL queries that run on schedule against ingested data, generating alerts and incidents when matching patterns are found. Understanding rule types, tuning approach, and custom-rule authoring is what separates basic Sentinel deployment from a working detection programme.
Rules are written in the language of the [KQL primer](/guides/kql-primer-for-defender-xdr), run against data connected per [Sentinel onboarding](/guides/microsoft-sentinel-onboarding), and produce the incidents handled in the [incident response runbook](/guides/microsoft-365-incident-response); many start life as hunting queries in [Defender XDR advanced hunting](/guides/defender-xdr-advanced-hunting).
## The rule types
Sentinel supports several analytic rule types:
### Scheduled
The most common — runs a KQL query on a recurring schedule, generates alerts on matches.
- **Query interval** — how often to run (every 5 minutes, every hour, etc.).
- **Lookup period** — how far back to query.
- **Threshold** — how many matches before alerting.
- **Entity mapping** — which fields are users, devices, IPs, hashes.
Most rules are scheduled rules.
### Near real-time (NRT)
For very fast detection on specific events:
- Runs every minute against the last minute of data.
- Lower latency than scheduled rules.
- Limited compared to scheduled — simpler queries, less complex aggregation.
Used for high-priority detections where minutes matter — confirmed account compromise, mass-deletion detection.
### Microsoft Security
Pre-built rules that **forward Defender XDR alerts into Sentinel** as incidents. Don't author these; just enable them per product (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps).
### Anomaly
Built-in ML-based anomaly detection. Microsoft ships these; you tune by deciding which behaviours are "normal" for your environment.
### Fusion
The cross-product correlation engine. Combines signals from multiple sources into multi-stage incident detection.
### Threat Intelligence
Match logged events against threat-intelligence indicators (IP addresses, file hashes, domains).
## Tuning rules
Out of the box, many rules generate **more alerts than you can investigate**. Tuning is essential:
### Suppress known-good
Add exclusions for:
- **Internal vulnerability scanners** that look like attackers.
- **IT operations activities** that look like attacker behaviour.
- **Service accounts** with elevated permissions doing legitimate things.
- **Backup software** with broad file-access patterns.
- **DevOps pipelines** with unusual cross-service patterns.
### Adjust thresholds
A rule alerting on "10 failed sign-ins" may produce too many alerts; raising to "50 failed sign-ins" tightens.
### Time-of-day filtering
Some activities are normal at 14:00, suspicious at 03:00. Add time-aware logic.
### Entity grouping
Combine multiple events into single incidents — group failures by same user / device / IP.
## Custom rule authoring
For your specific environment, you'll write custom rules. The pattern:
```kql
// Detect unusual data export by departing employees
let HRData = externaldata(UserPrincipalName:string, DepartureDate:datetime)
[@"https://your-data-source/hr.csv"] with(format="csv");
let DepartingUsers =
HRData
| where DepartureDate between (now() .. now()+30d);
SignInLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName in (DepartingUsers | project UserPrincipalName)
| join kind=inner OfficeActivity on $left.UserPrincipalName == $right.UserId
| where Operation in ("FileDownloaded", "SyncDownloadedFiles")
| summarize TotalDownloads = count() by UserPrincipalName, bin(TimeGenerated, 1h)
| where TotalDownloads > 100
```
Key elements:
- **External data** for context (HR data here).
- **Time filtering** for performance.
- **Join** against relevant signals.
- **Aggregation** for threshold logic.
- **Output** with the right entities mapped.
## Rule lifecycle
1. **Author rule** in the workspace.
2. **Test** with historical data — verify it would have detected past events.
3. **Run in alert-only mode** for a week — see what fires.
4. **Tune** based on findings.
5. **Promote to incident creation** when stable.
6. **Periodic review** as the environment evolves.
## Operational discipline
- **Document every rule** — what it's for, expected fire rate, owner.
- **Track false-positive rate** per rule — high FP rules need tuning or retirement.
- **Quarterly rule review** — what's still useful, what to retire.
- **Test before deploying** custom rules — bad rules generate alert storms.
## Where to learn
- **GitHub repository** of community-shared Sentinel queries.
- **MITRE ATT&CK** framework — many Sentinel rules map to specific ATT&CK techniques.
- **Microsoft Learn** Sentinel learning paths.
- **Sentinel content hub** for vendor-published rule packs.
For mature SOC operations, custom analytic rules are where Sentinel's value compounds — your team writes detections specific to your environment, your threats, your patterns. The pre-built rules are a starting point; the custom rules are the durable investment.
---
# Microsoft Service Trust Portal and compliance documentation
URL: https://www.solvingmicrosoft365.com/guides/service-trust-portal-and-compliance-docs
Category: Microsoft Purview (Compliance)
Published: 2026-05-01
> Where to find Microsoft's compliance certifications, audit reports, and data-handling commitments.
The **Microsoft Service Trust Portal (STP)** at `servicetrust.microsoft.com` is the central library of **Microsoft's compliance certifications, audit reports, security documentation, and data-handling commitments**. It's where your compliance team gets the artefacts they need to satisfy auditors, regulators, and customer due diligence.
The portal's documents back [Compliance Manager](/guides/compliance-manager) assessments and the assurance controls [Customer Key](/guides/customer-key-for-microsoft-365) and [Customer Lockbox](/guides/customer-lockbox-deep-dive); residency and isolation questions are answered in [tenant isolation and data residency](/guides/microsoft-365-tenant-isolation-and-data-residency), and the government-cloud variant in [Microsoft 365 vs Microsoft 365 Government](/guides/microsoft-365-vs-microsoft-365-government).
## What's in the STP
A non-exhaustive catalogue:
### Audit reports
- **SOC 1, 2, and 3** reports for Microsoft cloud services.
- **ISO 27001, 27017, 27018, 22301** certifications and audit reports.
- **PCI DSS** attestations of compliance.
- **FedRAMP** documentation for US government scenarios.
- **HIPAA** business associate agreements and supporting docs.
- Country-specific certifications — UK G-Cloud, German C5, Singapore MTCS, Australian IRAP, and many more.
### Compliance frameworks
- Microsoft's mapping of services against specific regulatory frameworks.
- GDPR commitments and supporting materials.
- HIPAA, FERPA, FISMA, CJIS specific documentation.
### Operational documentation
- **Microsoft 365 data location** by region.
- **EU Data Boundary** details.
- **Customer Lockbox** behaviour and access procedures.
- **Data subject rights** documentation for GDPR.
- **Incident notification** procedures.
### Tools
- **Compliance Manager** integration — assessments linked to Microsoft's underlying controls.
- **Compliance Score** components.
- **Audit-related FAQs** for common compliance questions.
## How to use it
For most compliance scenarios:
### Customer due diligence
When a prospect or partner asks "are you SOC 2 compliant for the services you use?":
- Pull the relevant SOC 2 report for Microsoft 365 from STP.
- Combine with your own SOC 2 (or other) report.
- Present together as evidence that the full chain of services is audited.
### Regulator inquiry
When a regulator asks about specific compliance:
- Find Microsoft's documentation for the relevant regulation.
- Combine with your tenant's specific configuration evidence.
- Present a coherent compliance picture.
### Internal audit
For internal audit functions evaluating your Microsoft 365 estate:
- Use STP documentation to confirm Microsoft's responsibilities under the shared responsibility model.
- Combine with **Compliance Manager** scores for your tenant-specific compliance posture.
## Shared responsibility model
A crucial concept the STP makes explicit: Microsoft 365 operates under a **shared responsibility model** between Microsoft and the customer. Microsoft is responsible for:
- Infrastructure security.
- Service operations and availability.
- Some baseline platform security features.
Customers are responsible for:
- Identity (users, MFA, Conditional Access).
- Data classification and labelling.
- Endpoint security on customer-managed devices.
- Configuration of security and compliance features in the tenant.
The STP documents Microsoft's side of this clearly. Your tenant's compliance documentation has to cover the customer side.
## Authentication and access
The STP is **freely accessible** for most content — no Microsoft 365 sign-in required. Some sensitive documents (specific audit reports, NDA-required content) require Microsoft 365 sign-in with a tenant admin role or specific licensing.
## Related portals and tools
- **Compliance Manager** (`purview.microsoft.com`) — tenant-specific compliance scoring linked to STP documentation.
- **Microsoft Trust Center** (`microsoft.com/trust-center`) — broader trust-related content (privacy, security, transparency).
- **Microsoft Privacy Statement** — published commitments on data handling.
- **Service-level agreement (SLA) pages** — uptime commitments per service.
## Operational rhythm
A mature compliance function:
- **Subscribes to STP updates** — Microsoft publishes new audit reports annually.
- **Reviews STP at audit time** — pulls the current versions of relevant reports.
- **Tracks compliance certifications** Microsoft adds/removes over time.
- **Documents the shared responsibility split** in their own internal policies.
For organisations in regulated industries, the STP is essential reference material. For organisations less encumbered, it's the right place to point auditors when they ask about Microsoft's controls without having to argue the case yourself.
---
# ServiceNow with Microsoft 365
URL: https://www.solvingmicrosoft365.com/guides/servicenow-with-microsoft-365
Category: Microsoft 365 essentials
Published: 2026-05-01
> How ServiceNow integrates with Microsoft 365 — SSO, Teams, Outlook, Graph connectors, and ITSM automation patterns.
**ServiceNow** is the leading IT service management (ITSM) platform, used by many large enterprises for incident, problem, change, and request management. Integration with Microsoft 365 is mature and multi-faceted — knowing the integration points lets you exploit them properly.
Integration rests on [SAML SSO](/guides/saml-sso-with-entra-id), [SCIM provisioning](/guides/scim-provisioning-to-entra-id), the [Graph API](/guides/microsoft-graph-api-basics), and — for Copilot — a Graph connector per [extensions and plugins](/guides/microsoft-365-copilot-extensions-and-plugins); ticket-driven automation often runs in [Power Automate](/guides/what-is-power-automate).
## SSO with Entra ID
The starting point: ServiceNow as a SAML- or OIDC-integrated app in **Microsoft Entra ID**. Configured in the **Enterprise applications gallery**, the integration handles:
- SSO from Microsoft 365 to ServiceNow with one click.
- Conditional Access policies applied to ServiceNow sign-ins.
- SCIM provisioning to keep ServiceNow user accounts in step with Entra.
- Role assignment via Entra ID groups.
For multinational organisations, ServiceNow + Entra ID + Conditional Access is essentially mandatory.
## Microsoft Teams integration
ServiceNow's Teams integrations bring ITSM into the collaboration surface:
- **Virtual Agent for Teams** — a chatbot that handles common service requests directly in Teams chat.
- **ServiceNow app for Teams** — view tickets, create new tickets, approve change requests without leaving Teams.
- **Adaptive cards** in Teams chat for notifications about ticket updates, approvals, incidents.
- **Teams meetings integration** for major incident calls with ServiceNow incident records.
For organisations using Teams heavily, surfacing ITSM in Teams dramatically improves request submission and ticket-update visibility.
## Outlook integration
Email-driven request creation, approval emails, escalation notifications — ServiceNow integrates with Outlook for ticket-related email flows. Microsoft 365 actionable messages let users approve change requests directly from their Outlook inbox.
## Graph connectors
A **Microsoft Graph connector for ServiceNow** indexes ServiceNow records — knowledge articles, incidents, requests — into **Microsoft Search** and **Microsoft 365 Copilot grounding**. Users searching for "VPN issue" find both the IT VPN setup SharePoint page (internal) and the relevant ServiceNow knowledge article — unified discovery.
For Copilot tenants, this is one of the most valuable integrations — Copilot can answer ITSM questions grounded in your specific knowledge base rather than generic web content.
## Automation patterns
**Power Automate** has hundreds of ServiceNow connectors available. Common patterns:
- **Approval routing** — Power Automate orchestrates approvals for ServiceNow change requests via Teams adaptive cards.
- **Ticket creation from Microsoft 365 signals** — DLP detection creates a ServiceNow incident; Defender alert creates an incident.
- **Cross-system reporting** — pull ServiceNow data into Power BI alongside Microsoft 365 telemetry.
## Microsoft Defender XDR + ServiceNow
For security operations, the **Defender XDR + ServiceNow integration** automates ticket creation for security incidents, with bidirectional sync — incident status changes flow between platforms. Reduces analyst friction; automates the routine ITSM side of security response.
## When this matters most
- **Large enterprises** with ServiceNow as the ITSM standard.
- **Microsoft 365 customers** wanting consolidated user experience across collaboration and IT requests.
- **Security operations** wanting Defender XDR feeding ServiceNow incident records.
- **Tenants rolling out Copilot** wanting Copilot to find ServiceNow knowledge.
For organisations with both platforms, **investing time in the integrations is one of the higher-leverage moves available**. ServiceNow's value goes up when it's in Teams rather than separate; Microsoft 365's value goes up when it can surface ServiceNow content via Copilot. The investment is one-time setup with continuous payoff.
---
# Shared mailboxes explained
URL: https://www.solvingmicrosoft365.com/guides/shared-mailboxes-explained
Category: Exchange & Outlook
Published: 2026-05-01
> Shared mailboxes are mailboxes multiple people can monitor. Here's how they differ from groups, distribution lists, and personal mailboxes.
A **shared mailbox** is a mailbox in Exchange Online that several people can read and send from, without needing a licence per person. They're how addresses like `support@`, `sales@`, or `info@` get handled by a team rather than an individual.
## What a shared mailbox is
A shared mailbox:
- Has its own primary SMTP address.
- Doesn't require a Microsoft 365 licence (up to 50 GB; beyond that, it does).
- Can't be signed into directly — there's no password.
- Is **accessed by delegated users** who have Full Access and/or Send As / Send on Behalf permissions.
- Shows up in Outlook automatically for those users via auto-mapping.
For each delegated user, the shared mailbox appears as a separate folder under their mailbox tree in Outlook, OWA, and the mobile app.
## What it's good for
- **Generic team addresses**: support, sales, info, hr, careers.
- **Ticketing queues** that don't yet have a ticketing system.
- **Functional roles** that change owner over time without disrupting the address.
## Shared mailboxes vs Microsoft 365 Groups
A **Microsoft 365 Group** is much more than an email address — it also has a SharePoint site, a OneNote, a Planner plan, and can be the basis of a Teams team. Mail to a group can land in members' inboxes or in the group's own conversation history.
If the team wants a shared workspace alongside the inbox, a **group** is usually the better choice. If they just need a shared address to monitor and reply from, a **shared mailbox** is simpler.
## Shared mailboxes vs distribution lists
A **distribution list** (or distribution group) is a fan-out address: mail sent to it is delivered to each member's personal inbox. There's no shared storage. Compared to a shared mailbox, this means no collaborative read/reply, but everyone gets their own copy. Use it for **announcements**, not for **shared queues**.
## Operational tips
- Set delegated users to **send on behalf** or **send as** depending on whether you want the original sender's name to appear.
- Use **Sent Items copy** settings (an option in Exchange) so sent mail lands in the shared mailbox's Sent folder, not the sender's personal one.
- Apply **Purview retention** to shared mailboxes the same way you do to personal ones.
- For high-volume scenarios, route the address into a real **ticketing system** (Zendesk, ServiceNow, Dynamics) instead of letting it grow.
Shared mailboxes are a great low-cost starting point for team-based email. They're a stop-gap for serious workflow, not a destination.
## Licensing edge cases worth knowing
The "no licence needed" rule has real limits that catch tenants out. A shared mailbox growing past **50 GB** needs a licence assigned to it (any Exchange Online plan) purely to unlock the larger quota — the mailbox still can't be signed into directly, but it stops being genuinely free at that size. Separately, if a shared mailbox needs to be enabled for **Microsoft 365 Copilot, in-place archiving beyond the default, or litigation hold**, it typically needs an appropriately licensed user technically associated with it, since those capabilities are gated by licence regardless of the mailbox type. Treat "shared mailboxes are free" as true only for straightforward, moderate-volume use — anything approaching enterprise archival or AI-feature requirements needs the same licensing conversation a personal mailbox would.
## Frequently asked questions
**Can a shared mailbox send external mail without exposing which delegate actually replied?** Yes — with **Send As** configured (rather than Send on Behalf), outbound mail shows only the shared mailbox's address as the sender, with no indication of which delegated staff member actually typed the reply; this is the standard configuration for support and sales addresses where a consistent single-sender identity matters more than internal attribution.
**Do shared mailbox permissions show up in an access review?** Not by default in most Entra ID access review configurations, since Full Access and Send As permissions are Exchange-native grants rather than group memberships — a periodic manual review (or a script pulling mailbox permissions via Graph PowerShell) is the practical way to audit who has access to a shared mailbox, since it won't automatically surface in the same governance tooling used for group-based access.
---
# SharePoint Advanced Management
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-advanced-management
Category: SharePoint & OneDrive
Published: 2026-05-01
> SharePoint Advanced Management adds governance, oversharing controls, and Copilot-ready controls to SharePoint Online.
**SharePoint Advanced Management (SAM)** is a paid add-on for Microsoft 365 that ships extra governance, security, and lifecycle features on top of SharePoint Online. It's become especially important since Microsoft 365 Copilot launched — many of SAM's features are also bundled into Copilot prerequisites.
## What's in SAM
The major capabilities, grouped:
### Oversharing visibility
- **Data access governance (DAG) reports** for sites with too many people, "Everyone except external" usage, or sensitivity-label drift.
- **Site lifecycle reports** — inactive sites, sites with too many owners or none.
- **Permissions reports** scoped to a site, library, or item.
### Sharing controls
- **Restricted access controls** at the site level — only specific Entra ID groups can access a given site, overriding sharing links.
- **Block download** policies — preview-only access from the browser, no local copies.
- **Default sharing link types** at site granularity.
- **Site-level conditional access** that ties into Intune compliance.
### Lifecycle
- **Inactive site policies** — auto-flag, remind owners, and archive sites that haven't been touched in N days.
- **Site archive** — move a site to a low-cost archive state, recoverable, while removing it from active search and Copilot grounding.
### Microsoft 365 Copilot readiness
SAM provides the inputs to two important Copilot-related reports: which sites are oversharing, and which should be excluded from Copilot grounding. Restricted access controls and archive policies are the two main levers.
## Licensing
SAM is sold per user per month, with availability via a standalone SKU and as part of higher-tier plans and Copilot bundles. Tenants on E5 or Microsoft 365 Copilot increasingly find it included or heavily discounted.
## Where SAM fits in your governance stack
SAM lives alongside:
- **Microsoft Purview** for retention, sensitivity labels, DLP, and eDiscovery.
- **Entra ID Identity Governance** for access reviews and entitlement management of the groups behind site permissions.
- **Microsoft 365 admin center** for the base lifecycle of groups and licences.
None of these replaces the others. SAM specifically handles SharePoint-level controls that the broader Purview and Entra tools can't see in granular detail.
For any organisation rolling out Copilot, SAM is no longer optional. It's the difference between an informed rollout and surprise oversharing.
## Frequently asked questions
**Do we need SAM if we're not deploying Copilot?** The lifecycle and oversharing-visibility features (inactive site reports, permissions reports, restricted access controls) are useful on their own for any SharePoint estate that's grown past the point where admins can eyeball every site's permissions — Copilot is what made SAM urgent for most tenants, but the governance value stands independently of it.
**How is SAM different from the sharing settings already in the SharePoint admin center?** The baseline SharePoint admin center controls set tenant-wide defaults (external sharing on/off, link types). SAM operates at a finer grain — per-site restricted access tied to specific Entra ID groups, block-download policies, and reporting that surfaces *which* sites and files are actually oversharing right now, rather than just what the default policy theoretically allows.
**What's the fastest first action with SAM?** Run a data access governance report against the tenant's most active sites and look specifically for "Everyone except external users" grants and sites with an unusually high sharing-link count — those two signals catch the majority of real oversharing risk before any Copilot-specific tuning is needed.
**Does restricting a site with SAM's access controls break existing sharing links?** Restricted access controls scope who can reach the site at all, layered on top of (not replacing) whatever sharing links already exist — a link shared with someone outside the newly-restricted group stops resolving for them even though the link itself is technically still valid, which is the intended tightening but is worth testing on a pilot site before applying broadly, since it can surprise site owners who assumed existing links would keep working unconditionally.
**Does SAM apply to OneDrive as well as SharePoint sites?** Several SAM capabilities extend to OneDrive — notably block-download policies and some of the oversharing reports — since OneDrive for Business is itself built on the same SharePoint platform underneath. It's worth checking the specific feature's documented scope rather than assuming every SAM capability covers both uniformly, since a handful remain SharePoint-site-only.
---
# SharePoint communication sites deep dive
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-communication-sites
Category: SharePoint & OneDrive
Published: 2026-05-01
> How to build and operate effective SharePoint communication sites — intranet portals, news hubs, and broadcast pages.
A **SharePoint communication site** is designed for **broadcasting information to a wide audience** — intranet portals, departmental news hubs, HR-policy reference, knowledge bases. Different from **team sites** (workspaces for collaborating groups), communication sites are read-oriented for most users with a small set of authors.
## When to choose a communication site
- **Department intranet** — HR, Finance, IT, Engineering portal pages.
- **Corporate news hub** with regularly-published articles.
- **Reference content** — policies, procedures, knowledge base articles.
- **Brand assets and templates** library.
- **Onboarding portals** for new hires.
Not the right choice for:
- **Collaborative team workspaces** — use team sites.
- **Project workspaces** — use Microsoft Teams (which creates a team site).
- **Shared editing environments** — communication sites assume read-mostly.
## Site templates
When creating a communication site, Microsoft offers templates:
- **Topic** — for general broadcast content with news and links.
- **Showcase** — for visual content with hero images and gallery layouts.
- **Blank** — start from scratch.
Plus industry templates (healthcare, government, nonprofit) that pre-populate with relevant content patterns.
## Building a good communication site
A few principles:
### Design with the homepage as the hero
The homepage is where most users start. Invest in:
- **Hero web part** — visual entry points to key content.
- **News web part** — recent articles surfaced.
- **Quick links** — frequently-accessed pages and external resources.
- **Events web part** for upcoming dates.
- **People web part** highlighting team members.
A great homepage answers "what should I look at first?" in 5 seconds.
### Information architecture matters
Plan the **navigation** before building pages:
- **Top navigation** — major sections.
- **Hub navigation** (if the site is part of a hub) — shared across the hub.
- **Footer navigation** — terms, contact, legal.
Keep navigation depth shallow — 2 levels usually enough. Too-deep navigation loses users.
### News as continuous engagement
The **news posts** feature drives ongoing engagement:
- Authors publish news posts on the site.
- Posts surface in the homepage news web part.
- Posts can appear in Viva Connections feeds.
- Subscribed users get email digests via **news digest**.
For corporate-communications scenarios, news posts are how the comms team reaches employees consistently.
### Audience targeting
For mixed-audience sites, **audience targeting** in modern SharePoint lets specific content show only to specific groups:
- Pages — visible only to specific audiences.
- Links in navigation — different links per audience.
- Library content — surfaced based on user attributes.
Built on Entra ID groups; powerful for personalisation.
## Permissions model
Communication sites typically have:
- **Site members** — small set of authors with edit permissions.
- **Site visitors** — broad audience with read permissions (often "Everyone except external users" or a specific group).
- **No external sharing** for most intranet content (unless intentional public-facing).
Unlike team sites, communication sites aren't connected to a Microsoft 365 Group — no shared mailbox, no Teams team. They're pure content surfaces.
## Hub integration
Most communication sites are part of a **hub site**:
- The hub provides shared navigation across the hub's associated sites.
- Hub search aggregates results across the hub.
- Theme and branding shared.
A typical corporate intranet has a **home site** (top of hub hierarchy) with associated department hubs (HR hub, IT hub, etc.), each hub having its own communication sites and team sites.
## Operational considerations
- **Named owner** for every communication site — who maintains it.
- **Editorial calendar** for news posts — consistent cadence beats sporadic flurries.
- **Analytics** — built-in site analytics show what's read, what isn't.
- **Stale content review** — quarterly check for outdated content.
- **Accessibility** — alt text on images, proper heading structure, sufficient colour contrast.
## Viva Connections integration
For organisations with **Viva Connections** enabled, the corporate home site becomes the **Connections home** experience in Teams. Users see the intranet experience inside Teams, with personalised dashboard cards alongside the SharePoint pages.
For organisations with serious intranet investment, communication sites plus Viva Connections deliver a modern, mobile-friendly, personalised intranet at fraction of the cost of dedicated intranet products.
---
# SharePoint document libraries — a deep dive
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-document-libraries-deep-dive
Category: SharePoint & OneDrive
Published: 2026-05-01
> Document libraries are the workhorse of SharePoint. Here's what they actually do beyond "a folder in the cloud."
A **document library** in SharePoint Online looks like a folder full of files. Under the hood it's a structured list with rich metadata, versioning, and permissions — and once you treat it as such, much more becomes possible.
## What a library actually is
Every document library is a **list of items**, where each item is a file (or folder). Each item has built-in columns (Name, Modified, Modified By) and can have **custom columns** you define — text, number, choice, person, date, taxonomy. Custom columns let you tag content for search, filtering, and views.
## Views
Views are saved configurations of columns, filters, sorting, and grouping. The same library can have a flat view for everyone, a grouped-by-project view for the PMO, and a filtered "my documents" view. Modern SharePoint also supports:
- **Tiles view** for visual content libraries.
- **Conditional formatting** with column-based highlighting.
- **JSON formatting** for custom rendering of column values.
Views are surfaced as URLs, so you can bookmark or link to a specific view.
## Versioning and history
Document libraries keep **major version history** by default (up to 500 versions). Older versions are recoverable in place. You can also turn on **minor versions** (drafts vs published) for content that needs an approval flow.
## Co-authoring
Office files in a SharePoint library are **co-authored** — multiple users can edit simultaneously in Word, Excel, or PowerPoint, both in the desktop and web apps. Locking, presence, and merge happen automatically.
## Approvals, retention, and labels
A library can have:
- **Content approval** — items aren't visible to non-editors until approved.
- **Retention policies** from Purview applied automatically.
- **Sensitivity labels** at the file level, inherited from defaults or applied by users.
- **Information barriers** to prevent specific groups from accessing.
## Sync, share, and the file explorer experience
Libraries can be **synced** to a workstation via OneDrive's sync client, and **added as a shortcut** to a user's OneDrive (the "Add shortcut to OneDrive" button). Both feel like local folders to the user but are still subject to all the SharePoint permissions, retention, and policies above.
Treating a library as "just a folder" works until it doesn't. Once the metadata, views, and policies are in place, you're using SharePoint the way it was designed.
## Content types
A **content type** is a reusable, named bundle of columns, document templates, and workflow/retention behaviour that can be attached to multiple libraries across a site or a whole site collection — defined once (say, "Contract," with columns for counterparty, expiry date, and value) and reused everywhere contracts live, rather than recreating the same columns library by library. Content types are what make Purview retention labels and DLP policies scale sensibly across many libraries: label a content type once, and every library using it inherits the behaviour, instead of an admin configuring retention per library by hand.
## Storage and the "list view threshold" in practice
The 5,000-item view threshold isn't a hard cap on library size — libraries scale to millions of items — but it does mean **library structure has to be designed with views in mind from the start**, not retrofitted after the fact. A flat library with a single "all items" view and no indexed columns will simply stop returning results once a folder or filtered set crosses 5,000 items, with an error rather than a slow query. The fix is either an **indexed column** on whatever field is filtered most often (department, status, date), or splitting genuinely distinct content into separate libraries rather than one library growing without any metadata-driven filtering at all.
## Frequently asked questions
**Can a document library be restored if content is deleted by mistake?** Yes, in layers: the site's own recycle bin holds deleted items for 93 days (recoverable by anyone with edit rights), a second-stage recycle bin extends that window further for site admins, and version history separately lets you roll back an overwritten file to an earlier version without needing to restore a deletion at all.
**How many document libraries should one site have?** As few as the actual access-control boundaries require — a common mistake is creating a new library per project or per team within a single site when a single library with metadata columns (project name, team) and filtered views would serve the same navigational need with far less administrative overhead, reserving a genuinely separate library for content that needs distinct permissions or retention behaviour from the rest of the site.
## Frequently asked questions
**What is the SharePoint list view threshold?**
5,000 items in a single view or query is the point where SharePoint requires an indexed column or filtered view to return results; libraries can hold up to 30 million items, but views and sync behave badly beyond a few hundred thousand. Design libraries and folders so views stay under the threshold.
**Should we use folders or metadata in SharePoint?**
Both, in moderation. Metadata (columns, content types) enables filtering, views, and search; folders enable simple navigation, sync, and per-folder permissions. Deep folder trees hit path-length limits and hide content; flat libraries with metadata are the recommended pattern, with a few folders for humans.
**How does versioning work in document libraries?**
Every save creates a version (500 major versions by default, configurable); users can view and restore versions. Since 2024, intelligent versioning trims old versions automatically to save storage. Versions count against storage quota.
---
# SharePoint Embedded
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-embedded
Category: SharePoint & OneDrive
Published: 2026-05-01
> SharePoint Embedded lets developers use SharePoint storage and capabilities inside their own custom applications.
**SharePoint Embedded** is the developer-targeted version of SharePoint — letting you use SharePoint's storage, search, AI, and governance capabilities **inside your own custom applications** without those applications being part of Microsoft 365 directly. It's how Microsoft is opening up SharePoint as a platform for app developers.
SharePoint Embedded is the developer counterpart to the sites in [What is SharePoint](/guides/what-is-sharepoint); it is accessed through the [Graph API](/guides/microsoft-graph-api-basics), inherits [Purview](/guides/what-is-microsoft-purview) controls, and shares the storage model with [document libraries](/guides/sharepoint-document-libraries-deep-dive).
## What SharePoint Embedded provides
A custom application built on SharePoint Embedded can:
- **Store files** in customer-isolated containers backed by SharePoint storage.
- **Use SharePoint search** for content discovery within the application.
- **Leverage Microsoft Purview** for content classification, retention, eDiscovery.
- **Use Microsoft Graph** for programmatic file operations.
- **Apply sensitivity labels** to stored content.
- **Use Microsoft 365 Copilot** to ground answers on the embedded content.
- **Inherit Microsoft 365 identity and security** — Entra ID, Conditional Access apply.
The customer-isolated **container** is a unit of storage and governance, similar to a SharePoint site but designed for the embedded application model. Each container is created and owned by the app, scoped to specific users or organisational scope.
## Why this exists
Historically, app developers building content-centric apps faced a choice:
- **Roll their own storage** (S3, Azure Blob, custom file servers) — significant engineering burden for compliance, governance, search.
- **Build on the existing Microsoft 365 surface** — but that surface (SharePoint sites and lists) wasn't designed for embedded use.
SharePoint Embedded fills the gap: the underlying SharePoint storage and capabilities, but with a developer-first API and an app-controlled model.
## Use cases
- **Customer-facing applications** that handle documents — contract management, claims processing, document collaboration tools.
- **Industry-specific applications** — health records, legal case management, compliance dashboards.
- **Partner-built solutions** — ISV applications that ship to many Microsoft 365 customers.
- **Custom enterprise apps** that need richer content handling than building from scratch.
## How it differs from SharePoint Online
- **SharePoint Online sites** are the user-facing surface inside the Microsoft 365 admin model.
- **SharePoint Embedded containers** are isolated app-controlled containers, not visible in the user's SharePoint navigation by default. The application surfaces them through its own UI.
The underlying storage technology is the same; the access model differs.
## Licensing
SharePoint Embedded is billed on a **pay-as-you-go** consumption model based on storage and operations, separate from Microsoft 365 plan licensing. The application doesn't require its end users to have specific Microsoft 365 plans for many scenarios.
## Where this fits in 2026
SharePoint Embedded is a relatively new Microsoft platform — most actively adopted by:
- **ISVs** building line-of-business apps for Microsoft 365 customers.
- **Microsoft itself** — Microsoft 365 Copilot containers, Loop workspaces, and other Microsoft products are built on SharePoint Embedded under the hood.
- **Enterprises** building custom content-heavy applications.
For most Microsoft 365 administrators, SharePoint Embedded is "interesting but not directly relevant" — it's a developer platform, not an admin surface. For developers building apps on Microsoft 365 infrastructure, it's increasingly the right answer for content storage.
---
# SharePoint Framework (SPFx) overview
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-framework-spfx-overview
Category: SharePoint & OneDrive
Published: 2026-05-01
> SPFx is Microsoft's modern client-side development model for extending SharePoint and Microsoft 365. Here's how it works.
The **SharePoint Framework (SPFx)** is the modern client-side development model for building extensions to SharePoint Online, Microsoft Teams, Outlook, and Microsoft 365 Copilot. It replaced the legacy server-side and full-trust development model with a clean Node.js / TypeScript stack that runs in the user's browser with the user's identity.
SPFx builds on [Graph API basics](/guides/microsoft-graph-api-basics) and targets [pages and web parts](/guides/sharepoint-page-design-and-web-parts) and [Teams tabs](/guides/microsoft-teams-apps-and-tabs); for low-code alternatives see [list formatting](/guides/sharepoint-list-formatting) and [Power Apps](/guides/what-is-power-apps).
## What SPFx is used for
Common SPFx artefacts:
- **Web parts** — custom blocks that authors can drop into SharePoint pages alongside the built-in web parts (a customer dashboard, a survey, a CRM widget).
- **Extensions** — Application Customizers (add header/footer to every page), Field Customizers (custom rendering for list columns), Command Sets (custom commands in list toolbars).
- **Teams tabs and personal apps** — SPFx-built solutions can deploy as Teams apps.
- **Outlook and Microsoft 365 Copilot extensions** — newer convergence with the Microsoft Teams app model.
The same code base, with the right manifest, can ship to multiple surfaces.
## The development stack
- **Node.js LTS**, **Yeoman**, **gulp**, **TypeScript**.
- **React** is the default UI framework (other frameworks are possible but less idiomatic).
- **PnPjs** — community library for Microsoft Graph and SharePoint REST work, much friendlier than raw fetches.
- **Microsoft Graph and SharePoint REST API** for backend interaction.
- **App Catalog** — tenant-wide or site-collection-level catalog where built `.sppkg` packages are deployed.
The default tooling produces a single `.sppkg` you upload to the catalog; from there the solution is available across sites or scoped to specific sites.
## Authentication and permissions
SPFx solutions run as the signed-in user. To call Graph or other APIs, they use **Microsoft Graph Toolkit** components or `MSGraphClient` / `AadHttpClient` with **permission scopes** declared in the manifest. Tenant admins must **approve** those scopes in the SharePoint admin center's **API access** page before the solution can call the APIs.
## Where SPFx fits today
- **Custom intranet experiences** — branded landing pages with bespoke web parts.
- **Line-of-business integration** — Teams tabs and SharePoint web parts that surface external systems.
- **Microsoft 365 Copilot extensions** built using the Teams app SDK model.
Increasingly, the choice between SPFx and **Power Apps / Power Pages / Copilot Studio** depends on the audience: low-code for citizen-developer scenarios, SPFx for pro-developer customisation with full control and version-controlled source.
## When to skip SPFx
- For internal workflow automation, **Power Automate** is faster.
- For custom data apps, **Power Apps** is faster.
- For simple SharePoint customisation, **list formatting JSON** and **modern page web parts** often suffice.
- For full custom applications, **Azure App Service** + **Microsoft Graph** is often cleaner than the SPFx hosting model.
SPFx remains the right answer when you specifically need the artefact to live inside a SharePoint page, a Teams tab embedded in Teams, or a Copilot agent extension built using the Microsoft 365 app SDK.
---
# SharePoint hub permissions and inheritance
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-hub-permissions
Category: SharePoint & OneDrive
Published: 2026-05-01
> How permissions work for hub sites and their associated sites — what's shared, what isn't, and what to watch out for.
**SharePoint hub sites** group associated sites under shared navigation, theme, and search scope. But **permissions don't propagate** between hub and associated sites — each site retains independent permissions, which catches a lot of admins out. Understanding the model prevents surprise access scenarios.
Hubs are introduced in [SharePoint hub sites](/guides/sharepoint-hub-sites) and placed within [information architecture](/guides/sharepoint-information-architecture); the permission model they sit on is [SharePoint permissions explained](/guides/sharepoint-permissions-explained), and the external-sharing interaction is in [SharePoint external sharing](/guides/sharepoint-external-sharing).
## What hub association shares
When a site associates to a hub, it inherits:
- **Top navigation** from the hub.
- **Theme and branding** from the hub.
- **Search scope** — searches from any associated site search across the hub.
- **News roll-up** — the hub's news web part can show news from all associated sites.
What it does **NOT** inherit:
- **Permissions** — each site retains its own membership and access controls.
- **Sensitivity label** — each site has its own (if any).
- **External sharing settings** — each site is independently configured.
- **Storage quota** — each is independent.
- **Site collection admins** — separate.
## Why this matters
A common misconception: "the hub is private to a group, so the associated sites are private too." False — each site's access is determined by its own permissions.
Practical implications:
- **Sensitive site associated to public hub** — the sensitive site stays private. The hub navigation may show its name, but content access requires explicit permission to that site.
- **Public site associated to internal hub** — the public site stays publicly accessible. The hub's restrictions don't override.
- **Internal users see hub navigation** — but clicking through to a restricted site still requires permission to that site.
## Audience targeting in hubs
For navigation that should show different items to different audiences, **audience targeting** in hub navigation lets you scope individual nav links:
- HR portal link visible to all employees.
- Executive resources link visible only to executives group.
- HR business partners link visible only to HRBP group.
Configure in **hub navigation → Edit → toggle audience targeting**. Pair with Entra ID groups for clean filtering.
## Hub-level access governance
For hubs themselves:
- **Hub site owners** can change hub settings, navigation, theme.
- **Anyone with site collection admin** rights on associated sites can disassociate.
- **Hub designation** requires SharePoint Admin role at the tenant level.
No "hub members" group — there's no concept of "members of the hub." Permissions are at the site level.
## Common operational issues
### "Why can users see this hub but not access the site?"
That's working as designed — the hub navigation shows the site exists, but access requires per-site permission. To prevent showing the site at all, use audience targeting on navigation.
### "Permissions changed on the hub but not the sites"
Changing **hub** settings doesn't affect site permissions. Changing **site** settings affects only that site. Mass permission changes require iterating across all associated sites.
### "Sensitivity label on the hub but sites still over-share"
A label on the hub site applies only to the hub. Each associated site's label is independent. For tenant-wide sensitivity-label governance on hubs and associated sites, use **container labels** applied at site creation, with appropriate site-creation policies.
## Hub disassociation
Sites can disassociate from a hub — voluntarily by the site owner, or by the SharePoint Admin. On disassociation:
- Site loses hub navigation, theme, search scope.
- Site retains its own content, permissions, settings.
- News articles from the site no longer roll up to the hub.
Disassociation is non-destructive — the site continues independently.
## Best practices
- **Document hub permissions design** — what the hub-associated-site relationship means in your tenant.
- **Audit periodically** — what sites are associated to which hubs.
- **Use audience targeting** for navigation rather than expecting permissions to filter.
- **Sensitivity-label sites independently** rather than relying on hub inheritance.
- **Train site owners** on the hub model — many think hub means hierarchy of permissions.
For organisations using hubs to organise SharePoint at scale, treating each site's permissions as independent — and using audience targeting where filtering is needed — produces cleaner governance. Trying to bend the hub model into a hierarchical permissions structure produces frustration; embracing the independence works.
---
# SharePoint information architecture
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-information-architecture
Category: SharePoint & OneDrive
Published: 2026-05-01
> How to design a SharePoint site structure that scales — hubs, sites, navigation, and the patterns that work.
SharePoint information architecture is the practice of designing **how content is organised across sites** — what becomes its own site, how sites relate via hubs, how navigation works, where common content lives. Done well, users find things. Done badly, the intranet feels chaotic and useless.
## The modern building blocks
Modern SharePoint Online is built from a few units:
- **Sites** — each its own site collection in modern SharePoint, with isolated permissions, lifecycle, and quota.
- **Hub sites** — sites others can **associate** with, getting shared navigation, theme, and search scope.
- **Home sites** — the tenant's designated landing page, often with **Viva Connections** integration.
- **Navigation** — global (Viva Connections / home site), hub-level, and per-site navigation.
The older nested-subsite pattern is deprecated for new content.
## A typical IA pattern
A common shape that scales for most organisations:
```
Home site (corporate intranet)
├── HR hub
│ ├── HR team site
│ ├── HR communication site (HR portal)
│ ├── HR policies communication site
│ └── HR projects team sites
├── IT hub
│ ├── IT service catalog (communication site)
│ ├── IT operations (team site)
│ └── IT documentation (communication site)
├── Engineering hub
│ ├── Engineering team site
│ ├── Engineering documentation
│ └── Project sites
├── Sales hub
│ └── ...
└── Other functional hubs
```
Each hub has its own navigation, theme, and search scope. Sites associate to one hub. The home site provides global navigation across the whole intranet.
## Designing hubs
A few principles for hub design:
- **One hub per logical business unit** — department, function, business unit.
- **Avoid hub sprawl** — too many hubs (>30) make global navigation cluttered.
- **Hub-to-hub associations** — for very large intranets, hubs themselves can associate to parent hubs (two levels deep typically).
- **Naming consistency** — `HR Hub`, `IT Hub`, `Engineering Hub` is clearer than mixed naming.
## Communication sites vs team sites
- **Communication sites** — broadcasting information to wide audiences. Polished page layouts. Used for hub centres, departmental portals, intranet news hubs.
- **Team sites** — workspaces for collaborating groups. Backed by Microsoft 365 Groups (and often Teams teams). Used for project work, department workspaces, working files.
A typical hub combines both: a communication-site hub centre plus many team sites associated to it.
## Permissions design
- **Group-driven** — site members come from Microsoft 365 Group membership for team sites.
- **Audience-targeted** — communication sites visible to broader audiences with restricted edit rights.
- **Sensitivity labels** at the container level set sharing posture per site.
- **Avoid item-level permissions** — they create audit nightmares.
## Common pitfalls
- **Over-engineering early** — designing for 1,000 sites when you have 5. Start simple, evolve.
- **Building a tree of subsites** — modern SharePoint doesn't reward this. Use flat hub structures.
- **Inconsistent naming** — `HR Department`, `Human Resources`, and `HR Team` all referring to the same thing.
- **No ownership** — sites need accountable owners; orphaned sites accumulate.
- **Skipping global navigation** — users get lost without it.
## Migration considerations
When migrating from legacy SharePoint or file shares:
- **Don't replicate folder structure 1:1** — flatten and use metadata where possible.
- **Identify natural site boundaries** — usually department-aligned.
- **Plan navigation up front** — restructuring later is painful.
- **Communicate the new structure** before, during, and after migration.
For an organisation building or rebuilding its Microsoft 365 intranet, IA design is the most consequential decision. Spend time on it; document it; revisit annually.
## A worked example: a 400-user professional services firm
A 400-user consultancy on Microsoft 365 E3, historically all "Everyone except external users" on the tenant root site with permissions granted per folder. Post-cleanup the IA looks like this:
- **Intranet** — one communication site (Comms), author group ~5, everyone reads. No collaboration happens here.
- **Company-wide collaboration** — one hub site (HQ) with spokes: HR, Finance, IT, Legal, Marketing, Operations. Each spoke owned by that function's Microsoft 365 Group.
- **Client work** — one hub (Delivery) with a spoke per active client (typically 40–80 sites). Each spoke is owned by the client's engagement Team. Provisioning is automated: a Power Automate flow triggered from CRM creates the site with a site template that pre-seeds four libraries (Contracts, Deliverables, Working Files, Correspondence), sensitivity labels applied at container level, and access limited to the delivery team.
- **Personal drafting** — OneDrive. As soon as a document goes to a second person it moves to the appropriate SharePoint library.
- **Retention** — a retention label auto-applied to Contracts (7 years from last-modified), Deliverables (10 years from client-offboarded event), everything else on the standard 3-year rolling policy.
The unglamorous work: renaming and remapping ~200 old sites into the new IA, mostly by cloning documents into their new home rather than migrating in place — anything that broke on the way over stayed broken.
## Decision matrix: hub, spoke, or standalone
| Situation | Structure |
| --- | --- |
| One organisation-wide news feed everyone reads | **Hub** with **communication-site** homepage; every other site associates to it |
| A department or function that collaborates internally and publishes some content out | **Spoke team site** associated to the HQ hub |
| A cross-functional programme spanning many departments | **New hub** (Programme hub) with the participating team sites associated to it |
| A single-purpose short-lived team (a project, a bid, a task force) | **Team site** provisioned from a template, no hub required |
| Confidential board or M&A material | **Standalone team site** with restricted membership, sensitivity-label container control, no hub association |
| Personal working files | **OneDrive** — until they leave that user's control |
## When to stop redesigning
- **You have three or fewer working hubs.** Do not add a fourth hub because the org chart grew a new column. Hubs work when they represent enduring content domains, not project-based groupings.
- **Users are creating standalone sites.** This is a symptom of provisioning friction — fix the provisioning flow (self-service through a governed template) before adding another layer of IA.
- **Search returns the right result on the first try for 80% of queries.** IA changes have diminishing returns; invest the next hour in labels, templates, and search promotions instead.
- **You cannot describe the IA in three sentences.** Neither can anyone else, which means it will not survive the next reorg.
## MSP checklist
- **Standard template per client size band.** SMB clients get one hub + spokes-by-department; mid-market gets internal hub + delivery hub + confidential-standalone pattern.
- **Provisioning is code, not clicks.** Site templates + a Power Automate or Graph API–driven provisioning flow, source-controlled. Manual site creation is the operational anti-pattern that grows into next year's cleanup project.
- **Hub-association reports.** Monthly per-client report of sites not associated to any hub (with reason: standalone by design, or drift). Drift gets a follow-up.
- **Sensitivity-label baseline** applied at container creation, not left to users. Public / General / Confidential / Highly Confidential is the working default across small clients.
- **External-sharing posture** documented per site classification. Standalone confidential = organisation-only; standard client site = new-and-existing guests with expiration.
## Frequently asked questions
**What is SharePoint information architecture?**
The design of sites, hubs, navigation, metadata, and content types so people can find things: which sites exist and why, how they are grouped under hubs, what the global navigation shows, and which metadata columns and content types libraries use.
**Should we use one big site or many small sites?**
Many small sites, one per team, project, or topic, grouped under hubs. A site is the unit of permissions, retention, and lifecycle; giant sites with subsites and broken inheritance are the legacy pattern Microsoft moved away from with the flat, hub-based model.
**What are hub sites for?**
Associating related sites so they share navigation, branding, and search scope without changing permissions — a department hub with its project sites, for example. A site can belong to one hub; hubs can be nested one level.
---
# SharePoint large list handling
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-large-list-handling
Category: SharePoint & OneDrive
Published: 2026-05-01
> How to work with SharePoint lists that exceed the default 5,000-item threshold — indexing, views, and architecture.
SharePoint lists have a famous **5,000-item view threshold** — list views that would return more than 5,000 items fail with a throttling error. For lists growing past that threshold (common in real-world scenarios), specific techniques unlock continued usability without throwing errors.
Large lists are a library-design problem covered in [document libraries deep dive](/guides/sharepoint-document-libraries-deep-dive) and [information architecture](/guides/sharepoint-information-architecture); the sync limits are in [OneDrive sync client deep dive](/guides/onedrive-sync-client-deep-dive), and for list-shaped data the alternatives are [Microsoft Lists](/guides/sharepoint-lists-vs-microsoft-lists) or [Dataverse](/guides/dataverse-explained).
## What the threshold actually means
The threshold is **per view**, not per list:
- A list can have **30 million items** — that's the actual list limit.
- Individual **views** can return up to 5,000 items by default.
- Beyond that, the view is throttled — error to the user.
So a 50,000-item list is fine; viewing all 50,000 in one view isn't.
## Indexed columns
The most important tool: **indexed columns**. When a column is indexed:
- Filters and sorts on that column become fast — even on huge lists.
- Views that filter by indexed columns can return up to 20,000 items.
- The list can be queried efficiently via REST / Graph.
Add indexes via **List Settings → Indexed columns**. Up to 20 single-column indexes per list, plus compound indexes.
Index the columns you filter / sort by:
- **Status** — filter to "Active" only.
- **Department** — filter by department.
- **Modified date** — filter to recent items.
- **Person columns** — filter by assignee.
For large lists, indexing isn't optional — it's how you make them usable.
## View design
For lists exceeding the threshold:
- **Filter views aggressively** — return small subsets, not "all items."
- **Sort by indexed columns** — sorting on unindexed columns triggers throttling.
- **Limit columns shown** — fewer columns = less work per row.
- **Item limit** — explicitly set the page size (50, 100, 200 items).
Default views shipped with SharePoint often don't follow these patterns; create your own.
## Compound indexes
For queries with multiple filters, **compound indexes** (multi-column) speed them up:
- Compound index on **Status + Modified Date** — fast for "active items modified this month."
- Compound index on **Department + Status** — fast for "my department's active items."
Compound indexes are more powerful than two separate single-column indexes for the specific combination they cover.
## Folders for partitioning
For lists exceeding the threshold, **folders** partition content:
- Folder per region, department, year, etc.
- Each folder contains under 5,000 items.
- Views can navigate to specific folders.
Folder structure has UX costs (users navigating folders); modern SharePoint discourages deep folders. But for very large lists, folder-based partitioning is sometimes the right pragmatic answer.
## Power Automate large-list handling
When Power Automate flows query large SharePoint lists:
- **Use OData filters** matching indexed columns.
- **Page through results** with `$top` and `$skiptoken`.
- **Avoid Apply to each over huge sets** — refactor to bulk operations where possible.
- **Use delta queries** when only changes matter.
Without these patterns, flows on large lists fail with throttling.
## When to graduate to Dataverse
Past a certain scale, SharePoint lists aren't the right answer:
- **Millions of items** at scale — Dataverse handles this gracefully; SharePoint struggles.
- **Relational integrity** required — SharePoint lookups are limited.
- **Transactional semantics** — multi-table updates with atomicity.
- **Row-level security** beyond what SharePoint can provide.
- **Heavy concurrency** — many simultaneous editors.
For these, Dataverse is the right destination. Power Apps and Power Automate work seamlessly on either; the data layer is the difference.
## Operational considerations
- **Monitor list size** — track approach to 5,000, 20,000, 30,000 thresholds.
- **Plan indexes before hitting limits** — adding indexes to already-throttled lists is harder than preventing.
- **Test views during development** — verify they work past expected scale.
- **Communicate to users** — train them not to "show all items" on large lists.
- **Periodic data archival** — old items that can be moved out keep active lists fast.
For SharePoint-using teams whose lists are growing, knowing these patterns lets you keep working in SharePoint past the points many think require migration. The 5,000-item threshold is a constraint, not a hard limit on usability.
---
# SharePoint list and column formatting (JSON)
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-list-formatting
Category: SharePoint & OneDrive
Published: 2026-05-01
> How JSON-based formatting customises SharePoint list views without code — what's possible and where to start.
SharePoint lists support **JSON-based column and view formatting** that customises how data displays without any custom code. It's one of the highest-leverage features in modern SharePoint — give users dramatically better-looking lists with a few lines of JSON.
Formatting applies to the lists in [SharePoint Lists vs Microsoft Lists](/guides/sharepoint-lists-vs-microsoft-lists) and the [Lists templates](/guides/microsoft-lists-templates); when JSON is not enough, [Power Apps](/guides/what-is-power-apps) customises forms and [SPFx](/guides/sharepoint-framework-spfx-overview) builds full components. Large lists need the care in [large list handling](/guides/sharepoint-large-list-handling).
## What you can format
- **Column formatting** — control the rendering of a specific column's values. Add icons, conditional colours, progress bars, action buttons, embedded links, formatted dates.
- **View formatting** — control the rendering of an entire row or tile in a list view. Headers, footers, group headers can be styled.
- **Tile views** — custom card-based layouts for galleries.
The same engine works in Microsoft Lists, SharePoint document libraries, and list views embedded in Teams tabs.
## How it works
You write a JSON object that describes the rendering. The JSON references the field's value via `@currentField`, the row's other columns via `[$ColumnName]`, the current user via `@me`, and various contextual values. Conditional logic uses `=if(...)` expressions or the newer Excel-style `=switch()` and other helpers.
A simple example — colour-code a Status column:
```json
{
"$schema": "https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json",
"elmType": "div",
"style": {
"background-color": "=if(@currentField == 'Done', '#dff6dd', if(@currentField == 'In Progress', '#fff4ce', '#fde7e9'))",
"padding": "4px 8px",
"border-radius": "4px"
},
"txtContent": "@currentField"
}
```
This turns a plain-text "Done / In Progress / Blocked" column into a coloured badge.
## Common patterns
- **Icons next to text** — a small icon plus the value to draw the eye.
- **Progress bars** — for percent-complete columns.
- **Conditional colours** — red / yellow / green by status or due date.
- **Person avatars and details** — for person-or-group columns.
- **Action buttons** — clicking opens a Power Apps form, runs a Power Automate flow, or opens a link.
- **Multi-line layouts** — combine multiple columns into a single card.
## Getting started
The fastest path:
1. Browse the **Microsoft 365 PnP Column-Formatting Samples** repository on GitHub — hundreds of ready-to-use formatters.
2. Copy a sample close to what you want.
3. Adapt the column names and conditions.
4. Apply via Column settings → Format this column → Advanced mode.
You don't need to write JSON from scratch unless you're doing something specific. Sample libraries cover the common cases.
## When not to use formatting
- **Complex business logic** belongs in a Power App, not a list formatter.
- **Cross-list relationships** — formatting can only see the current row's data.
- **Performance-critical scenarios** with huge lists — heavy formatting can slow rendering.
For administrators and citizen developers, list formatting is the closest thing to "customise SharePoint without code" that produces good-looking results. Invest a few hours in it; the payoff is dozens of polished lists across the tenant.
---
# SharePoint Lists vs Microsoft Lists
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-lists-vs-microsoft-lists
Category: SharePoint & OneDrive
Published: 2026-05-01
> SharePoint lists, Microsoft Lists, Dataverse, Excel — picking the right place for structured data.
Microsoft offers half a dozen places to put structured data, and the choice has real consequences. The first decision is usually between **SharePoint lists**, **Microsoft Lists**, **Dataverse**, and a humble **Excel file**.
Lists are the light end of a spectrum that runs through [Lists templates](/guides/microsoft-lists-templates), [list formatting](/guides/sharepoint-list-formatting), [Power Apps](/guides/what-is-power-apps), and [Dataverse](/guides/dataverse-explained); keep the [large list threshold](/guides/sharepoint-large-list-handling) in mind before a list becomes a database.
## SharePoint lists
A **SharePoint list** is a structured list that lives inside a SharePoint site. It has columns (text, number, choice, date, person, lookup, taxonomy), views, formulas, and permissions tied to the site. SharePoint lists have existed since SharePoint 2001 and are the foundation of many internal apps.
## Microsoft Lists
**Microsoft Lists** is a newer, friendlier surface on top of the same SharePoint lists engine. It's a separate app (`lists.microsoft.com`, Teams tab, mobile app) that focuses the experience on the list itself: templates, ready-made designs, conditional formatting, calendar view, gallery view. Lists you create in Microsoft Lists are still SharePoint lists — they just live in a specific site (usually your personal one) and benefit from the better UI.
## When SharePoint lists are the right call
- Up to ~5,000 items per view (with indexing, up to the 30-million-item list limit).
- Data is naturally tied to a site or team.
- No transactional or relational requirements.
- Users will edit through the SharePoint or Microsoft Lists UI.
Typical fit: project trackers, inventory, request logs, asset registers, contact lists.
## When you should pick Dataverse instead
Dataverse is Microsoft's relational database in the Power Platform. Reach for it when:
- You need real relational tables and referential integrity.
- You need row-level security and field-level security.
- You're building a serious model-driven Power App.
- You're storing data that drives Dynamics 365 or Copilot agents.
- Volumes or concurrency are beyond SharePoint's comfort zone.
Dataverse costs more (it requires premium Power Apps or Dynamics licensing), but it's a database. SharePoint lists are documents that happen to look like a database.
## When Excel is fine
For ad-hoc data that one person owns, an Excel file in OneDrive co-authored by a small team often beats either option. It's faster to set up and easier to share. Reach for a list once you need permissions, views, automation triggers, or many editors.
## The migration path
Start in Excel, graduate to a Microsoft List when you need shared views and permissions, graduate to Dataverse when you need a database. Skipping straight to Dataverse for "future flexibility" usually slows you down.
| | Excel | Microsoft Lists / SharePoint lists | Dataverse |
| --- | --- | --- | --- |
| Setup effort | Minutes | Minutes to hours | Hours to days |
| Relational integrity | None | Weak (lookups only) | Full |
| Row-level security | No | Site/list permissions only | Yes, granular |
| Practical scale | One owner, small team | Up to ~5,000 items per view | Millions of rows |
| Extra licensing cost | None | None (included) | Power Apps premium |
| Best fit | Ad-hoc, single-owner data | Trackers, registers, request logs | Line-of-business apps, Dynamics-linked data |
## Frequently asked questions
**Can a Microsoft List be converted into a Dataverse table later without losing data?** There's no one-click migration — moving from a list to Dataverse means recreating the schema as Dataverse tables and importing the data, typically via Power Query or a one-time flow; it's a deliberate migration project, not a setting to flip, which is exactly why starting in Dataverse only when the requirements genuinely call for it (rather than defaulting to it "just in case") avoids unnecessary migration work in either direction.
**Why does a list stop returning results reliably once it grows large?** SharePoint's list view threshold (5,000 items per unindexed view or query) is a database-level protection, not a soft warning — a view that isn't filtered by an indexed column simply fails to return results past that point rather than slowing down gradually. Adding an indexed column on whatever field is filtered most often, or moving to Dataverse for data that was always going to outgrow list scale, are the two real fixes.
---
# SharePoint Migration Tool deep dive
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-migration-tool-deep-dive
Category: SharePoint & OneDrive
Published: 2026-05-01
> How to use the SharePoint Migration Tool and Migration Manager for large-scale migrations to SharePoint Online.
The **SharePoint Migration Tool (SPMT)** and **Migration Manager** are Microsoft's free first-party tools for migrating content from on-premises SharePoint, file shares, and other clouds into SharePoint Online and OneDrive. For larger migrations, knowing how to drive them well — and where their limits are — matters.
The tool serves the playbooks in [migrating from file shares](/guides/sharepoint-migration-from-file-shares) and [migrating file shares to OneDrive and SharePoint](/guides/migrating-file-shares-to-onedrive-and-sharepoint); design the target with [information architecture](/guides/sharepoint-information-architecture) first, and read [large list handling](/guides/sharepoint-large-list-handling) before migrating a 400,000-item share.
## SPMT vs Migration Manager
Two related tools:
- **SharePoint Migration Tool (SPMT)** — a Windows desktop client you run on a machine with access to the source content. Best for one-off migrations or jobs from a single source.
- **Migration Manager** — a web-based orchestrator in the SharePoint admin center that drives **multiple SPMT agents** across distributed source environments. Best for large-scale, multi-source projects.
Same underlying engine; Migration Manager adds the orchestration and reporting layer.
## What can migrate
- **Windows file shares** — UNC paths, mapped drives, on-prem shared folders.
- **On-premises SharePoint** — SharePoint 2010 / 2013 / 2016 / 2019 / Subscription Edition site collections.
- **Google Drive** — including Shared Drives via the Migration Manager Google integration.
- **Box** — via Migration Manager.
- **Dropbox** — via Migration Manager.
Each source has its own pre-migration considerations.
## Preparation
The success of a migration depends mostly on preparation, not on running the tool. Pre-migration tasks:
### Inventory and triage
Walk the source and identify:
- **Total volume** (GB and file count).
- **Owners** for each share / site.
- **Stale content** that shouldn't migrate.
- **Files with invalid characters** or paths too long for SharePoint.
- **Permissions complexity** — NTFS ACLs map imperfectly to SharePoint permissions.
A common finding: 30–60% of source content hasn't been accessed in years. Migrate selectively.
### Target design
Design where each source goes:
- **Personal H: drives → user OneDrives**.
- **Department shares → department SharePoint team sites**.
- **Project shares → Teams teams**.
- **Reference content → communication sites**.
Resist replicating folder structure 1:1. Flatten and use metadata.
### Pre-create destinations
Create the target sites, libraries, and permissions before migration. The tool moves content into existing locations more cleanly than provisioning on the fly.
## Running the migration
A typical wave:
1. **Run a scan** first to identify migration issues without moving content.
2. **Review the scan report** — fix file names, shorten paths, remove unsupported content.
3. **Run a pilot migration** of one share to validate process and timing.
4. **Schedule the bulk migration** during a maintenance window or off-hours.
5. **Run an incremental delta** after the bulk to catch any newly modified files.
6. **Cutover** — make the source read-only, run a final delta.
7. **Validate** — spot-check files post-migration.
8. **Decommission** the source after a stabilisation period (30 days typically).
## Migration Manager features
For larger migrations, Migration Manager adds:
- **Multi-agent orchestration** — SPMT agents on multiple source machines for parallelism.
- **Web-based reporting** — task status, throughput, errors, success rate.
- **Bandwidth control** — limit migration impact on the source network.
- **Scheduling** — run migrations during specific windows.
- **Migration assessments** — built-in scanning for issues before migration.
## Performance
Realistic throughput depends on many factors:
- **Bandwidth between source and Microsoft cloud** — usually the bottleneck.
- **File sizes** — many small files migrate slower per GB than few large files.
- **Source filesystem performance** — slow source storage slows the whole operation.
- **Microsoft cloud throttling** — Microsoft rate-limits ingestion; small bursts are fine, sustained heavy load gets throttled.
Plan for hundreds of GB to single-digit TB per day per source machine in typical scenarios.
## Third-party alternatives
For migrations Microsoft's free tooling can't handle well — complex permission preservation, multi-system source heterogeneity, custom logic — third-party tools (ShareGate, AvePoint Fly, Quest Migration Manager, BitTitan) offer richer features at a price.
For most file-share-to-SharePoint and SharePoint-on-prem-to-SharePoint Online migrations, SPMT and Migration Manager are sufficient. For complex hybrid SharePoint scenarios or large M&A migrations, third-party tools usually win on ROI.
## After migration
- **User onboarding** — show users where their content is now.
- **Roll out OneDrive Known Folder Move** if not already done.
- **Decommission the old source** — leaving it accessible delays the cultural transition.
- **Capture lessons** for the next wave.
A successful migration replaces "where are the files?" with "the files are in the obvious place." That's the goal — not just moving bytes from A to B.
---
# SharePoint multilingual sites
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-multilingual-sites
Category: SharePoint & OneDrive
Published: 2026-05-01
> How to design SharePoint sites that serve multiple languages — translation, navigation, and authoring patterns.
For multinational organisations, an intranet that works in English only — when 40% of employees don't have English as a first language — is a problem. **SharePoint multilingual sites** let you deliver content in multiple languages with one underlying site and per-language pages.
Multilingual sites are part of the [multi-language tenant setup](/guides/multi-language-tenant-setup) story and apply to the [communication sites](/guides/sharepoint-communication-sites) and [pages](/guides/sharepoint-page-design-and-web-parts) of an intranet; for global organisations they often pair with [Multi-Geo](/guides/microsoft-365-multi-geo).
## How multilingual works in modern SharePoint
A multilingual SharePoint site has:
- **A default language** — the primary site language.
- **Alternative languages** — additional languages enabled per site.
- **Per-page translations** — each page can have a translation in each alternative language.
- **Per-language navigation** — top navigation items translated.
- **Per-language site display** — users see the site in their preferred language based on browser settings or explicit selection.
Configured per site in **Settings → Site information → Language settings**. Once enabled, page authors can create translations of any page; users automatically see the right one.
## Workflow for content authors
A typical authoring flow:
1. **Author creates a page** in the default language (e.g., English).
2. From the page settings, **request translation** — creates draft pages in the enabled alternative languages.
3. **Translator (or AI translator) translates the draft**.
4. **Publish each language version** — they go live independently.
5. **Update navigation** — translated nav items map to the right language's pages.
For tenants with **Microsoft Translator integration**, AI-translated drafts can be a starting point — translator reviews and refines rather than translating from scratch.
## What's translated vs not
Translation happens at the **page level** — the page's title, content, and metadata. **Library and list content** (the actual documents and items stored in SharePoint) is **not auto-translated** by SharePoint — they exist in whatever language they were authored in.
For files stored in libraries, options include:
- **Separate libraries per language** — `Documents (EN)`, `Documents (FR)`, etc.
- **Single library with language metadata** — each file tagged with its language; views filter accordingly.
- **External translation services** for documents that need to be available in multiple languages.
## Hub and global navigation
For hub sites, **hub navigation translations** are configured at the hub level — users associated to the hub see hub nav in their language. The same applies to **home site navigation** at the global level.
This means a multinational intranet with localised hubs delivers a coherent experience to users regardless of language.
## Limitations and operational considerations
- **Not all SharePoint features are fully multilingual** — some settings, certain admin surfaces, web part configurations have English-only UIs even on translated sites.
- **Performance** — sites with many languages and many pages produce many page artefacts; not usually a problem but worth knowing.
- **Authoring discipline** — translations get out of sync if authors update one language without the others.
- **Cultural considerations** — translation isn't just literal; some content needs localisation (legal disclaimers, examples, imagery).
## When to invest
Multilingual SharePoint is most valuable for:
- **Multinational organisations** with significant non-English-first-language populations.
- **Public-sector and regulated industries** with legal multilingual requirements.
- **Customer-facing intranet portions** where the audience expects native language.
For organisations where English is the universal corporate language and all employees speak it fluently, monolingual SharePoint is simpler and equivalent in utility.
When you do invest, plan the **translation operating model** alongside the technical setup. Who translates? On what cadence? What's the quality bar? Without those answers, multilingual capability becomes shelf-ware.
---
# SharePoint page design and web parts
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-page-design-and-web-parts
Category: SharePoint & OneDrive
Published: 2026-05-01
> Modern SharePoint pages are built from web parts. Here's the kit and how to compose a good page.
Modern SharePoint pages are assembled in the browser from a library of **web parts**. The classic SharePoint Designer / publishing model is gone for new sites; pages are now blocks of structured content arranged in sections, designed to look right on any device.
Pages live on the sites described in [team sites vs communication sites](/guides/sharepoint-team-sites-vs-communication-sites) and [communication sites deep dive](/guides/sharepoint-communication-sites); multilingual pages are in [multilingual sites](/guides/sharepoint-multilingual-sites), custom web parts in the [SPFx overview](/guides/sharepoint-framework-spfx-overview), and video embedding in [Stream on SharePoint](/guides/microsoft-stream-on-sharepoint).
## The page model
A page is a stack of **sections**. Each section has a column layout (one to three columns, plus full-width). Sections contain **web parts** — pre-built building blocks that pull in content of various kinds.
## The web parts most pages use
- **Text** — rich text with headings, lists, links.
- **Image** — single image with alt text, captions, and basic styling.
- **Hero** — large image/news tile cluster, ideal for a landing page.
- **Quick links** — a grid of links with icons, used heavily on intranets.
- **News** — pulls in news posts from this site, the hub, or selected sites.
- **People** — a profile card grid.
- **File and media** — embed a document or video viewer.
- **Highlighted content** — query-driven roll-up of files or pages matching filters.
- **Embed** — paste any embeddable URL (YouTube, Power BI, Forms, Stream).
- **Code snippet** — for documentation pages.
Beyond these, the marketplace and custom SPFx (SharePoint Framework) web parts extend further.
## Sections, columns, and layouts
A typical landing page layout:
1. Full-width **hero** section with site navigation and a call to action.
2. Two-column section with a **news** roll-up beside **quick links**.
3. Full-width **events** or **embed** section (calendar or Power BI dashboard).
4. Three-column **people** or **link** grid.
5. A footer with contacts and important documents.
Use **section backgrounds** to break up the page visually; use **vertical sections** for sidebars that float on the right.
## News, pages, and articles
A **news post** is a page with the "News" template — it appears in the site's News rollup and the hub's news feed. A regular **page** doesn't. Both have the same authoring experience. **News digest** lets a site owner email a curated roundup of news.
## Brand and theming
A communication site can be themed at the site level (colours, fonts) and inherits from a hub if associated. Tenant-wide **branding** (logo, app launcher header, browser tab favicon) lives in the Microsoft 365 admin center.
Keep pages simple. The hard part isn't picking web parts — it's keeping content fresh enough to be worth reading.
## Web parts and Copilot grounding
Not every web part contributes equally to what Copilot can retrieve from a page. **Text, Hero, and News** web parts store genuinely extractable text that Copilot can ground answers on; **Embed** web parts (an iframe to an external service) and heavily image-based layouts contribute far less, since there's no underlying text for the index to crawl — a beautifully designed page built mostly from embeds and hero images can look complete to a human visitor while being close to invisible to Copilot's retrieval. For pages meant to answer real employee questions (an IT help page, an HR policy page), leaning on Text and structured content rather than image-heavy or embed-heavy layouts pays off doubly — better for search, and better for any AI-assisted retrieval built on top of it.
## Frequently asked questions
**Can a page be scheduled to publish at a future date, like a news article?** Yes — modern SharePoint pages support scheduled publishing, letting an author finish a page ahead of time and have it go live (and appear in News rollups, if applicable) automatically at a specified date and time rather than needing someone to manually publish it at the right moment.
**Do web parts work the same way across desktop and mobile?** Most do, with layouts reflowing responsively — a three-column section collapses to a single column on a phone, for instance — but a handful of web parts (some third-party SPFx parts in particular) render poorly or are hidden entirely on mobile if they weren't built with responsive behaviour in mind, which is worth checking specifically for any custom or less common web part before relying on it for content mobile users need to see.
---
# SharePoint search and crawl architecture
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-search-and-crawl
Category: SharePoint & OneDrive
Published: 2026-05-01
> How SharePoint indexes content, what affects search quality, and how to influence ranking.
SharePoint's search experience — under **Microsoft Search** as the user-facing surface — depends on a continuously-updated index of tenant content. Understanding what gets indexed, how often, and how ranking works helps both with troubleshooting "I can't find that file" and with deliberate improvement of search quality.
The overview and the admin levers are in [SharePoint search and Microsoft Search](/guides/sharepoint-search-and-microsoft-search) and [Microsoft Search administration](/guides/microsoft-search-administration); if the question is why Copilot finds something search does not, read [Copilot grounding vs SharePoint search](/guides/copilot-grounding-vs-sharepoint-search).
## What gets indexed
The SharePoint search index covers:
- **Files** in SharePoint and OneDrive libraries — full text for supported file types (Word, Excel, PowerPoint, PDF, plain text, HTML, and many more).
- **List items** — text columns, choice columns, custom columns.
- **Pages** — modern and classic SharePoint pages.
- **Site metadata** — site title, description, owner.
- **People** — profile fields from Entra ID.
- **External content** — third-party data via **Microsoft Graph connectors**.
Each indexed item carries its **permissions** so search results are trimmed per user — users see only what they're authorised to access.
## Crawl behaviour
SharePoint Online's search is **continuous crawl** — content is indexed as it changes, typically within minutes for most changes. No admin crawl schedules to configure. Specific events that trigger indexing:
- File created, modified, or moved.
- List item created or modified.
- Page published.
- Site created.
- Permissions changed.
- Sensitivity label applied.
Initial indexing of a new site or large content upload can take longer — Microsoft prioritises across the global service, so peak times have longer indexing latency.
## Why search results are sometimes stale
When users report "I uploaded this file yesterday and search can't find it," common causes:
- **Recent upload** — give it a few minutes / hours.
- **Indexing pause** for very-large bulk operations — Microsoft sometimes pauses to keep service health.
- **Tenant just resumed from preservation hold** — re-indexing in progress.
- **Permissions just changed** — search may show old permissions briefly.
- **Content too short to index** — extremely small documents may not surface.
- **Unsupported file type** — some specialised formats don't index full-text.
For investigation, the **search admin centre** shows tenant-wide search health.
## Ranking signals
Search results are ranked by:
- **Relevance to query** — keyword match, semantic similarity.
- **Recency** — recent content ranks higher (with decay).
- **Popularity** — frequently-clicked items rank higher.
- **Personal signals** — content the user has interacted with ranks higher for that user.
- **People graph** — content from people you work with ranks higher.
- **Promoted results** — admin-configured bookmarks always appear at top.
The personal-signals layer means **two users see different results** for the same query — relevance depends on each user's work context.
## Influencing search quality
Admin actions that improve search results:
### Bookmarks and answers
For known frequent queries, configure **bookmarks** in the Search admin centre. "VPN" returns the VPN setup page; "expense report" returns the expense system. Avoids users sifting through irrelevant results.
### Acronyms
For organisation-specific acronyms, define them. "ARR" → "Annual Recurring Revenue."
### Custom verticals
For specialised content, define **search verticals** that filter results to specific content types — files, pages, people, ServiceNow tickets, etc.
### Promoted content
Mark specific sites as **featured** — they appear prominently in the user's organisation home and in relevant searches.
### Microsoft Graph connectors
Index external content alongside SharePoint — Jira tickets, ServiceNow records, GitHub repos, file shares — for unified search across all enterprise data.
### Content quality
- **Descriptive titles** on pages and files surface better than `Document 1`.
- **Useful descriptions** in site and library properties.
- **Sensitivity labels** correctly applied — users can find content by label.
- **Up-to-date content** — stale content with old dates ranks lower than current.
## Operational considerations
- **Search analytics** in the Search admin centre show top queries, zero-click queries (no result clicked), trending content.
- **Use top-zero-click queries** as candidates for new bookmarks.
- **Quarterly review** — search admin practice as ongoing operation.
- **User feedback** — provide a feedback channel for "I couldn't find X" reports.
For Microsoft 365 customers with significant content volume, deliberate search administration is one of the higher-leverage admin investments. The search box gets used many times a day across the tenant; small improvements compound.
---
# SharePoint search and Microsoft Search
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-search-and-microsoft-search
Category: SharePoint & OneDrive
Published: 2026-05-01
> How search works in Microsoft 365 — what gets indexed, what users see, and how to make results better.
Search in Microsoft 365 went from "SharePoint Search" to "Microsoft Search" around 2019. The underlying index is shared across SharePoint, OneDrive, Teams, Outlook, and Bing-at-work, and the user-facing surface is the same search box across the apps. Knowing how it works helps both users and admins.
The crawl mechanics and staleness troubleshooting are in [SharePoint search and crawl architecture](/guides/sharepoint-search-and-crawl); tenant-level administration is in [Microsoft Search administration](/guides/microsoft-search-administration), and the difference between search and Copilot retrieval is the subject of [Copilot grounding vs SharePoint search](/guides/copilot-grounding-vs-sharepoint-search).
## What's indexed
Microsoft Search indexes:
- **SharePoint sites and pages** — content, metadata, columns.
- **Files** in SharePoint and OneDrive — including full-text content for supported file types.
- **Teams messages** and channel content.
- **Outlook** mailboxes (a user's own mail, primarily).
- **People** — names, titles, departments, skills, hierarchy from Entra ID.
- **Conversations and Loop components**.
- Optional **third-party connectors** — Jira, ServiceNow, GitHub, file shares, and more — via Microsoft Graph connectors.
Each user's search results are **personalised** and **trimmed to their permissions**: you only see what you can already access.
## Where users search
- **The search box at the top of Microsoft 365 apps** (SharePoint, Teams, Outlook, Office apps, Bing-at-work).
- The **SharePoint search results page** for a site or hub.
- The **Microsoft Search browser address bar** (`bing.com` signed in with a work account).
Results are unified — files, messages, and people show up in one list, with verticals for files, people, sites, etc.
## How admins influence results
Admins control search through the **Search & Intelligence admin centre** (`admin.microsoft.com/search`):
- **Answers**: predefined answers for known questions (e.g. "VPN" surfaces the VPN page).
- **Bookmarks**, **Q&A**, and **acronyms**.
- **Locations**: known office addresses.
- **Promoted results** and **verticals**.
For larger or external sources, **Graph connectors** bring third-party content into the index.
## Improving result quality
A few practical levers:
- **Title and description** metadata on SharePoint pages matter — they're what shows in results.
- **Sensitivity labels** and **retention** ensure old, stale content isn't promoted forever.
- **Site hub associations** define **search scopes**: a search from a hub searches across all associated sites.
- **Search analytics** show what users searched for and which results they clicked — use this to seed bookmarks and answers.
For Copilot tenants, search quality directly affects Copilot quality. Stale, mis-titled, or mis-permissioned content shows up in answers.
## Search vs Copilot retrieval — a common confusion
Microsoft Search and Copilot's retrieval both draw on the same underlying index and both respect the same per-user permission trimming, which leads many admins to assume "if it's in search, it's Copilot-ready" — that's not quite right. Search surfaces a ranked list of documents for a user to open and read themselves; Copilot additionally has to **extract and synthesise** content from what it retrieves, which means a technically-indexed but badly-structured document (no headings, ambiguous filenames, content buried in an image or scanned PDF) can show up perfectly well as a search result while contributing little or nothing useful to a Copilot-generated answer. Improving search ranking and improving Copilot answer quality are related but not identical exercises — fixing titles and descriptions helps both; fixing document *structure* (real headings, extractable text rather than scanned images) matters specifically for the Copilot half.
## Frequently asked questions
**Why do two users see different results for the same search term?** Results are trimmed to each user's own permissions and further personalised by their own search and interaction history — a manager who regularly opens a specific policy document will tend to see it ranked higher than a colleague who's never opened it, even though both have equal access to it.
**Can search results be forced to exclude a specific site entirely?** Yes — a site can be excluded from the search index (and, separately, from Copilot's grounding) via the SharePoint admin center or, at greater granularity, through SharePoint Advanced Management's restricted access and archive controls, which remove a site from active search and Copilot retrieval without deleting its content.
**How current are search results relative to a document that was just edited?** Typically minutes, not hours — the crawler picks up changes on a short cycle for most content types, though very large libraries or unusual file types can lag longer; a document that seems to be missing from search immediately after being saved is more often a permissions or file-type issue than a crawl-delay one.
---
# SharePoint and Microsoft Syntex content processing
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-syntex-content-processing
Category: SharePoint & OneDrive
Published: 2026-05-01
> How Microsoft Syntex automates document classification, metadata extraction, and content processing at scale.
**Microsoft Syntex** (formerly SharePoint Syntex, now also marketed as SharePoint Premium) adds AI-driven **content processing** to SharePoint Online — automatically classifying documents, extracting structured metadata, generating documents from templates, performing eSignature, and applying retention / sensitivity at scale. For organisations with high-volume document workflows, Syntex is one of the higher-impact Microsoft 365 capabilities of the past several years.
This is the SharePoint-side view of [Microsoft Syntex](/guides/microsoft-syntex-deep-dive); the extracted metadata feeds [document libraries](/guides/sharepoint-document-libraries-deep-dive) and [information architecture](/guides/sharepoint-information-architecture), and the Power Platform alternative is [AI Builder document processing](/guides/ai-builder-document-processing).
## Document understanding
The core capability: train an **AI model** to classify documents and extract specific fields from them. When new documents arrive at a SharePoint library, Syntex applies the model — categorising each document and extracting field values into SharePoint columns.
Two model types:
### Unstructured document processing
For text-heavy documents where layout varies — contracts, agreements, policies, articles. The model learns from example documents you provide. For each new document:
1. **Classifier** identifies the document type — "this is a contract."
2. **Extractors** pull specific fields — start date, end date, parties, total value, jurisdiction.
The extracted fields land in SharePoint metadata columns. Filtering, searching, and aggregating across documents becomes structured.
### Structured / freeform document processing
For form-style documents where field locations are more consistent — invoices, applications, receipts. Uses **AI Builder form processor** under the hood. Provide 5–10 example documents; train the model; apply to incoming documents.
### Prebuilt models
Microsoft ships ready-to-use models for common document types:
- **Invoices** — vendor, invoice number, date, line items, total.
- **Receipts** — vendor, date, total, line items.
- **Business cards** — name, company, contact details.
- **Contracts** — parties, dates, terms (basic).
Prebuilt models are a fast starting point without training.
## Content assembly
Generate documents from templates and structured data:
- **Word templates** with placeholder fields.
- **Data source** for the placeholder values — Dataverse, SharePoint list, Power Automate input.
- **Output document** generated with values filled in.
Use cases: contract generation from a customer record, proposal generation from product configurations, personalised letters from a customer list. Replaces manual mail-merge or third-party document-automation tools.
## eSignature
Native digital signing in Microsoft 365:
- Request signatures on PDF or Word documents.
- Multiple signers, sequence-controlled.
- Tamper-evident signed documents stored in SharePoint.
- Audit trail of signature events.
Alternative to **DocuSign** or **Adobe Sign** for in-tenant signing workflows. Some organisations use Syntex eSignature for internal use, third-party for customer-facing.
## Content processing flows
For automated handling at scale:
- **Auto-classify documents** as they arrive based on a trained model.
- **Auto-apply sensitivity labels** based on detected content.
- **Auto-apply retention** for specific document categories.
- **Trigger workflows** — Power Automate flows fire when classification happens.
## Image and video processing
Lighter capability but useful:
- **Image tagging** — automatic tags for images uploaded to SharePoint.
- **OCR** on images and PDFs for content searchability.
- **Video transcription** for accessibility and search.
Often consumed at the **pay-as-you-go transaction** level — image processed = transaction.
## Where Syntex fits with Microsoft 365 Copilot
Syntex and Microsoft 365 Copilot are complementary:
- **Syntex makes content machine-understandable** — classification, extraction, structured metadata.
- **Copilot reasons over content** — answers questions, summarises, drafts.
Better Syntex-applied metadata = better Copilot grounding quality. For Copilot-heavy use cases, Syntex investment pays back in answer quality.
## Licensing
Syntex has shifted to a **pay-as-you-go** model:
- **Document understanding** transactions per file.
- **Content assembly** per document generated.
- **eSignature** per signature request.
- **Content processing** per asset.
Some capabilities also have **per-user** licensing for organisations with heavy steady use.
## When Syntex is the right investment
Most valuable for:
- **High-volume document processes** — accounts payable processing thousands of invoices, claims processing.
- **Contract management** with significant document review.
- **Regulatory document classification** at scale.
- **Customer-facing document generation** at volume.
Less valuable for:
- **Low document volumes** — manual processing is fine.
- **One-off document scenarios**.
- **Highly variable document types** that resist consistent classification.
For organisations matching the heavy-volume profile, Syntex often pays back the licensing cost within months in saved manual effort.
---
# SharePoint team sites vs communication sites
URL: https://www.solvingmicrosoft365.com/guides/sharepoint-team-sites-vs-communication-sites
Category: SharePoint & OneDrive
Published: 2026-05-01
> The two main SharePoint site types — what each is for, and how to pick.
SharePoint Online has many site types, but two account for the vast majority of usage: **team sites** and **communication sites**. They're fundamentally the same product — the same web parts, the same APIs — but they're shaped for different jobs.
Site type is the first decision in [SharePoint information architecture](/guides/sharepoint-information-architecture); communication sites are detailed in [communication sites deep dive](/guides/sharepoint-communication-sites), team sites are usually created through Teams per [Groups vs Teams vs SharePoint](/guides/m365-groups-vs-teams-vs-sharepoint), and both are grouped by [hub sites](/guides/sharepoint-hub-sites).
## Team sites
A **team site** is a workspace for a group of people working together — a department, a project, a product. Every Microsoft 365 Group and every Microsoft Teams team is backed by a team site. Team sites assume:
- A relatively small, defined membership.
- High write-to-read ratio — lots of people contributing files and edits.
- Quick links and shared dashboards rather than polished marketing pages.
- Members and Owners groups inherited from the underlying Microsoft 365 Group.
The default home page is utilitarian: news, document library, activity feed, links.
## Communication sites
A **communication site** is for **broadcasting information** to a wider audience — an intranet landing page, an HR portal, a brand hub, a company news site. Communication sites assume:
- A small set of authors writing for a broad audience of readers.
- Low write-to-read ratio.
- Polished page design with hero images and modern layouts.
- Permissions tilted toward read-only for most of the org.
Communication sites are **not connected to a Microsoft 365 Group**, which means no shared mailbox, no team, no Planner. That's fine — they're publishing tools.
## How to choose
| Use case | Site type |
| --- | --- |
| Project workspace, 5–50 people contributing | Team site |
| Department intranet, broadcast to whole company | Communication site |
| Teams channel (auto-created) | Team site |
| Company news hub | Communication site |
| Manager toolkit, edited by HR, read by managers | Communication site |
| Customer-facing site | Neither — use Power Pages or another platform |
## Hub sites
Both can be associated with a **hub site**, which provides shared navigation, theme, and search across many sites. Most modern intranets use one or more hub sites with a communication site at the centre and dozens of team and communication sites associated to it.
A practical rule: if you find yourself adding a "site visitors" group to a team site so half the company can read it, you probably want a communication site instead. Trying to make a team site behave like a publishing site means fighting the product the whole way.
## Why the Microsoft 365 Group attachment is the real dividing line
The single most consequential technical difference isn't the page design templates — it's that a team site is **backed by a Microsoft 365 Group** and a communication site (by default) is not. That attachment is what brings a shared mailbox, a Planner plan, group-based membership management, and (if applicable) a Teams team along for free — and it's also what ties the site's lifecycle to the group's own lifecycle policies (expiration, naming conventions, access reviews). A communication site, lacking that attachment, needs its own separate site-collection administration and permissions management from day one, which is more manual work but also avoids inheriting group sprawl for content that was never meant to be a "team" in the collaborative sense at all.
## Frequently asked questions
**Can a communication site be converted into a team site later, or vice versa?** No — the underlying architecture (Microsoft 365 Group-backed or not) is set at creation and isn't a supported in-place conversion; migrating content from one site type to the other means creating a new site of the target type and moving the content across, which is worth planning for up front rather than guessing wrong and needing to redo it.
**Do communication sites support the same web parts and page design as team sites?** Yes — both site types share the identical modern page and web-part engine described elsewhere; the difference is entirely about audience, permissions model, and Microsoft 365 Group attachment, not about what content or layout capabilities are available on the page itself.
---
# Teams app development for Microsoft 365 Copilot
URL: https://www.solvingmicrosoft365.com/guides/teams-app-development-for-copilot
Category: Microsoft 365 Copilot
Published: 2026-05-01
> How to build Teams apps that extend Microsoft 365 Copilot — the unified app model, message extensions, and agent extensions.
Microsoft has converged the Teams app model with the Microsoft 365 Copilot extension model. A single app manifest can deploy to Teams, Outlook, Microsoft 365 Copilot, and the broader Microsoft 365 web surface. For developers building line-of-business extensions, this **unified app model** is the strategic direction.
Apps are surfaced through [Teams apps and tabs](/guides/microsoft-teams-apps-and-tabs) under [app permission policies](/guides/teams-app-permission-policies); Copilot extension options are compared in [extensions and plugins](/guides/microsoft-365-copilot-extensions-and-plugins), the low-code route is [Copilot Studio](/guides/copilot-studio-explained), and the APIs are [Graph](/guides/microsoft-graph-api-basics).
## The unified manifest
The modern Teams app manifest (formerly called the Teams App manifest, now also referred to as **Microsoft 365 app manifest**) is a JSON document describing:
- **App identity** — name, ID, version, publisher.
- **App icons** and metadata.
- **Capabilities** — what kinds of things the app does:
- **Bots** — conversational agents.
- **Tabs** — embedded web pages.
- **Message extensions** — actions in the message composer and adaptive cards.
- **Static tabs** — pinned personal pages.
- **Meeting extensions** — surfaces inside Teams meetings.
- **Copilot agent extensions** — invocable from Microsoft 365 Copilot Chat with `@AgentName`.
- **Permissions** — which Microsoft Graph scopes the app needs.
- **Domains** — which web origins the app can talk to.
- **Distribution** — where the app should appear (Teams store, internal catalog, etc.).
One manifest covers all the surfaces; you don't write separate apps for Teams vs Outlook vs Copilot.
## Message extensions
The most useful starting point for many integrations:
- **Search extensions** — user types `@AppName search-query` in a Teams chat; the app returns matching results as adaptive cards.
- **Action extensions** — user invokes an action from the message composer or app menu; the app runs custom logic.
Existing message extensions automatically work as **Copilot extensions** — they show up in Copilot Chat for invocation. The user can `@AppName` from inside Copilot and get the same functionality.
For a CRM integration, this means: build a message extension that searches your CRM, deploy it once, and users get CRM search in Teams chats **and** in Copilot Chat — same code, same manifest.
## Building agent extensions
For richer AI-orchestrated experiences, build **agent extensions** via **Copilot Studio**:
- Define knowledge sources (SharePoint, Graph connectors, custom data).
- Define actions (Power Automate flows, custom connectors, plug-ins).
- Configure conversation behaviour.
- Publish as a Microsoft 365 Copilot extension.
Users invoke with `@AgentName` from Copilot Chat. The agent grounds on the defined knowledge and can take action via the defined connectors.
## Tabs and personal apps
For embedded web experiences:
- **Tabs** in Teams channels or chats — your web app embedded in an iframe inside Teams.
- **Personal apps** — pinned to a user's Teams sidebar for quick access.
These have been part of the Teams app model for years. The unified manifest now lets the same tabs and personal apps appear in **Outlook** and the **Microsoft 365 web home**.
## Authentication
Apps use **Microsoft Entra ID** for auth. The Teams app SDK handles the authentication flow:
1. User clicks the app in Teams.
2. SDK acquires a token via SSO if the user is already authenticated.
3. Token is sent with API calls to your backend.
4. Your backend validates and uses the token to call Graph or other APIs on behalf of the user.
Same identity model as any modern Microsoft 365 integration.
## Distribution
Once built, the app distributes via:
- **Microsoft Teams Store** — public marketplace, optionally publicly available or restricted.
- **Tenant app catalog** — internal apps sideloaded by admins or developers.
- **AppSource** — Microsoft's broader app marketplace.
For internal LOB apps, the tenant catalog is the right path.
## Tooling
- **Microsoft 365 Toolkit** (formerly Teams Toolkit) for Visual Studio Code — scaffolds projects, generates manifests, runs local development with tunnelling, deploys to test tenants.
- **Microsoft Graph SDKs** for backend integration.
- **Adaptive Cards** for rich card-based UIs.
- **Microsoft 365 Developer Program** for a free dev tenant to test against.
## When to build vs buy
For organisations considering custom app development:
- **Build** when the requirement is specific to your business, no off-the-shelf app fits, and you have engineering capacity.
- **Buy** when an off-the-shelf SaaS app (with native Teams / Microsoft 365 integration) covers the need.
- **Low-code instead** — Power Apps and Copilot Studio handle a lot of what previously required custom development. Consider before reaching for code.
For organisations doing custom development at all, the unified app model is dramatically more efficient than the historical pattern of separate Teams apps, separate Outlook add-ins, separate Copilot extensions. One codebase, many surfaces.
---
# Teams app permission policies design
URL: https://www.solvingmicrosoft365.com/guides/teams-app-permission-policies
Category: Microsoft Teams
Published: 2026-05-01
> Designing Teams app permission and setup policies — controlling app installation and pinning at scale.
Microsoft Teams has a vast app ecosystem — thousands of third-party apps plus custom internal apps. Without governance, users install whatever they want; the tenant fills with apps, including risky ones. **Teams app permission policies** and **app setup policies** are the admin controls that keep app sprawl manageable.
App permission policies are the control behind [Teams apps and tabs](/guides/microsoft-teams-apps-and-tabs) and, increasingly, [Copilot agents](/guides/copilot-agents-and-agent-store-governance); they belong to the same governance layer as [Entra app consent policies](/guides/entra-id-app-consent-policies) and [Power Platform DLP](/guides/power-platform-dlp-policies).
## App permission policies
An **app permission policy** controls **which apps users can install**:
### App categories
Apps are categorised:
- **Microsoft apps** — first-party (Planner, Forms, Lists, Forms, etc.).
- **Third-party apps** — published in the Teams Store.
- **Custom apps** — your tenant's internal apps.
### Policy options
For each category, choose:
- **Allow all apps** — permissive.
- **Allow specific apps and block all others** — allow list (only specified allowed).
- **Block specific apps and allow all others** — block list (only specified blocked).
- **Block all apps** — restrictive.
A typical balanced policy:
- **Microsoft apps** — Allow all.
- **Third-party apps** — Allow specific (an approved-app list curated by IT).
- **Custom apps** — Allow all (tenant-internal, already vetted by you).
### Assignment
Assign per-user or per-group. Different populations get different policies:
- **General users** — restricted third-party access.
- **Specific teams (sales, marketing)** — allow specific third-party apps relevant to their work.
- **IT and security team** — fewer restrictions for testing and evaluation.
## App setup policies
An **app setup policy** controls **which apps are pinned by default** in the user's Teams sidebar — visual prominence without install action:
- **Default pinned apps** — Activity, Chat, Teams, Calendar, etc.
- **Custom pinned apps** — pin your internal LOB app, an approved third-party app for the user's role.
- **Allow / restrict user-pinning** — can users themselves change the pinning.
Different setup policies per role surface different apps:
- **Sales reps** — pin your CRM Teams app.
- **HR team** — pin HR tools.
- **Engineering** — pin DevOps tools.
- **Executives** — pin Power BI app.
## App-centric management
The newer **app-centric management** experience in the Teams admin centre lets you manage apps per-app:
1. Find the app in the app catalogue.
2. Set **who can install it** — specific users / groups, all users, no users.
3. **Who has it pre-pinned** for fast access.
This per-app management complements policy-based management for surgical control.
## OAuth consent governance
Teams apps often request **Microsoft Graph permissions** the user has to consent to. Combined with **Entra ID app consent policies**:
- Restrict which Graph scopes users can consent to.
- Risky scopes require admin consent via the **admin consent workflow**.
- **Defender for Cloud Apps** alerts on suspicious OAuth grants.
This three-layer governance (Teams policies + Entra consent policies + Defender monitoring) prevents the most common Teams app risks.
## Permissions audit
Periodically inventory:
- **Which Teams apps are installed** tenant-wide (via the admin centre).
- **What permissions each has been granted**.
- **Usage statistics** — apps that nobody uses are candidates for blocking.
For Microsoft 365 customers with significant Teams usage, this inventory is worth running quarterly.
## App approval workflow
For organisations wanting users to **request apps** they want installed:
- **Custom approval flow** — Power Automate flow that captures requests, routes to IT, posts result to user.
- **Microsoft 365 admin centre** approval (when supported for the app type).
Better than "no" by default with no path to "yes" — users with a real need get approval; users without don't.
## Operational considerations
- **Document the approved app list** so users know what's available.
- **Communicate changes** — adding or removing apps from the allow list should be announced.
- **Regular review** — app catalogue changes; existing approvals should be re-validated periodically.
- **Pilot new apps** before broad rollout.
For tenants approaching Teams app sprawl, deploying explicit policies is the right correction. For new tenants, start with policies in place rather than fixing it later.
---
# Teams auto attendants and call queues
URL: https://www.solvingmicrosoft365.com/guides/teams-auto-attendants-and-call-queues
Category: Microsoft Teams
Published: 2026-05-01
> How to design auto attendants and call queues in Teams Phone — the modern PBX features built on resource accounts.
For organisations using Teams Phone, **auto attendants** and **call queues** are how you build the menus and queues that route inbound calls to the right people. Combined, they replace much of what a traditional PBX or contact-centre platform used to do for basic call routing.
## Auto attendants
An **auto attendant** is an interactive voice menu — "press 1 for sales, 2 for support, 3 for billing." Configuration includes:
- A **resource account** with a phone number that callers dial.
- **Greeting** in business hours and after hours (recorded audio, text-to-speech, or uploaded WAV).
- **Menu options** — DTMF (key press) or voice command, each routing to another auto attendant, a call queue, an external number, voicemail, or specific Teams users.
- **Business hours, holiday schedule, and time zone**.
- **Language**.
- **Dial scope** — which users in the directory can be dialled by name lookup.
Nested auto attendants are common: a main number routes to department auto attendants, which route to call queues with agents.
## Call queues
A **call queue** distributes inbound calls to a pool of **agents** (Teams users with the right calling licence). Configuration:
- A **resource account** with a phone number (or routed-to from an auto attendant).
- **Routing method**: attendant routing (all ring), serial routing, round-robin, longest-idle, presence-based.
- **Agents** — users assigned to the queue.
- **Hold music**.
- **Max wait time** and **max queue length** before overflow.
- **Overflow / timeout destinations** — voicemail, another queue, external number.
- **Greeting and waiting messages** at intervals.
Agents see queue calls in their regular Teams client with the queue name displayed. They can opt in or out of receiving queue calls via Teams settings (subject to policy).
## A worked example
A small business with sales and support:
```
[Main number] +1-555-123-4567
│
▼ (Auto attendant: greeting + menu)
├── 1 → Sales call queue (Tom, Alice, Sam)
├── 2 → Support call queue (Pat, Riley)
├── 3 → Billing → forward to external billing provider
└── 0 or after timeout → receptionist (Cindy)
```
Plus an **after-hours auto attendant** that says "we're closed, leave a message" and routes everything to a shared mailbox.
## Reporting
The Teams admin center provides reporting on:
- **Call counts** per queue and auto attendant.
- **Wait times** and abandonment rates.
- **Agent activity** — calls handled, calls missed.
- **Auto attendant menu selections** — which options callers pick most.
Useful for sizing call queues and identifying flow problems.
## When this isn't enough
For more advanced contact-centre scenarios — skills-based routing, screen pops, CRM integration, recorded compliance, advanced reporting, IVR with deep self-service — look at **Teams-certified contact centres** (Genesys, NICE, Five9, AudioCodes, Anywhere365). They integrate with Teams Phone for the agent experience while bringing dedicated contact-centre infrastructure.
For internal switchboards and small-to-mid call-routing needs, native Teams auto attendants and call queues are usually enough — and free with the Teams Phone licence.
## Frequently asked questions
**What is the difference between an auto attendant and a call queue?**
An auto attendant answers a number with a menu ('press 1 for sales'), routes by choice, business hours, and holidays, and can look up people by name. A call queue holds callers with music and distributes calls to a group of agents by routing method (attendant, serial, round robin, longest idle).
**Do auto attendants and call queues need licences?**
Each needs a resource account with a free Teams Resource Account licence (formerly Phone System Virtual User) and a phone number if it is dialled directly. Agents in queues need Teams Phone licences. Advanced queue features (in Teams Premium or Queues app) may need more.
**How do I see call queue statistics?**
The Queues app (Teams Premium) gives supervisors real-time and historical views; the Teams admin center provides auto attendant and call queue historical reports through Power BI templates and the call quality dashboard.
---
# Teams breakout rooms
URL: https://www.solvingmicrosoft365.com/guides/teams-breakout-rooms
Category: Microsoft Teams
Published: 2026-05-01
> How breakout rooms in Teams meetings work — configuration, facilitation patterns, and limitations.
**Breakout rooms** in Microsoft Teams meetings let an organiser split a meeting into smaller sub-meetings, then bring everyone back together. They're how you run workshops, training, and large-group discussions that need both whole-group time and small-group time.
Breakout rooms are one of the organiser tools in [meetings best practices](/guides/microsoft-teams-meetings-best-practices) and are controlled by [meeting policies](/guides/teams-meeting-policies-design); for workshops they combine with [Whiteboard for hybrid workshops](/guides/microsoft-whiteboard-hybrid-workshops), and for events they give way to [webinars](/guides/teams-webinars-vs-meetings-and-licensing).
## How breakout rooms work
In an active Teams meeting, the **organiser** (or designated breakout-rooms managers) opens the breakout panel and:
1. **Creates N rooms** (named or numbered).
2. **Assigns participants** automatically (round-robin), manually, or lets participants pick.
3. **Opens the rooms** — participants are moved to their assigned room as sub-meetings.
4. **Sets a timer** if desired, with countdown displayed to participants.
5. **Joins rooms** as the facilitator to check in, answer questions, redirect.
6. **Broadcasts a message** to all rooms simultaneously.
7. **Closes the rooms** when ready — everyone returns to the main meeting.
Each breakout room is itself a Teams meeting with its own chat, recording (if enabled separately), whiteboard, and screen sharing. Content created in a breakout — chat messages, whiteboard work — is **preserved after the room closes** and remains accessible to participants of that room.
## Configuration in advance
The organiser can configure breakouts **before the meeting starts**:
- **Number of rooms** and naming.
- **Pre-assigning participants** (useful for known attendee lists).
- **Designating co-organisers** as breakout managers.
- **Auto-assign** or **manual** mode.
Pre-configuration saves time when the meeting starts.
## Facilitation patterns
A few that work well:
- **Liked/Learned/Lacked retrospective**: each room takes one category, then rooms close and groups present back.
- **Speed networking**: short rounds of small-room conversations.
- **Case-study analysis**: each room takes a different case, then synthesises in main meeting.
- **Training breakouts**: hands-on exercises in small groups during a larger training session.
Pair with **Microsoft Whiteboard** in each breakout for visual collaboration; the whiteboards persist after closing.
## Limits and caveats
- **Up to 50 breakout rooms** in a single meeting.
- **External participants** can be assigned to breakouts (guests, federated users).
- **Anonymous participants** can't join breakouts directly — the organiser must make them registered first.
- **Recording** in breakouts is independent of the main meeting recording.
- **Mobile participants** can join breakouts on iOS and Android but with reduced facilitator features.
## When breakouts are right
- **Workshops and training** sessions.
- **Strategy sessions** with parallel work streams.
- **Large-group brainstorms** where everyone-at-once becomes unwieldy above ~20 people.
- **Cohort-based learning programmes**.
## When they're not
- **Casual meetings** where the overhead isn't worth it.
- **Very short meetings** — breakouts take a few minutes to set up and join.
- **Town halls and webinars** — broadcast formats, not breakout-friendly.
For meeting facilitators running workshops in Teams, breakout rooms are one of the most practical features in the product. The skill is in the facilitation, not the tooling — but the tooling has matured enough not to get in the way.
---
# Teams chat retention and policies
URL: https://www.solvingmicrosoft365.com/guides/teams-chat-retention-and-policies
Category: Microsoft Teams
Published: 2026-05-01
> How Teams chat messages are retained — defaults, Purview retention, eDiscovery scope, and end-user controls.
Microsoft Teams chat — both 1:1 messages and channel posts — has a more complex retention story than email or files. Knowing the defaults, what Purview retention does, and where the gaps are matters for compliance and operational decisions.
## Where Teams chat lives
Behind the scenes:
- **Channel messages** are stored as **chat messages in the underlying SharePoint site / Microsoft 365 Group**.
- **1:1 and group chats** are stored in the participants' **Exchange Online mailboxes** in a hidden folder.
- **Files shared in chat** are stored in the **sender's OneDrive** (for 1:1) or the **team's SharePoint site** (for channel posts).
- **Meeting recordings** are stored in **OneDrive or SharePoint** depending on context.
Different storage locations have different retention models — this is a key source of confusion.
## Default retention
Without explicit retention policies, Teams messages persist by default. Microsoft 365 doesn't auto-delete chat content the way some other platforms do.
However, **mailbox retention defaults** can affect 1:1 chat retention since the messages live in mailboxes. For most tenants, no aggressive default applies.
## Purview retention policies for Teams
Purview retention policies have **dedicated Teams scope options**:
- **Teams channel messages** — applied at the channel/team level.
- **Teams chats** — applied at the user mailbox level for 1:1 and group chats.
- **Teams meeting messages** — meeting-specific in-meeting chat (technically a sub-category).
- **Teams private channel messages** — separately scoped because they live in different SharePoint sites.
- **Teams shared channel messages** — also separately scoped.
Configure each independently — a retention policy might keep channel messages 7 years for regulatory reasons while keeping 1:1 chats only 1 year.
## End-user retention controls
By default, **users can't delete channel messages older than X days** unless the admin has enabled message deletion. Specific permissions:
- **Channel posters** can edit / delete their own messages.
- **Team owners** can delete any message in the team.
- **Compliance retention** overrides everything — if a policy retains for 7 years, user deletion just hides the message; it stays in preservation hold.
## Common pitfalls
- **Different retention per chat type** — easy to set retention on 1:1 chats but forget channel posts, or vice versa.
- **Files in chat** — files in 1:1 chats live in OneDrive; retention on the OneDrive applies. Files in channel posts live in SharePoint; retention on SharePoint applies. They don't follow the chat retention automatically.
- **Meeting chats** — separate retention scope; verify it's covered.
- **Private vs shared channels** — separate SharePoint sites mean separate retention scope. Adaptive scopes can target all sites of a specific kind.
- **Mailbox retention vs Teams retention** — the **Teams chats** retention scope is the right control for 1:1 messages; the **Exchange mailbox** retention scope applies broadly to mailbox content and is less precise.
## eDiscovery
Teams messages are **fully searchable in eDiscovery**. For investigations:
- **Channel messages** — searchable from the underlying SharePoint site / mailbox of the group.
- **1:1 and group chats** — searchable from the participants' mailboxes.
- **Conversation reconstruction** in Premium eDiscovery presents chats as coherent conversations rather than isolated messages.
For tenants subject to legal discovery, Teams chat is treated like email — search, hold, export — with the same workflow.
## Operational guidance
A reasonable baseline for many tenants:
- **Channel messages**: retain 7 years.
- **1:1 and group chats**: retain 1 year (or longer for regulated industries).
- **Meeting recordings**: retain 60 days (or per organisational policy).
- **Files in chat**: retain according to file storage policy (typically same as SharePoint / OneDrive).
For regulated industries — financial services, healthcare, legal — retention may extend to 7+ years across all Teams categories.
Document the retention design, communicate it to users, audit annually. Teams chat retention is one of those topics where the defaults work for nobody specifically but accumulate problems for everyone.
## Frequently asked questions
**How long are Teams chat messages kept?**
Indefinitely unless a Purview retention policy for Teams chats and channel messages says otherwise. Many organisations set a retention policy that deletes chats after a period (one to seven years is typical) and keeps channel messages longer, matching their email retention.
**Can users delete Teams messages permanently?**
A user can delete their own message from view, but if a retention policy or hold applies, the message is preserved in the hidden substrate and discoverable in eDiscovery. Without a policy, deleted messages are gone after a short period.
**Where are Teams chats stored for compliance?**
In a hidden folder in the users' Exchange mailboxes (and the group mailbox for channels), which is why Exchange holds and Purview retention cover them and why eDiscovery finds them. Files shared in chat are in the sender's OneDrive; channel files are in the team's SharePoint site.
---
# Teams Common Area Phones
URL: https://www.solvingmicrosoft365.com/guides/teams-common-area-phones
Category: Microsoft Teams
Published: 2026-05-01
> How Teams Phone supports shared, deskless phones for reception, warehouses, and shop floors.
A **Common Area Phone (CAP)** in Microsoft Teams is a shared, non-personal phone — a reception desk handset, a warehouse phone, a meeting room phone — that doesn't belong to one specific user. Teams Phone supports CAPs as a distinct licence and configuration model from regular user phones.
Common area phones are one device class in [Teams Phone](/guides/microsoft-teams-phone), licensed separately from users and routed through the same [Calling Plans or Operator Connect](/guides/teams-calling-plans-and-operator-connect) or [Direct Routing](/guides/teams-direct-routing-deep-dive) setup; they need the [emergency calling](/guides/teams-emergency-calling) configuration like any other endpoint, and share the fleet-management concerns of [Teams Rooms](/guides/microsoft-teams-rooms).
## What a CAP is
A CAP is a Teams-certified IP phone (Yealink, Poly, AudioCodes, others, mostly Android-based) signed in with a **resource account** rather than a user identity. The phone shows a simple dial pad, perhaps recent calls, a directory if configured — no user-specific features (no inbox, no meetings, no personal contacts).
Use cases:
- **Reception desks** in offices, hotels, clinics.
- **Warehouse and shop floors** where workers need an internal extension.
- **Common areas** like break rooms or lobbies.
- **Phone-only kiosks** at airports, hospitals, retail counters.
## Licensing
CAPs use the **Common Area Phone licence**, a low-cost SKU that includes Teams Phone Standard for the resource account. Calling plan minutes (if outbound calling to PSTN is needed) require an additional Calling Plan or Operator Connect arrangement.
A typical reception phone:
- **CAP licence** for the resource account.
- **Calling Plan** or **direct routing** for outbound PSTN calls.
- **Phone number** assigned to the resource account.
For inbound-only use cases (extension dialling within the company), no calling plan is needed.
## Configuration
Standard sequence:
1. **Create a resource account** in Entra ID with the Common Area Phone licence.
2. **Assign a phone number** in the Teams admin center if needed.
3. **Configure a Common Area Phone policy** in the Teams admin center — what features the phone has access to (call park, hot desking, meeting join, voicemail).
4. **Sign the phone in** with the resource account credentials. Modern CAP-certified phones support QR-code or device-code sign-in for easier deployment.
5. **Test calls** in and out.
## Hot desking
A CAP can be configured for **hot desking** — a user signs into the phone with their own Entra ID for the duration of their visit, getting their personal contacts, voicemail, and Teams presence. When they sign out (or after a timeout), the phone reverts to its CAP identity. Useful for shared offices where the same physical phone is used by different people across the day.
## Operational considerations
- **Resource accounts don't expire** — Microsoft 365 lifecycle policies that disable inactive users can break CAPs if not exempted.
- **Phone firmware updates** are managed in the Teams admin center; keep on the latest firmware.
- **Reset to factory** if a CAP is repurposed for a different room — the old resource account stays on the phone otherwise.
For organisations rolling out Teams Phone alongside Calling Plans / Operator Connect / Direct Routing, CAPs handle the shared-phone scenarios that personal user licences don't fit.
---
# Teams compliance recording
URL: https://www.solvingmicrosoft365.com/guides/teams-compliance-recording
Category: Microsoft Teams
Published: 2026-05-01
> How regulated industries record Teams calls and meetings for compliance — the recording APIs and partner solutions.
Some regulated industries — most notably financial services subject to SEC, FINRA, FCA, MiFID II — must **record and retain** voice and video communications for compliance. Microsoft Teams supports this via **compliance recording**, a specific recording category distinct from regular meeting recording.
## Compliance recording vs meeting recording
Two different things:
- **Meeting recording** — a meeting organiser or participant clicks record; the recording is saved to OneDrive / SharePoint for participants to review. Discretionary, user-driven.
- **Compliance recording** — automatic capture of voice and video for specific users (typically traders, brokers, advisors) regardless of meeting type, including 1:1 calls, ad-hoc calls, group calls, and meetings. Mandatory, policy-driven, recorded by a certified third-party platform.
Compliance recording is what regulators require; meeting recording is for convenience.
## How compliance recording works
Teams provides **Recording Bot APIs** that let certified third-party platforms attach to user sessions:
1. A user with the **CR policy** assigned starts a Teams call.
2. Teams notifies the configured **compliance recording platform** (Verint, NICE, Theta Lake, ASC, Red Box, AudioCodes SmartTAP, others).
3. The platform's bot joins the call invisibly and captures audio, video, and screen-shares.
4. Recordings are encrypted, stored on the platform's infrastructure (often with WORM controls), retained according to regulatory schedules.
5. Compliance officers can search and replay recordings via the platform's portal.
The recording is **transparent to the user** — they see a small recording indicator in some clients, but the call proceeds normally.
## What's covered
A typical compliance-recording deployment captures:
- **All 1:1 and group calls** between recorded users.
- **All meetings** the recorded user participates in.
- **All screen sharing**.
- **All chat messages** to and from the recorded user.
- **Voicemail** received by the recorded user.
External participants are notified of recording per local jurisdiction requirements (legally required disclosure in many countries).
## Configuration
Compliance recording requires:
1. **A certified compliance recording platform** — pick a vendor.
2. **Microsoft 365 E5** or **Teams Phone + appropriate add-on** for the recorded users.
3. **Compliance Recording Policies** in the Teams admin center — assigned to specific users (traders, advisors), referencing the recording bot.
4. **The recording platform's bot** registered as an Azure app with the right Graph permissions.
5. **Failover behaviour** configured — if the recording bot is unavailable, does the call proceed (less safe) or fail (less productive)?
## Operational considerations
- **Recording must be reliable** — regulators care about completeness; a missed conversation is a compliance violation.
- **Retention** is typically 5–7 years for SEC / FINRA scenarios; the recording platform handles it.
- **eDiscovery integration** — recordings should be searchable as part of broader investigations.
- **Cross-tenant calls** — recording works for guests and external Teams users joining recorded users' calls.
For organisations under MiFID II or US financial regulation, compliance recording isn't optional. The good news: the ecosystem is mature and partner platforms are well-integrated with Microsoft 365 governance.
---
# Teams Phone Direct Routing deep dive
URL: https://www.solvingmicrosoft365.com/guides/teams-direct-routing-deep-dive
Category: Microsoft Teams
Published: 2026-05-01
> Direct Routing connects Teams Phone to any SIP carrier — the architecture and the operational details.
**Direct Routing** is the connectivity option for Microsoft Teams Phone that lets you use **any SIP-capable carrier** for public-telephone-network (PSTN) connectivity, rather than buying Microsoft Calling Plans or going through Operator Connect. It's the most flexible option, and the right answer for many enterprises with existing carrier contracts or complex telephony requirements.
## The architecture
Direct Routing introduces one component you don't have in the simpler options: a **Session Border Controller (SBC)**. The SBC sits between Microsoft Teams and your SIP carrier, translating signalling and media between the two sides.
```
[Teams clients]
│
▼
[Microsoft Teams Phone service] (Azure-hosted)
│ SIP/TLS, SRTP
▼
[Your SBC] (on-prem or in Azure)
│ SIP, RTP (or SIP/TLS, SRTP — varies by carrier)
▼
[SIP carrier]
│
▼
[Public phone network]
```
The SBC is the only piece in this chain that doesn't come from Microsoft or your carrier. You buy it from one of Microsoft's certified vendors — AudioCodes, Ribbon, Oracle / Acme Packet, Anynode, Cisco, others — and configure it to talk to both Microsoft and your carrier.
## Why use Direct Routing
- **Existing carrier contracts** — your enterprise has negotiated SIP-trunk rates with a specific carrier, and you'd like to keep them.
- **Geographic coverage** — Microsoft Calling Plans are available in some countries; in others (or for specific regulatory regimes), you need a local carrier.
- **Contact-centre integration** — Direct Routing can integrate with on-prem contact-centre platforms more flexibly than Calling Plans.
- **Compliance recording** — recording vendors plug into the SBC for call recording at the network level.
- **Emergency-service integration** — country-specific 911/112 routing often requires local carrier configuration.
## Operational components
- **The SBC** itself — sized for peak concurrent call capacity, often deployed in pairs for HA.
- **Certificates** — public TLS certificates trusted by both Microsoft and the carrier.
- **Network connectivity** — direct paths between the SBC and Microsoft, with appropriate firewall rules and QoS.
- **SIP trunk(s)** to your carrier — sized for outbound concurrent calls.
- **Voice routing policies** in Teams admin center — decide which users use which SBC and which carrier paths.
## Configuration on the Teams side
In the Teams admin center, Direct Routing involves:
- **PSTN gateways** — the SBCs registered with Teams.
- **Voice routes** — patterns that determine which calls route to which gateway.
- **PSTN usages** — named groupings of voice routes.
- **Voice routing policies** — assignments of users to PSTN usages.
- **Dial plans** — local number translations per region.
PowerShell is essential — much of this is more efficiently configured via Teams PowerShell than the GUI.
## Common gotchas
- **Certificate expiration** on the SBC silently breaks signalling. Monitor.
- **Media bypass** (clients send media directly to the SBC rather than via Microsoft) reduces latency but requires careful network configuration.
- **Local Media Optimization (LMO)** for international deployments keeps media within regions.
- **Emergency calling** — every country has specific rules; Microsoft's documentation is essential reading per country.
- **Survivability** — if your SBC or trunk goes down, calls fail. Plan for HA.
## When to pick Operator Connect instead
If you'd take Direct Routing's flexibility but want to skip the SBC operational burden, **Operator Connect** is the middle ground. Microsoft certifies specific operators who run the SBC for you, manage the trunk, and integrate via the Teams admin center directly. Less flexible, far less operational overhead.
For enterprises with telecoms ops teams that already manage SBCs and SIP carriers, Direct Routing is the natural choice. For enterprises without, Operator Connect is usually a better fit.
## Frequently asked questions
**What is Direct Routing in Teams?**
Connecting Teams Phone to the public telephone network through your own (or a partner-hosted) certified Session Border Controller, which links to your chosen carrier's SIP trunk. It offers the most control — routing, analogue devices, legacy carriers — at the cost of running the SBC.
**Do I need a certified SBC for Direct Routing?**
Yes. Microsoft supports Direct Routing only with SBCs from certified vendors (AudioCodes, Ribbon, Oracle, and others) on supported firmware. Hosted SBC services from partners are an option if you do not want to operate hardware.
**Should I move from Direct Routing to Operator Connect?**
If your carrier offers Operator Connect and you do not need the SBC for analogue devices, complex routing, or a carrier without an Operator Connect presence, moving simplifies operations and removes a maintenance burden. Keep Direct Routing where those requirements exist.
---
# Teams Phone emergency calling
URL: https://www.solvingmicrosoft365.com/guides/teams-emergency-calling
Category: Microsoft Teams
Published: 2026-05-01
> How emergency calling works in Teams Phone — E911 / 112 location, dynamic detection, and country-specific requirements.
For organisations using **Teams Phone** as their primary telephony, **emergency calling** is a critical capability. When someone dials 911 (US/CA), 112 (EU), 999 (UK), or other emergency numbers, the call must reach the right emergency services with **the right location information**. Getting it wrong creates legal liability and, more importantly, real-world risk.
## How emergency calling works in Teams Phone
When a user dials an emergency number, Teams Phone:
1. **Detects it's an emergency call** based on country-specific dial patterns.
2. **Determines the user's location** from one of several sources (covered below).
3. **Routes the call** to a Public Safety Answering Point (PSAP) appropriate for that location.
4. **Provides the location** to the PSAP via the country's emergency-services protocol.
5. **Optionally notifies internal security** or designated responders that an emergency call has been placed.
The complexity is in step 2 — knowing where the user actually is when they dial.
## Sources of location
For each user, Teams Phone uses location from one of:
### Calling Plan / Operator Connect emergency locations
For users on Microsoft Calling Plans or Operator Connect, **emergency locations** are pre-registered in the Teams admin center per address. Each user has a default emergency address.
### Dynamic emergency calling
For organisations operating multiple offices or where users are mobile, **dynamic emergency calling** detects the user's current network location and provides the corresponding emergency address automatically:
- **Network sites** define corporate networks by subnet, IP range, or BSSID.
- **Network identifiers** map network attributes to specific addresses.
- When a user dials emergency, Teams uses their current network to determine location.
This is essential for organisations with multiple buildings — if a user in Building A dials emergency, the call should reach Building A's emergency services, not the headquarters address.
### Manual location confirmation
For roaming users on unknown networks (working from home, hotel, coffee shop), Teams can prompt the user to **confirm their current address** before completing the emergency call. The user's manually-entered address is used for routing and PSAP delivery.
### Direct Routing emergency calling
For Direct Routing configurations, emergency calling is the customer's responsibility to configure correctly via the SBC and SIP carrier. Microsoft provides emergency-calling APIs and integration points, but the heavy lifting is in your telecoms configuration.
## Country-specific requirements
Each country has its own emergency-services protocol:
- **United States** — **E911** with specific federal regulations. **Kari's Law** (notification requirements), **Ray Baum's Act** (dispatchable location requirements).
- **Canada** — **E911** with Canadian-specific PSAP integration.
- **United Kingdom** — **999** with location-based routing.
- **European Union** — **112** with E112 location requirements per country.
- **Australia** — **000** with specific routing requirements.
Microsoft Calling Plans cover specific countries; for other countries, Direct Routing or Operator Connect with local emergency-calling configuration is required.
## Operational considerations
- **Test emergency calling** during deployment, but **don't dial 911 / 112 for testing in production** — those are real emergency services. Use Microsoft's test numbers or carrier-specific test paths.
- **Network site definitions** need ongoing maintenance — when offices open / close / change subnet ranges, emergency configuration must update.
- **Roaming users on company devices** — communicate the location-confirmation prompt; users should know to provide accurate information when prompted.
- **Common Area Phones** — emergency configuration applies per-device, fixed location.
- **Compliance recording** — Teams Phone with compliance recording captures emergency calls by default; verify regulatory implications.
## Internal notification
A useful Teams Phone capability: **emergency call notification** alerts an internal contact list when emergency calls are placed. Reception, building security, or facilities can respond in parallel with emergency services.
Configured via **emergency call routing policies** in the Teams admin center. Typically configured to alert via email and SMS to designated security responders.
## Documentation and audit
Every emergency-related configuration matters for legal compliance:
- **Document the emergency calling design** — which users on which carriers in which locations.
- **Audit annually** — re-verify configurations, addresses, network site definitions.
- **Pre-deployment legal review** in jurisdictions with strict E911 / E112 regulations.
- **Post-incident review** if emergency calling fails — failure to deliver location to PSAP is a serious finding.
For organisations relying on Teams Phone as their primary telephony, emergency calling is not an afterthought. Plan it deliberately; document carefully; audit annually. The cost of failure is too high to leave to chance.
## Frequently asked questions
**How does emergency calling work in Teams?**
Teams Phone routes emergency calls (112/911/999) with a location: for Calling Plans and Operator Connect, dynamic emergency calling can detect the user's location from network elements you define (subnets, Wi-Fi access points, switches) and send it with the call; otherwise the registered address on the number is used.
**What is Kari's Law and RAY BAUM's Act?**
US regulations requiring direct 911 dialling without a prefix and notification of on-site personnel (Kari's Law), and dispatchable location — floor, room — with the call (RAY BAUM's Act). Teams supports both via emergency calling policies and dynamic location; organisations with US users must configure them.
**Do remote workers get emergency location in Teams?**
Only if the client can determine it: on Windows and Mac, Teams can prompt the user to confirm or enter an address when working off-network, which is sent with an emergency call. Configure the emergency calling policy to enable the address prompt for remote users.
---
# Teams external collaboration patterns
URL: https://www.solvingmicrosoft365.com/guides/teams-external-collaboration-patterns
Category: Microsoft Teams
Published: 2026-05-01
> Picking the right external-collaboration pattern in Microsoft Teams — guests, shared channels, federation, anonymous join.
External collaboration in Microsoft Teams is a confusingly named space with four overlapping mechanisms. Picking the right one for the relationship matters for security, user experience, and operational sanity.
## The four mechanisms
- **Guest access** — full member of one of your teams, with a guest identity in your tenant.
- **External access (federation)** — one-to-one chat/calling with other Microsoft 365 tenants. No team membership.
- **Shared channels (Teams Connect)** — invite people from other Microsoft 365 tenants into a specific channel without making them guests in your tenant.
- **Anonymous join** — join a meeting without any tenant identity; just enter a name.
## When to use each
### Guest access
For **deep, long-term collaboration** with named external individuals — an embedded consultant working in your project team for a year, an executive advisor with full visibility into your strategy team, etc.
Pros:
- Full access to the team's content (subject to permissions).
- Familiar Teams experience for the guest.
Cons:
- Each guest is an identity in your tenant.
- Guests accumulate over time if not cleaned up.
- Permissions on team-wide files exposed to all members including guests.
### External access (federation)
For **direct messaging and calling** between specific people at different organisations — a CEO talking to a peer at a partner company. No shared workspace; just chat and call.
Pros:
- No identity created in either tenant.
- Persistent direct relationship between specific people.
- Lightweight.
Cons:
- Limited to 1:1 chat and calling.
- No shared files, no shared channels.
### Shared channels (Teams Connect)
For **ongoing cross-organisation work** between teams at different Microsoft 365 tenants — a joint product team with people from two companies, an industry consortium working on a standard, etc.
Pros:
- Members keep their own tenant identity.
- Cleaner than mass guest access.
- Each shared channel has its own SharePoint site with appropriate isolation.
Cons:
- Requires both tenants to configure Cross-Tenant Access Settings.
- Channel members don't see the rest of the team.
- Not suitable for non-Microsoft-365 external parties.
### Anonymous join
For **one-off external meetings** where the attendee doesn't have a Microsoft 365 account (or you don't want to bother with identity setup) — webinar attendees, occasional vendor calls, customer events.
Pros:
- No identity setup needed.
- Just send a meeting link.
Cons:
- No identity audit trail.
- No persistent relationship after the meeting.
## Decision matrix
| Scenario | Right mechanism |
| --- | --- |
| Long-term embedded contractor | Guest access |
| Direct chat with another company's CEO | External access |
| Ongoing project with partner organisation | Shared channel |
| One-off webinar or external meeting | Anonymous join |
| Specific external user needs file access | Guest or shared channel |
| Mass external audience for a town hall | Anonymous join via Town Halls |
## Configuration
All four are configured independently — confusingly:
- **Guest access** — overall toggle in Teams admin center plus tenant-wide controls in SharePoint admin center for guest file sharing.
- **External access** — in Teams admin center → Users → External access. Tenant-by-tenant federation control.
- **Shared channels** — Cross-Tenant Access Settings in Entra admin center, plus shared-channel-specific policies in Teams admin center.
- **Anonymous join** — Teams meeting policy.
A tenant can have any combination enabled. Many production configurations have all four enabled with different controls per relationship.
## Common pitfalls
- **Asking "is Teams open to external?"** without distinguishing which mechanism is meant. Be specific.
- **Granting guest access when shared channels would be cleaner** — shared channels are the modern default for ongoing cross-org work.
- **Forgetting to lifecycle external access** — orphaned guests, stale shared channels.
- **Mismatched configuration between tenants** for shared channels — both tenants need to trust each other for the partner.
For organisations doing significant external collaboration, decide on a deliberate posture per relationship type. Document it. Communicate to users which mechanism to use when. Audit periodically. This deliberateness is the difference between "external collaboration works" and "external collaboration is a mess."
---
# Teams meeting policies design
URL: https://www.solvingmicrosoft365.com/guides/teams-meeting-policies-design
Category: Microsoft Teams
Published: 2026-05-01
> Designing Teams meeting policies for different user populations — recording, transcription, lobby, presenters, sharing.
**Teams meeting policies** govern what users can do in meetings — recording, transcription, lobby behaviour, presenter controls, screen sharing, chat, breakouts, watermarking. Designing the policy set deliberately, rather than leaving everyone on the Global default, is one of the higher-leverage admin actions in a serious Teams deployment.
The shorter map of what a meeting policy is lives in [Microsoft Teams meeting policies](/guides/microsoft-teams-meeting-policies); adjacent controls are [meeting recording management](/guides/teams-meeting-recording-management), [sensitivity labels for meetings](/guides/sensitivity-labels-for-teams-meetings), [live captions and translation](/guides/teams-live-captions-and-translation), and the Copilot-in-meetings settings in [Copilot in Teams meetings](/guides/copilot-in-teams-meetings-recap-and-action-items).
## The Global default
Every tenant has a **Global (Org-wide default)** meeting policy. The shipped defaults are reasonable starting points for most organisations, but worth reviewing:
- **Cloud recording**: on by default — usually correct.
- **Transcription**: on by default — required for Copilot meeting recap.
- **Anonymous join**: on by default with lobby — usually correct.
- **Who can present**: "Everyone" by default — usually wrong; should be "Specific people" or "Only organisers."
- **Lobby bypass**: "Everyone" by default — usually wrong; should be "People in your organisation."
Many tenants improve security and consistency just by tightening the Global default.
## Custom policies for specific populations
Beyond Global, create custom policies for populations with specific needs:
### Executives
- **Watermarking** on (Teams Premium) for confidential meetings.
- **Recording** off by default — manual enable per meeting.
- **End-to-end encryption** available (Teams Premium) for highly confidential meetings.
- **Lobby** stricter — manual admit even for internal participants.
- **Chat retention** longer for accountability.
### General employees
- **Default policy** with reasonable settings.
- **Anonymous join** allowed with lobby for external meetings.
- **Recording** allowed but not required.
### Frontline / shift workers
- **Reduced features** — many meeting features irrelevant.
- **Walkie Talkie** more important than meetings.
### Restricted users (interns, contractors)
- **No recording** (privacy concerns).
- **No anonymous attendees** they can admit.
- **Specific people can present** locked down.
- **Sensitive features** disabled.
## Lobby and presenter controls
Two of the most important settings:
### Lobby bypass
Who skips the lobby and joins meetings immediately:
- **Everyone** — anyone can join without admission. Use only for public webinars.
- **Everyone except dial-in users** — common reasonable default.
- **People in your organisation** — internal users skip; externals wait.
- **People in your organisation and trusted organisations** — internal plus federated partners skip.
- **People I invite** — only explicitly-invited get in.
For most meetings, "People in your organisation" is the right default. External attendees wait in lobby; organiser admits when ready.
### Who can present
By default, **everyone** can present in a Teams meeting. This means external attendees can present, take control, share their screen. Better defaults:
- **Specific people** — designated presenters by name.
- **Only organisers and co-organisers** — strictest.
- **People in your organisation** — internal users can present.
For meetings with external attendees, especially webinars and customer-facing meetings, restrict who can present.
## Recording and transcription
For **Microsoft 365 Copilot users**, **transcription must be enabled** for meeting recap to work. Recording is optional; transcription alone gives the AI summarisation capability.
Recordings store in:
- **Channel meetings** → the channel's SharePoint site.
- **Other meetings** → the organiser's OneDrive.
Retention follows the storage location's policies. For default 60-day or shorter retention of meeting recordings, configure a **Purview retention policy** scoped to Teams meeting messages.
## Watermarking and Teams Premium
**Teams Premium** unlocks several meeting-protection features:
- **Watermarks** on shared content and video — recipient identity displayed semi-transparently.
- **End-to-end encryption** for scheduled meetings.
- **Sensitivity-label-driven meeting controls** — different protections per labelled meeting.
For high-security meetings (board, M&A, legal), these features matter.
## Configuration via PowerShell
Bulk policy configuration is faster via PowerShell:
```powershell
Connect-MicrosoftTeams
# Create a custom policy
New-CsTeamsMeetingPolicy -Identity "Executive" `
-AllowCloudRecording $false `
-AllowMeetWatermark $true `
-DesignatedPresenterRoleMode "OrganizerOnlyUserOverride"
# Assign to a user
Grant-CsTeamsMeetingPolicy -Identity exec@yourcompany.com -PolicyName "Executive"
```
## Operational discipline
- **Document the policy set** so admins know what each does.
- **Pilot before broad assignment** — test policies on a small group.
- **Review periodically** — Microsoft adds new settings; existing policies don't auto-include them.
- **Audit assignments** — users on wrong policies create surprises.
For organisations using Teams seriously, well-designed meeting policies are one of the lower-effort, higher-leverage Teams admin investments. The Global default tweaked plus 2–3 custom policies for specific populations covers most needs.
## A worked example: three-tier policy set
Rather than one all-encompassing policy, most organisations settle on three:
- **Default (everyone).** Recording allowed with consent-notice on; transcription on; live captions on; meeting chat on; anonymous join for scheduled meetings only; screen share for entire screen and applications; PSTN dial-out allowed within the country; watermarks off (E5/Teams Premium only anyway).
- **External-facing (client-facing staff).** Same as default but: participants sent to lobby by default (organisation, federated, and trusted orgs bypass); anonymous users can join scheduled meetings but not present without organiser promote; recording auto-notifies chat; meeting insights and Copilot recap on.
- **Restricted (regulated roles: legal, HR, senior finance, boards).** Recording off (or "controlled" — only organiser can start); transcription off; anonymous join off; lobby for everyone including staff; meeting chat off after meeting ends; sensitive-content watermarks on (Teams Premium); Copilot recap off; end-to-end encryption available on 1:1 calls for that role.
Assign via group-based licence-style Teams policy assignment, not per-user clicks. Reassign nightly via Set-CsUserPolicyPackage or the newer Graph endpoints if you drive it from an identity source of truth.
## Decision matrix: which policy to touch first
| Concern | Setting |
| --- | --- |
| Untrusted anonymous joiners | **Anonymous join** off, or lobby everyone |
| Sensitive discussions leaking through recording | **Meeting recording** off for that policy, or org-wide with organiser-only start |
| External participants seeing private chat history | **Meeting chat** = for the current meeting only |
| Screen-share of the wrong window | **Content sharing** = single app only, disable entire screen |
| Overwhelming attendee count in a broadcast | **Meeting type** = webinar or town hall, not standard meeting |
| Recording retention drift | Purview retention on the storage location (organiser's OneDrive for chats, meeting site for channel meetings) |
| End-to-end encrypted 1:1 calls | **Enhanced encryption for 1:1** in the policy |
| Sensitive-content watermark on the meeting | **Sensitivity label** on the meeting invite (Teams Premium) |
## When meeting policies are the wrong tool
- **You need per-meeting overrides.** Meeting options (per-invite) override the policy for chat, lobby, presenters, and camera/mic. Design the policy for the 90th-percentile meeting, not the exception.
- **You need to block file sharing in-meeting.** That's DLP and SharePoint permissions on the storage location, not a meeting-policy setting.
- **You need to prevent recording by the participant's OS/other software.** Meeting policies can only stop Teams from recording. External capture is a human/legal problem, not a policy problem.
- **You need to change chat retention.** Teams chat retention is a Purview retention policy, scoped to Teams. Meeting policies don't control retention.
## MSP checklist
- **Default, external-facing, restricted** three-tier template applied at every new tenant.
- **Group-based assignment.** Never per-user for meeting policies — the audit trail is worse and the drift is guaranteed.
- **Change control.** Meeting-policy edits go through a documented change ticket. Silent tweak = call at 4pm from the client's marketing team saying anonymous join stopped working.
- **Recording storage audit.** Monthly per-client: which OneDrive/SharePoint sites hold meeting recordings, retention posture on those, any recordings shared externally.
- **Teams Premium features** enabled per-user, not tenant-wide, and reviewed quarterly against actual usage — the seats are the expensive part.
---
# Teams meeting recording management
URL: https://www.solvingmicrosoft365.com/guides/teams-meeting-recording-management
Category: Microsoft Teams
Published: 2026-05-01
> How Teams meeting recordings are stored, governed, retained, and discovered — and the admin decisions that matter.
When Teams meetings are recorded, the recordings are video files stored in Microsoft 365 — not in a separate "Stream" system anymore. Knowing **where they live, who can see them, how long they're kept, and how to find them later** matters for compliance, governance, and discovery.
## Where recordings live
Recording storage depends on **meeting type**:
- **Non-channel meetings** (scheduled or ad-hoc, not in a Teams channel) — saved to the **organiser's OneDrive**, in a `Recordings` folder.
- **Channel meetings** (held in a Teams channel) — saved to the **channel's SharePoint site**, in a `Recordings` folder in the channel's files area.
Permissions inherit from the storage location:
- Non-channel meeting recording → meeting attendees and the organiser can access (with sharing links automatically set up).
- Channel meeting recording → channel members can access.
## What's saved
- The video file (`.mp4`).
- An accompanying transcript (if transcription was enabled).
- Closed-caption files.
- Chapters / table-of-contents metadata.
- AI-generated meeting recap content (if Microsoft 365 Copilot was active).
The transcript is critical for **searchability** and for **Microsoft 365 Copilot's meeting recap** functionality. Without transcription, Copilot can't summarise post-meeting.
## Retention
By default, meeting recordings have **no retention policy** — they stay until explicitly deleted. This produces accumulation problems for organisations with high meeting volume.
Configure retention via **Microsoft Purview retention policies** targeting the storage locations:
- **OneDrive retention** for non-channel meeting recordings.
- **SharePoint site retention** for channel meeting recordings.
- **Specific Teams meeting message retention** for in-meeting chat (separately).
A typical baseline: retain meeting recordings 60–90 days, then auto-delete. For specific compliance scenarios (financial services regulated calls), retain 7+ years.
Alternative: **OneDrive admin centre's auto-delete for meeting recordings** — a simpler setting if your only requirement is "delete recordings after N days."
## Discovery and search
Recorded meetings appear in Microsoft Search results like any file. Users can search:
- By **meeting title**.
- By **content within the transcript** — search for specific phrases said during the meeting.
- By **speaker** — find meetings where specific people spoke (limited support).
- By **participant** — meetings the user attended.
For analysts or compliance officers needing systematic recording review, the Defender XDR / Purview interfaces can aggregate.
## Compliance scenarios
For regulated industries needing **call recording** beyond ad-hoc meeting recording:
- **Compliance recording** via Teams certified partners (Verint, NICE, Theta Lake, others) captures **all** Teams voice and video for specific users (traders, advisors). Different mechanism from meeting recording.
- **Information protection** — sensitivity labels applied to meetings can govern recording behaviour and access.
## End-user behaviour
The meeting recording capability surfaces to users as:
- A **Record** button during the meeting.
- **Automatic recording start** if the meeting policy requires it.
- A **recording-started notification** for all attendees.
- A **recording link** posted to the meeting chat after the meeting ends.
Educate users that:
- Recordings show in their chat history for easy access.
- The recording link is also in their or the organiser's OneDrive / SharePoint.
- They can rename, download, share, or delete the recording.
## Admin controls
In the **Teams admin centre → Meeting policies**:
- **Allow cloud recording** — on / off, per user policy.
- **Allow transcription** — on / off (essential for Copilot meeting recap).
- **Automatic transcription** — start transcription automatically for all meetings.
- **Storage** location — fixed by meeting type, but admin can verify settings.
In the **Microsoft 365 admin centre**:
- **OneDrive defaults** including auto-delete for meeting recordings.
- **SharePoint defaults** for channel meeting storage.
## Common operational issues
- **Recordings filling OneDrive storage** — without retention, organiser quotas grow unboundedly.
- **Lost recordings after employee departure** — recordings in the departed employee's OneDrive may be inaccessible unless ownership transferred.
- **Sensitivity label inheritance** — labels on the underlying meeting affect the recording.
- **Channel recording orphaned** — if the team is deleted, recordings go with it.
For organisations running Teams as a meeting platform at scale, recording governance is one of those "obvious in hindsight" investments. Set retention policies; communicate to users; audit periodically.
---
# Teams Premium features deep dive
URL: https://www.solvingmicrosoft365.com/guides/teams-premium-features-deep-dive
Category: Microsoft Teams
Published: 2026-05-01
> Microsoft Teams Premium is a paid add-on with a specific set of meeting and protection features. Here's what you get.
**Microsoft Teams Premium** is a paid per-user add-on that bundles a set of advanced Teams capabilities not included in standard plans, even E5. Knowing what's in it helps decide whether the add-on is worth it for your tenant.
Premium is an add-on in the [Teams licensing picture](/guides/what-is-microsoft-teams); the features it unlocks are used in [webinars](/guides/teams-webinars-vs-meetings-and-licensing), [town halls](/guides/teams-town-hall-vs-live-events-vs-stream), [live translation](/guides/teams-live-captions-and-translation), [sensitivity-labelled meetings](/guides/sensitivity-labels-for-teams-meetings), and [call queues](/guides/teams-auto-attendants-and-call-queues); [Copilot licensing](/guides/microsoft-365-copilot-licensing) explains the overlap with intelligent recap.
## Intelligent meeting recap
The flagship feature: Teams Premium meetings get **intelligent recap** automatically:
- **AI-generated meeting notes** with section headings.
- **AI-generated action items** assigned to specific people where named.
- **Speaker timelines** so you can jump to who said what.
- **Chapters** auto-detected from topic changes.
- **Personalised insights** — highlights of when you were mentioned, when topics relevant to you came up.
Requires meeting transcription to be enabled (which itself requires explicit consent in many configurations).
## Advanced meeting protection
- **Watermarks** — recipient name/email watermarked on shared content and video, deterring screenshots.
- **End-to-end encryption** for scheduled meetings (1:1 has E2E in standard Teams; group meetings require Premium).
- **Sensitivity-label-driven meeting policies** — apply different controls to meetings labelled Confidential or Highly Confidential.
- **Restricted content sharing** — block specific apps and surfaces from receiving shared content.
## Advanced webinars
Premium adds webinar features beyond the standard Teams webinar:
- **Manual registration approval** — review and approve attendees rather than auto-confirming.
- **Registration waitlists** when capacity is reached.
- **Custom registration questions** with rich field types.
- **Custom branded landing pages** matching organisation branding.
- **RTMP-in** — bring in external A/V feeds from a hardware encoder.
- **Green room** enhancements for presenters.
## Virtual appointments
Premium enables the **Virtual Appointments** experience for businesses with customer-facing meetings:
- Branded waiting rooms.
- SMS notifications for appointments and reminders.
- Queue management.
- Integration with Microsoft Bookings.
Used heavily in healthcare, financial services, professional services.
## Town hall enhancements
For very large broadcasts, Premium adds Town Hall features:
- Larger attendee capacities.
- External presenter support.
- More language options for real-time interpretation.
## Personalisation
- **Custom Together Mode scenes** matching your brand.
- **Organisation backgrounds** delivered to all users.
- **Customised meeting templates** for repeatable session types.
## What it doesn't include
- **Microsoft 365 Copilot** is a separate add-on — Teams Premium doesn't unlock Copilot in Teams.
- **Teams Phone** is also separate — Premium doesn't add calling capabilities.
- **Teams Rooms Pro** is a separate per-room licence — different product.
## Should you buy it
Teams Premium is most valuable for:
- **Executive teams** running confidential meetings — watermarking, E2E encryption, label-driven controls.
- **External-facing teams** running webinars, training, customer events — advanced webinar features.
- **Customer-service organisations** — virtual appointments.
- **Heavy meeting users** — intelligent recap saves real time.
For organisations where most meetings are casual internal stand-ups, Premium's value is lower. Pilot with a focused group and measure before broadcasting it.
## Frequently asked questions
**What does Teams Premium include?**
Intelligent recap and AI notes without a Copilot licence, advanced webinars (registration waitlists, manual approval, reminders) and town halls with higher capacity, meeting protection (watermarks, sensitivity-label-driven settings, end-to-end encryption), branded meetings, virtual appointments with SMS and queueing, and the Queues app for call centres.
**Is Teams Premium needed if we have Copilot?**
Copilot covers intelligent recap for licensed users. Premium is still needed for meeting protection, advanced webinars and town halls, branding, virtual appointments, and Queues — features Copilot does not include. Some organisations license Premium only to the teams that run events or call queues.
**How much does Teams Premium cost?**
Approximately 10 USD per user per month list (as of 2026-09; check Microsoft), as an add-on to any plan that includes Teams. It is licensed per user, and the organiser's licence governs the meeting's features.
---
# Teams Rooms deployment and management
URL: https://www.solvingmicrosoft365.com/guides/teams-rooms-deployment-and-management
Category: Microsoft Teams
Published: 2026-05-01
> How to plan, deploy, and operate Microsoft Teams Rooms at scale — devices, accounts, policies, and the Pro Management Portal.
Deploying **Microsoft Teams Rooms (MTR)** in dozens or hundreds of meeting rooms is the kind of project that looks straightforward but accumulates operational detail fast. Knowing the moving parts ahead of time prevents rework.
## Device choices
Teams Rooms runs on certified devices from many partners. The first split:
- **Teams Rooms on Windows** — a Windows-based appliance running the MTR application. Richer enterprise features, content-camera support, more peripheral options, suited for larger and more sophisticated rooms.
- **Teams Rooms on Android** — Android-based dedicated unit. Simpler, cheaper, suited to small rooms and huddle spaces.
Manufacturers: Logitech, Poly, Yealink, Crestron, Neat, Cisco (yes, even Cisco room kits can run Teams), Microsoft Surface Hub.
## Room sizing and component choices
Match the kit to the room:
- **Huddle (2–4 people)** — single all-in-one bar with camera, speakers, mic.
- **Small (4–6)** — bar with adequate mic coverage; one or two displays.
- **Medium (6–12)** — bar or modular, ceiling mic, sound bar, two displays.
- **Large (12–25)** — ceiling mic array, distributed speakers, multiple cameras, three or four displays.
- **Board rooms / executive (25+)** — custom AV with Teams Rooms compute integrated.
Sound quality matters more than video — invest in mics and acoustic treatment over extra screens.
## Resource accounts
Each room has a **resource account** in Entra ID with:
- A **Teams Rooms Basic** or **Teams Rooms Pro** licence.
- An **Exchange room mailbox** so users can invite the room to meetings.
- **Auto-accept settings** configured (decline conflicts, no future meetings booked far in advance).
- **Conditional Access exemptions** as needed for headless device sign-in.
Resource accounts are non-human identities, so MFA configuration needs care — typically certificate-based or strong device binding rather than human-style MFA.
## Pro vs Basic licensing
- **Teams Rooms Basic** — free for the first 25 rooms per tenant, with limited management features.
- **Teams Rooms Pro** — paid per room per month. Adds the **Pro Management Portal** with fleet-wide management, intelligent meeting features (Front Row layout, speaker tracking, content camera support), deeper analytics and reporting.
Pro is the right answer for any serious deployment.
## Pro Management Portal
The Pro Management Portal at `rooms.cloud.microsoft` provides:
- **Inventory** — every room device with health, OS version, peripheral status.
- **Remote actions** — reboot, run diagnostics, push updates.
- **Configuration** — push policies to specific devices or groups.
- **Health analytics** — call quality, uptime, sign-in failures, peripheral issues.
- **Incident tickets** — Microsoft can open and manage support tickets for room issues if you opt in.
For organisations operating 50+ rooms, the Pro Management Portal is essential — managing rooms one-by-one in the Teams admin center doesn't scale.
## Policies
Teams Rooms devices follow:
- **Teams Rooms-specific meeting policies** in the Teams admin center.
- **Configuration profiles** for OS-level settings (Windows Update behaviour, theme).
- **Network configuration** — QoS, IP whitelisting, proxy bypass for Teams media (covered in network connectivity guide).
## Common pitfalls
- **Network quality** is the #1 cause of bad meetings — invest in dedicated Wi-Fi or wired networking with QoS.
- **Device firmware** — keep peripherals (cameras, mics) updated; old firmware causes mysterious issues.
- **Resource accounts drift** — accounts sometimes lose Exchange auto-accept settings; check periodically.
- **Power management** — devices need to stay on; aggressive power policies break the experience.
A successful MTR deployment is mostly about operational discipline — the technology is mature, but the operating model needs to be deliberate.
---
# Teams Walkie Talkie and frontline workflows
URL: https://www.solvingmicrosoft365.com/guides/teams-walkie-talkie-and-frontline
Category: Microsoft Teams
Published: 2026-05-01
> Teams Walkie Talkie provides push-to-talk for frontline workers on Wi-Fi or cellular — alongside Shifts and Tasks for shift-based work.
For **frontline workers** — retail associates, warehouse staff, healthcare workers on hospital floors, manufacturing operators — Microsoft Teams ships a suite of capabilities designed around shift-based, deskless work patterns. The headline ones: **Walkie Talkie**, **Shifts**, **Tasks by Planner**, and frontline-specific Teams app layouts.
Walkie Talkie is one of the frontline features alongside [Shifts](/guides/microsoft-teams-shifts-for-frontline), licensed through the [Frontline plans](/guides/frontline-plans-deep-dive); the devices are typically managed with [Intune and Android Enterprise](/guides/intune-android-enterprise) and protected by [mobile device security](/guides/microsoft-365-mobile-security) policies.
## Walkie Talkie
**Walkie Talkie** in Teams provides **push-to-talk (PTT) voice** over Wi-Fi or cellular, replacing legacy handheld radios in many industries. Pick a channel, hold the button to talk, release to listen. Single channel at a time per user; instant connection within the channel.
Use cases:
- **Retail floor** — associates communicating across a store.
- **Warehouse / distribution** — coordination among shift workers across a large facility.
- **Healthcare** — clinical staff on hospital floors.
- **Hospitality** — front-of-house and back-of-house coordination.
- **Manufacturing** — production-floor communication.
Walkie Talkie runs on:
- **iOS and Android** devices with the Teams app.
- **Dedicated rugged devices** with PTT-button hardware integration — Zebra, Honeywell, Spectralink, others.
- The button mapping on dedicated devices makes Walkie Talkie work like a traditional radio: one button to talk, instant operation.
## Shifts
**Microsoft Shifts** is the shift-scheduling app in Teams. Managers build schedules; workers view their shifts, request time off, swap with colleagues, and clock in / out. Connectors integrate with workforce management systems (Blue Yonder, Kronos / UKG, Reflexis) so the source-of-truth schedule in WFM appears in Teams.
For frontline workers, Shifts is often the most-used Teams feature — schedule visibility on mobile is a daily need.
## Tasks by Planner
**Tasks** in Teams brings Planner functionality to frontline scenarios:
- **Task publishing** — corporate HQ pushes standardised task lists to specific store / location / shift teams.
- **Per-location tracking** — see which stores have completed the seasonal-display checklist.
- **Manager visibility** into team task completion.
Used heavily in retail for store opening / closing checklists, compliance tasks, marketing rollouts.
## Frontline-tailored Teams layout
Frontline workers get a **simplified Teams app layout** via Intune configuration and Teams policies:
- **Walkie Talkie** front and centre.
- **Shifts** in the navigation.
- **Tasks** prominent.
- **Reduced complexity** — channels collapsed, files de-emphasised.
- **Single sign-on** with their shared device or personal device.
The default knowledge-worker Teams layout is overwhelming for floor staff; the frontline experience is purpose-fit.
## Microsoft 365 F SKUs
Frontline workers are licensed via **Microsoft 365 F1** or **F3** plans — substantially cheaper than knowledge-worker plans. Each F SKU includes the frontline-tailored Teams experience plus appropriately scoped Outlook, OneDrive, and other services:
- **F1** — web and mobile only, minimal storage.
- **F3** — adds installable Office mobile apps, larger storage.
For organisations with significant frontline populations, F SKUs are often **the largest seat count** of the tenant by far.
## Shared device sign-in
For frontline scenarios where devices are shared across shifts:
- **Android shared device mode** with Intune — sign in / sign out fast, no personal-account exposure.
- **Hot desking on Teams CAP devices** — sign in to a shared device for the shift; sign out at end of shift.
These sign-in patterns are essential to the workflow — without them, frontline workers waste time on slow authentication.
## Communications with HQ
For two-way communication between corporate and frontline:
- **Viva Connections** in Teams — branded company-news experience.
- **Targeted Teams messages** to specific frontline groups.
- **Microsoft Viva Engage** for community discussions.
## Operational considerations
- **Battery life** — frontline workers on shift devices need full-shift battery. Walkie Talkie's PTT is reasonable; other Teams activities drain faster.
- **Connectivity** — Wi-Fi coverage on the work floor is critical. Cellular fallback helps.
- **Training** — frontline staff often have less Teams experience; brief training pays back.
- **Device management** at scale — Intune for Android Enterprise dedicated device mode for kiosk scenarios.
For organisations with significant frontline populations — retail, healthcare, hospitality, logistics — Microsoft 365's frontline offering has matured into a credible alternative to legacy purpose-built solutions. The integration with the broader Microsoft 365 estate is the differentiator.
---
# Token protection and token theft in Microsoft 365
URL: https://www.solvingmicrosoft365.com/guides/token-protection-and-token-theft
Category: Microsoft Entra (Identity)
Published: 2026-05-01
> Token theft has become a leading attack pattern. Here's how it works and what Microsoft 365 offers to defend against it.
In recent years, **token theft** has become one of the dominant attack patterns against Microsoft 365 tenants. Attackers don't need the user's password if they can steal the **session tokens** issued after the user has already signed in — and tokens can be stolen from compromised devices, intercepted on insecure networks, or extracted via phishing kits running adversary-in-the-middle proxies.
## How token theft works
The classic pattern:
1. Attacker sends a phishing email with a link to a **fake Microsoft sign-in page** hosted on attacker infrastructure.
2. Victim clicks, the page **proxies their input through to the real Microsoft sign-in** — capturing both the credentials and the **session token** Microsoft issues.
3. Attacker now has a valid session token that **doesn't require knowing the password or completing MFA again** — the MFA has already been completed by the victim.
4. Attacker imports the token into their own browser session and accesses the user's mailbox, files, Teams.
MFA alone doesn't stop this — the attacker has the post-MFA token. Tools like **Evilginx** and **Tycoon** automate adversary-in-the-middle phishing at scale.
## What Microsoft 365 offers to defend
Several Microsoft features layer together for defence:
### Token Protection (formerly token binding)
A **Conditional Access** capability (currently in public preview / GA progressively for various workloads) that **binds tokens to the specific device** they were issued for. A stolen token replayed from a different device fails because the token's cryptographic binding doesn't match.
When fully rolled out, this is the most direct mitigation — tokens become non-portable.
### Continuous Access Evaluation (CAE)
When risk signals indicate a compromise — anomalous sign-in location, identity protection alert — CAE revokes active tokens in near real time, cutting short an attacker's session even if they grabbed the token.
### Phishing-resistant authentication
**FIDO2 keys**, **passkeys**, and **Windows Hello for Business** are **phishing-resistant**: the cryptographic challenge-response can't be relayed through an adversary-in-the-middle proxy. If the user has phishing-resistant authentication required, the AitM attack fails at the sign-in step.
### Microsoft Defender XDR detection
Defender XDR has detections specifically for token replay anomalies — same token used from very different geographic locations, sudden token use from an unusual user agent. Triggers an alert and (with Identity Protection) can revoke the session.
### Identity Protection user risk
A user with confirmed compromised credentials is **forced to reset password and reauthenticate**, invalidating active tokens.
### Conditional Access for risky sessions
Sessions evaluated as high-risk get either blocked or forced to re-authenticate, even mid-session.
## What a robust defence looks like
For a Microsoft 365 tenant in 2026:
- **Phishing-resistant MFA** (FIDO2 / passkeys / Windows Hello) for all privileged users and increasingly all users.
- **Conditional Access** policies requiring compliant device for sensitive workloads.
- **Token Protection** enabled where available.
- **CAE** enabled.
- **Defender XDR** monitoring with token-replay detection.
- **Identity Protection** with risky-user policies.
- **User awareness training** — even phishing-resistant tenants benefit from users being suspicious of unexpected sign-in prompts.
## What still leaks
- **Cookie theft from compromised devices** — if an attacker has malware on the user's device, they can copy tokens / cookies directly without an AitM proxy. The mitigation is device-side: Defender for Endpoint, ASR rules, tamper protection.
- **OAuth consent attacks** — attackers convince users to grant a malicious app Graph permissions. Mitigation: app consent policies restricting user consent to risky scopes.
Token theft has changed the cost-benefit of investing in phishing-resistant authentication. For tenants that haven't pushed FIDO2 / passkeys broadly yet, this is the year.
## Frequently asked questions
**What is token theft in Microsoft 365?**
Stealing a valid session or refresh token from a device — via malware, a malicious browser extension, or an adversary-in-the-middle phishing proxy — and replaying it from the attacker's machine. Because the token already satisfied MFA, MFA does not stop the replay.
**What does Conditional Access token protection do?**
Token protection binds the refresh token cryptographically to the device it was issued on, so a token stolen and replayed elsewhere is rejected. It currently covers Windows devices with Entra join or hybrid join and a subset of apps and services; check the current support list before relying on it.
**How do I defend against token theft without token protection?**
Phishing-resistant MFA to stop adversary-in-the-middle proxies from working at all, compliant-device requirements so a token cannot be minted on an unmanaged machine, short sign-in frequency for sensitive apps, Continuous Access Evaluation, and Identity Protection risk policies that spot the anomalous session.
---
# Exchange transport rule examples
URL: https://www.solvingmicrosoft365.com/guides/transport-rule-examples
Category: Exchange & Outlook
Published: 2026-05-01
> Real-world transport rule patterns — external-sender warnings, encryption triggers, blocking, and compliance scenarios.
**Exchange transport rules** (mail flow rules) act on every message passing through Microsoft 365 — incoming, outgoing, internal. They're a powerful admin tool but also easy to misuse. Looking at real-world examples grounds the concept.
## External-sender warning
Probably the most common transport rule — prepend a warning to incoming external emails:
**Condition**: sender is outside the organisation, AND recipient is inside.
**Action**: prepend the message body with HTML:
```html
⚠️ External Email: This message originated from outside the organisation.
Don't click links or open attachments unless you trust the sender.
```
Helps users recognise suspicious phishing emails that imitate internal communications. Minor visual cost; meaningful security uplift.
## Auto-encrypt for sensitive content
Detect sensitive content and apply **Office 365 Message Encryption (OME)** automatically:
**Condition**: outbound message contains **Sensitive Information Type** "Credit Card Number" with confidence >= 75% AND count >= 3.
**Action**: apply **Encrypt-Only** OME template.
Result: an employee sends an email with credit card data to an external recipient; Microsoft 365 wraps it in OME automatically; recipient opens in the secure portal.
## Block specific senders
Block messages from a specific external domain or sender:
**Condition**: sender domain is `spam-domain.com`.
**Action**: delete the message without notifying anyone (or, more politely, reject with a custom rejection message).
Better than maintaining a manual block list per user; centralised and audited.
## Append legal disclaimer
The classic legal-compliance use case:
**Condition**: message is sent outside the organisation.
**Action**: append HTML disclaimer with required regulatory language and corporate contact info.
Used widely in financial services, legal firms, healthcare. Often the only transport rule on a tenant.
## Journal selected senders for compliance
For specific user populations subject to regulatory recording (traders, brokers, advisors):
**Condition**: sender is in security group "Compliance Recording".
**Action**: BCC to compliance journaling mailbox `journal@yourcompany.com`.
Preserves a complete copy of regulated users' email independent of mailbox actions. Pair with third-party journaling archive.
## Restrict large attachments
**Condition**: any attachment is greater than 25 MB.
**Action**: reject with custom rejection message: "Large attachments must use OneDrive / SharePoint sharing links rather than email attachments. Please upload to OneDrive and share a link instead."
Reduces email storage growth and forces better collaboration patterns.
## Honeyspot for compromised accounts
A more advanced pattern — detect impossible internal patterns:
**Condition**: an outbound message has both an internal `From` address and an external `Reply-To` header that doesn't match (a common BEC indicator).
**Action**: alert administrators and put the message in quarantine.
Catches a class of compromised-account behaviour.
## Operational considerations
- **Order matters** — rules evaluate top to bottom; the first match (per category) usually wins.
- **Test in audit mode first** — every rule has audit mode that logs without acting.
- **Don't over-rely on rules** for security — they're brittle and add latency.
- **Document each rule** with purpose and owner — undocumented rules outlive their usefulness.
- **Monitor rule processing time** — slow rules slow all mail flow.
- **Sensitive Information Types** in conditions are limited — they don't have the same precision as full DLP policies. For complex content-based actions, use **Purview DLP** instead of transport rules.
For tenants with significant compliance or security requirements, transport rules are an important tool. Used surgically; never abused.
---
# Universal Print overview
URL: https://www.solvingmicrosoft365.com/guides/universal-print-overview
Category: Microsoft Intune (Devices)
Published: 2026-05-01
> Microsoft's cloud printing service for Microsoft 365 — what it does, how to deploy it, and the limits.
**Universal Print** is Microsoft's **cloud printing service** for Microsoft 365 — print from any device to any registered printer without on-premises print servers. It's how Microsoft 365-native organisations get rid of the legacy print-server-and-driver-deployment patterns that have plagued IT for decades.
## How Universal Print works
Universal Print registers printers in your Microsoft 365 tenant. When a user prints:
1. The user picks a registered printer in the standard Windows print dialog (or the print dialog of any Universal-Print-aware app on macOS, iOS, etc.).
2. The application sends the print job to Universal Print over HTTPS.
3. Universal Print stores the job temporarily.
4. The printer (or a connector representing it) fetches the job from Universal Print.
5. The printer prints.
No drivers are deployed to the user's device beyond the built-in Windows class drivers. Authentication uses Entra ID.
## Printer types
Universal Print supports two printer categories:
### Native Universal Print printers
Newer printers from HP, Lexmark, Canon, Xerox, Sharp, Epson, and other Microsoft partners that include **Universal Print support in their firmware**. These printers register with the service directly — no proxy software needed. Microsoft maintains a compatibility list of supported models.
For new printer purchases, **native Universal Print printers are strongly preferred** — no on-prem infrastructure at all.
### Universal Print connector
For **legacy printers** that don't support Universal Print natively, the **Universal Print connector** is a small Windows service installed on a server in your network. The connector represents printers to Universal Print and translates protocols. One connector server can publish many printers.
The connector is lightweight compared to a traditional print server — it doesn't host drivers or queues; it forwards jobs. It does need to be online for printing to work.
## Configuration
In the Microsoft 365 admin center under **Printers**:
1. **Register printers** — for native printers, register via the printer's setup; for connector-managed printers, add via the connector software.
2. **Assign users / groups** to printers using Entra ID groups.
3. **Configure printer defaults** — paper size, duplex, colour.
4. **Monitor usage** in Universal Print reports.
Users see their assigned printers automatically in the Windows print dialog when signed in with their Entra ID account.
## Hybrid printer publishing
For organisations on the journey, **hybrid printer publishing** lets you import existing **Windows Print Server** queues into Universal Print without a full forklift migration. Users can keep printing the way they always did from on-prem-joined devices while new Entra-joined devices use the Universal Print path.
## Limits and gotchas
- **Job size limit** — large jobs (multi-GB PDFs) can be slow or rejected.
- **Connector requires Windows** — no native Mac or Linux connector option.
- **Some advanced features** (booklet printing, specific finishing options) depend on the printer's native support; Universal Print itself is print-job neutral.
- **Print quotas** are per-tenant — each Microsoft 365 plan includes a monthly print job allotment; large estates need top-ups.
## Licensing
Universal Print is licensed by **print jobs per month**. Each Microsoft 365 E3 / E5 / Business Premium licence includes a monthly print job allowance (currently several hundred per user). Additional volume can be purchased.
For Microsoft 365-native organisations with significant Windows fleets, Universal Print removes a chunk of operational burden. The transition from print servers to Universal Print is one of the bigger quiet wins available in a Microsoft 365 estate.
---
# Windows 365 vs Azure Virtual Desktop
URL: https://www.solvingmicrosoft365.com/guides/windows-365-vs-azure-virtual-desktop
Category: Microsoft Intune (Devices)
Published: 2026-05-01
> Microsoft's two cloud-hosted Windows products — what each is for and how to choose.
Microsoft offers two products for hosting Windows desktops and apps in the cloud: **Windows 365** (Cloud PC) and **Azure Virtual Desktop (AVD)**. They use the same underlying technology and they often confuse customers because of the overlap, but they solve different problems with different cost models.
## Windows 365 in one paragraph
**Windows 365 Cloud PC** provisions a **fixed Windows 11 desktop per user** in Microsoft's datacentres. Each user gets a cloud PC sized by **vCPU / RAM / storage SKU** — 2 vCPU / 4 GB / 128 GB at the entry level, up to 16 vCPU / 64 GB / 1 TB at the top. The cost is **per user per month, fixed**, regardless of how much they use it. Two flavours: **Enterprise** (Intune-managed, Entra-joined, integrated with your Microsoft 365 estate) and **Business** (self-service SMB tier).
## Azure Virtual Desktop in one paragraph
**Azure Virtual Desktop** is the consumption-based VDI service in Azure. You design **host pools** of Azure VMs, deploy them with the size and quantity you want, and users connect to **session hosts** within the pool. Costs are **consumption-based** — Azure compute, storage, and licensing charges per hour the VMs run. AVD supports **multi-session Windows 11 / Windows 10** (multiple users on one VM, sharing resources) and **single-session**, plus **RemoteApp** for streaming individual applications rather than full desktops.
## Where they're the same
Both products:
- Stream Windows from Azure datacentres to any modern client (browser, dedicated app, Mac, iOS, Android).
- Use the **Windows desktop session host** technology and the **FSLogix** user-profile container.
- Support **Entra ID join** and **Intune management**.
- Integrate with Microsoft 365 for productivity workloads.
- Support Microsoft 365 Apps in shared / multi-session environments.
## Where they're different
| Aspect | Windows 365 | AVD |
| --- | --- | --- |
| Per user | One dedicated cloud PC | Shared session hosts |
| Sizing | Fixed SKUs | Custom VM sizes |
| Cost model | Per-user fixed price | Consumption (Azure resources) |
| Setup complexity | Self-service / simple | Significant Azure configuration |
| Multi-session | No (single-user) | Yes |
| RemoteApp | No | Yes |
| Custom images | Limited | Full Azure imaging |
| User personalisation | Always there | FSLogix profile, redirected at sign-in |
| Best for | Persistent desktops, predictable users | Variable populations, RemoteApp, customisation |
## When to pick Windows 365
- Knowledge workers who need a dedicated, persistent Windows desktop in the cloud.
- Predictable user counts and usage patterns.
- IT teams that want simplicity over flexibility.
- Frontline workers using Cloud PC from shared physical thin clients.
- Contractor / partner access where you want to give a persistent PC without shipping hardware.
## When to pick AVD
- Mixed-population scenarios with variable user counts.
- Heavy multi-session Windows workloads where shared VMs are economical.
- Need for **RemoteApp** — stream individual apps rather than full desktops.
- Custom golden images, custom infrastructure controls.
- Existing AVD deployment to extend.
- Cost predictability isn't a hard requirement.
## Running both
Many organisations run **both** — Windows 365 for the bulk of knowledge workers wanting a dedicated cloud PC; AVD for specialist scenarios (engineering workloads, RemoteApp, multi-session). They share much of the underlying tooling, so the operational overhead of running both isn't double.
For most Microsoft 365 customers, **start with Windows 365** unless you have specific needs that push you to AVD. The fixed pricing and simpler operating model wins for typical use cases.
## Frequently asked questions
**Which is cheaper, Windows 365 or AVD?**
For full-time knowledge workers with predictable use, Windows 365's fixed per-user price is usually comparable or cheaper once the operational effort of AVD is counted. For part-time, shift, or bursty use, AVD's multi-session and pay-as-you-go compute is cheaper — often much cheaper — if you scale it down when idle.
**Can I run both Windows 365 and AVD?**
Yes, and many organisations do: Windows 365 for developers and users who need a persistent personal desktop, AVD for call centres, contractors, and multi-session task workers. Both are managed through Intune and accessed from the Windows App.
**Does AVD need more skills than Windows 365?**
Yes. AVD involves Azure networking, host pool design, image management, FSLogix profiles, scaling plans, and cost monitoring. Windows 365 needs Intune and licensing knowledge; the infrastructure is Microsoft's problem.
---
# Windows Autopatch
URL: https://www.solvingmicrosoft365.com/guides/windows-autopatch
Category: Microsoft Intune (Devices)
Published: 2026-05-01
> Microsoft's managed Windows update service — what it does, where it differs from Windows Update for Business, and when to use it.
**Windows Autopatch** is Microsoft's **managed Windows update service** for enterprise customers. It takes ownership of patching Windows and Microsoft 365 Apps across the fleet — deploying updates in **rings**, monitoring for issues, rolling back when needed, and providing reporting suitable for executive consumption.
## What Autopatch does
Once a device is enrolled in Autopatch (via Intune, with appropriate Microsoft 365 licensing):
- **Windows quality updates** — monthly Patch Tuesday cumulative updates.
- **Windows feature updates** — annual Windows feature releases.
- **Driver and firmware updates** for supported OEM devices.
- **Microsoft 365 Apps updates** — the installable Office apps.
- **Microsoft Edge updates**.
- **Teams updates**.
For each, Microsoft deploys to your fleet in **deployment rings** (Test, First, Fast, Broad) with delays between them. Microsoft also watches **telemetry across the entire Autopatch customer base**, so when an update is causing problems for any customer, it pauses for everyone.
## Deployment rings
The four default rings:
- **Test** (1% of devices) — early validation.
- **First** (9%) — broader pilot.
- **Fast** (15%) — internal IT and tech-friendly users.
- **Broad** (75%) — general population.
Custom rings can be defined for organisations needing more granularity. Users move between rings via Entra ID group membership.
## How it differs from Windows Update for Business
**Windows Update for Business** (the underlying Microsoft service) configures Windows to receive updates from Microsoft. Autopatch is **operational management on top of WUfB**:
- Autopatch defines and operates the deployment rings.
- Autopatch monitors success rates and rolls back automatically when needed.
- Autopatch provides reporting suitable for leadership.
- Autopatch coordinates with Microsoft's per-customer telemetry on issues.
- Autopatch handles communication of disruptions to admins.
Without Autopatch, you do all of this yourself in Intune. With Autopatch, Microsoft does it.
## Service-level objectives
Microsoft commits to SLOs for Autopatch:
- Devices reach **N+1 quality updates within X days**.
- Feature updates roll out within published windows.
- Issues caught in earlier rings prevent broader rollout.
These SLOs are measured per tenant and surfaced in the Autopatch dashboard.
## Tenant readiness
To use Autopatch, your tenant needs:
- **Microsoft 365 E3 / E5** or specific other licensing (check current eligibility).
- **Intune** managing the devices.
- **Entra ID-joined or hybrid-joined** Windows 10 / 11 devices on supported editions.
- **Connectivity** to Microsoft Update endpoints (per the network connectivity principles).
A readiness check tool validates these prerequisites before onboarding.
## When Autopatch is right
- **Large fleets** where managing update rings manually is operationally expensive.
- **Organisations wanting Microsoft to take operational responsibility** for patching health.
- **Tenants with limited dedicated client-engineering staff** — Autopatch effectively replaces a managed-update operations function.
- **Modern cloud-managed devices** — Entra-joined, Intune-managed, with reasonable connectivity.
## When it's not
- **Devices not yet Intune-managed** — Autopatch requires Intune.
- **Heavy customisation requirements** — if you need bespoke patching cadences for specific user populations beyond the standard rings.
- **Air-gapped or specialised environments** that can't receive updates directly from Microsoft.
For most Microsoft 365 enterprise customers running modern Windows endpoints, Autopatch is increasingly the default. It removes a chunk of the IT operational backlog at no additional cost.
## Frequently asked questions
**What is Windows Autopatch?**
A Microsoft-managed service that plans and rolls out Windows quality and feature updates, Microsoft 365 Apps, Edge, and Teams updates across rings (test, first, fast, broad) with automatic pausing and rollback on issues, using Intune policies it creates and manages in your tenant.
**Which licences include Windows Autopatch?**
Windows Enterprise E3/E5 and Microsoft 365 E3/E5, F3, and Business Premium (Business Premium gained Autopatch features in 2024). Devices must be Intune-managed and Entra joined or hybrid joined.
**How is Autopatch different from Windows Update for Business?**
Windows Update for Business is a set of policies you configure and operate yourself. Autopatch operates them for you — ring design, deferrals, deadlines, pausing a release when telemetry shows problems — and reports on compliance. Autopatch groups let you customise rings while keeping the managed service.
---
# Working effectively with your Microsoft account team
URL: https://www.solvingmicrosoft365.com/guides/working-with-microsoft-account-team
Category: Microsoft 365 essentials
Published: 2026-05-01
> How to engage Microsoft's account team — CSAs, CSPs, account executives, and the broader Microsoft ecosystem.
For organisations with meaningful Microsoft 365 spend, **the Microsoft account team** is a real asset — and one many customers under-use. Understanding the roles, what they can do, and how to engage effectively unlocks significant value beyond just licence purchasing.
The account team is the commercial counterpart to [Microsoft Support](/guides/working-with-microsoft-support) and the route into [FastTrack](/guides/microsoft-fasttrack); come to the conversation with the [plans and pricing](/guides/microsoft-365-plans-and-pricing) picture, the [licensing models](/guides/microsoft-365-licensing-models-explained), and a [cost optimisation](/guides/microsoft-365-cost-optimisation) list of your own.
## The roles
For enterprise customers, the Microsoft account team typically includes:
### Account Executive (AE)
The commercial owner — responsible for the customer relationship, contract negotiations, EA / MCA renewals, strategic conversations. The right point of contact for:
- **Renewal planning** — start 12+ months before EA expires.
- **Strategic agreements** — discounts, special terms, alliance investment.
- **Escalations** — when business-impacting issues need senior attention.
- **Microsoft co-marketing** opportunities.
### Cloud Solution Architect (CSA) / Technical Specialist
The technical owner — deep specialist in specific Microsoft 365 / Azure capabilities. Often multiple CSAs cover different domains (security, Power Platform, data, productivity). The right contact for:
- **Architecture guidance** on complex deployments.
- **Microsoft roadmap** information beyond what's public.
- **Best-practice recommendations** for your scenario.
- **Connecting you to Microsoft engineering** when needed.
### Customer Success Manager (CSM) / Account Manager
The day-to-day relationship owner — ensures the customer is getting value from existing licences. Right contact for:
- **Adoption support** — engage Microsoft enablement resources.
- **Quarterly business reviews** (QBRs) — formal cadence.
- **FastTrack engagement** if eligible.
- **Training credits** — many customers have unused training entitlements.
### Premier / Unified Support
For organisations with **Unified Support** contracts, dedicated:
- **Technical Account Manager (TAM)** — deep technical relationship, escalation point.
- **Support engineers** with knowledge of your environment.
- **Proactive services** — Microsoft engineers performing health checks, advisory.
## What the account team can do
Beyond licensing transactions:
### Roadmap previews
Specific upcoming features, sometimes months ahead of public roadmap announcements. Useful for planning.
### Private previews
Access to **private previews** of unreleased features. Sign NDAs, participate in feedback. Strategic for organisations wanting early access.
### Microsoft expertise
Access to Microsoft engineers, product managers, technical specialists for specific deep-dive sessions. Not unlimited but substantial.
### Investment funds
For large enterprise customers, Microsoft sometimes offers:
- **Adoption funds** for training and change management.
- **Proof-of-concept funding** for new capabilities.
- **FastTrack credits** for deployment assistance.
- **Architecture workshops** Microsoft-led.
Ask about these explicitly; they don't appear in catalogues.
### Microsoft Internal Use Rights
For Microsoft Partners (CSPs, consultants, ISVs), **Internal Use Rights** licences for testing and development. Different programme; check eligibility.
## How to engage effectively
### Be a regular, not a stranger
The customers who get the most from Microsoft account teams have **regular cadence**:
- **Quarterly business reviews** with the AE and CSM.
- **Monthly technical syncs** with CSAs on specific topics.
- **Always-on Teams chat** or email for ad-hoc questions.
Customers who only call at renewal are remembered as transactional; customers in regular conversation get strategic engagement.
### Be specific about needs
Vague "we want to do better at Microsoft 365" doesn't generate help. Specific "we're planning a Copilot rollout for 3,000 users and want Microsoft's input on prerequisite work" generates real engagement.
### Bring problems and opportunities
Microsoft account teams want to know about:
- **Business challenges** that Microsoft can help with.
- **Microsoft product issues** affecting you.
- **Competitive scenarios** — what alternatives you're considering.
- **Growth opportunities** — projects requiring more Microsoft licensing or capability.
Don't only bring complaints; bring opportunities for them to add value.
### Use the right channel
- **Strategic / commercial** → AE.
- **Technical guidance** → CSA / Technical Specialist.
- **Daily operations / FastTrack** → CSM / TAM.
- **Active support cases** → Support engineers directly.
- **Escalation** → Up the chain via AE.
Confusion produces slow responses.
### Be diplomatic
The Microsoft account team works for Microsoft, not for you. They're aligned with your success — but also with Microsoft's revenue. Frame conversations around mutual benefit; understand their incentives.
## What the account team won't do
- **Replace your internal IT** — they advise; you operate.
- **Make tactical decisions** for you.
- **Provide unlimited free consulting** — there are limits.
- **Promise specific roadmap dates** under NDA without good reason.
- **Disadvantage Microsoft's commercial position** in negotiations.
## Renewals specifically
EA / MCA renewals are the **biggest single account-team interaction**. Treat them deliberately:
- **Start 12–18 months before expiration**.
- **Engage actively** — don't wait for Microsoft to bring proposals.
- **Bring data** — actual usage, growth plans, alternatives considered.
- **Negotiate the components** — pricing, terms, value-add commitments.
- **Document commitments** — Microsoft adoption-fund commitments, training credits, services credits should be in writing.
For organisations with significant Microsoft spend, getting renewals right is one of the highest-leverage commercial activities IT does.
## Bottom line
For Microsoft 365 customers spending more than a few hundred thousand annually, the account team is a real asset. Engage proactively; build relationships; use their expertise. Customers who do produce dramatically better outcomes than customers who view the account team as just the people who sell renewals.
---
# Working effectively with Microsoft Support
URL: https://www.solvingmicrosoft365.com/guides/working-with-microsoft-support
Category: Microsoft 365 essentials
Published: 2026-05-01
> How to engage Microsoft Support for Microsoft 365 issues — preparing requests, severity, escalation, and what to expect.
For Microsoft 365 issues that exceed your team's investigation capacity — service-side problems, complex configuration questions, suspected service incidents — **Microsoft Support** is the escalation path. Engaging effectively gets faster resolution; engaging poorly creates frustration on both sides. A few patterns help.
Before opening a case, check [service health](/guides/microsoft-365-service-health-and-message-center); for incidents the [incident response runbook](/guides/microsoft-365-incident-response) lists what Microsoft can and cannot do, for commercial escalations see [working with your account team](/guides/working-with-microsoft-account-team), and for onboarding help [FastTrack](/guides/microsoft-fasttrack).
## When to engage Microsoft Support
Engage when:
- **Suspected Microsoft service issue** — and Service Health isn't yet showing an incident.
- **Configuration-related issue** — you've configured what you think is right, behaviour doesn't match.
- **Microsoft tooling questions** — specific feature not behaving as documented.
- **Performance issue** — user-impacting, ruled out client-side causes.
- **License-related issue** — billing, provisioning, or entitlement issues.
Don't engage for:
- **User training questions** — internal training.
- **Issues you haven't first investigated** — Microsoft will ask what you've already tried.
- **Issues better-suited for community** — `learn.microsoft.com` Q&A or tech community for "how-to" questions.
## How to engage
Microsoft 365 tickets can be created via:
- **Microsoft 365 admin centre → Support → New service request** — the standard path for most issues.
- **Premier / Unified Support portal** — for organisations with premium support contracts.
- **Microsoft FastTrack** — for deployment-related issues (eligible organisations).
- **Microsoft Partner Center** — for CSP partner-managed tenants (partner opens the ticket).
## Preparing a good support request
The faster Microsoft can understand your issue, the faster they help. Prepare:
- **Concise description** — what you're trying to do, what's happening, what should happen.
- **Steps to reproduce** — exact actions that trigger the issue.
- **Time of occurrence** — specific timestamps with timezone.
- **Affected users** — specific UPNs (not "many users").
- **Error messages** — exact text, error codes, screenshots.
- **What you've tried** — eliminates rabbit holes Microsoft would otherwise check.
- **Service Health status** — confirm no known incident applies.
- **Audit log evidence** if relevant.
- **Network info** — for performance issues.
Vague requests like "Email isn't working" produce slow responses. Specific requests like "User john@company.com gets 5.7.708 error on outbound mail to gmail.com addresses since 14:00 UTC; SPF passes; DMARC passes; Defender shows no anomaly" get fast meaningful responses.
## Severity levels
Microsoft Support classifies severity:
- **Severity A (critical)** — complete service unavailability impacting many users; mission-critical service blocked. Microsoft commits to fastest response (typically within 1 hour for Unified Support).
- **Severity B (high)** — significant impact on production but with workarounds. Response within several hours.
- **Severity C (moderate)** — limited impact, not production-stopping. Response within a business day or two.
Match the severity to the actual impact. Inflating severity for a minor issue wastes Microsoft's time and yours; deflating severity for a major issue means slow response.
## Escalation
If progress is slow:
- **Ask for case escalation** to a senior engineer.
- **Engage your Microsoft account team** (CSA, account executive) for high-impact issues.
- **For Unified / Premier customers**, the **Technical Account Manager (TAM)** can escalate internally.
- **Twitter (X)** sometimes gets attention for visible incidents but isn't a substitute for the formal channel.
## Information you may be asked
Be ready to provide:
- **Tenant ID** — the GUID identifying your tenant.
- **Microsoft 365 user UPNs** affected.
- **Test sign-in details** if reproducibility requires.
- **Screen recordings or screenshots**.
- **Defender XDR / Entra ID logs** if the issue is identity- or security-related.
- **Network connectivity test results** if performance-related.
- **Customer Lockbox approval** — for issues requiring Microsoft engineer to access your tenant content directly (Microsoft 365 E5).
## What to expect
- **Initial response** — Microsoft confirms ticket received, asks for additional info.
- **Investigation phase** — Microsoft engineer works the issue, may ask for screen-share or logs.
- **Update cadence** — varies by severity. For sev A, hourly updates; sev C, daily or longer.
- **Resolution proposal** — Microsoft suggests a fix or workaround.
- **Verification** — you confirm the issue is resolved.
- **Closure** — case closes; survey may be sent.
## After resolution
- **Document the fix** in your internal runbook.
- **Capture lessons** — what to do differently if this recurs.
- **Provide feedback** in the post-case survey — Microsoft does track this.
For organisations with serious Microsoft 365 dependence, the relationship with Microsoft Support is a real operational asset. Treat it deliberately — well-prepared cases get fast responses; poorly-prepared cases drag on. The discipline of "describe specifically, demonstrate clearly" pays back continuously.
---
# Zero trust in Microsoft 365
URL: https://www.solvingmicrosoft365.com/guides/zero-trust-in-microsoft-365
Category: Microsoft Defender (Security)
Published: 2026-05-01
> What zero trust actually means in a Microsoft 365 context — and the concrete controls that get you there.
"Zero trust" is one of the most overused phrases in security. In a Microsoft 365 context it has a specific, useful meaning: every access decision is **made at request time** based on user, device, app, and risk signals, and **no implicit trust** is granted by being inside the corporate network.
## The three principles
Microsoft frames zero trust as three principles:
1. **Verify explicitly** — every access decision uses all available signals (identity, device, location, risk, app, data sensitivity).
2. **Use least privilege** — just-in-time, just-enough access; PIM and entitlement management.
3. **Assume breach** — minimise blast radius, segment, encrypt, monitor.
These principles are intentionally generic. The interesting question is what they look like as **specific controls in Microsoft 365**.
## Zero trust in practice
### Identity
- **MFA** enforced everywhere.
- **Conditional Access** as the policy decision point for every Microsoft 365 sign-in.
- **Passwordless** for as many users as possible (Microsoft Authenticator, Windows Hello, FIDO2).
- **PIM** for privileged roles — no standing Global Admins.
- **Identity Protection** policies for risky users / sign-ins.
### Devices
- **Intune** managing every endpoint, with **compliance policies** feeding Conditional Access.
- **Defender for Endpoint** with EDR, ASR rules, tamper protection.
- **App protection policies** for personal devices (MAM-WE).
### Data
- **Sensitivity labels** classifying data at creation, with encryption attached.
- **DLP policies** preventing exfiltration through Exchange, Teams, SharePoint, OneDrive, and endpoints.
- **Retention policies** preserving and disposing data on a clear schedule.
- **SharePoint Advanced Management** restricting high-risk site access.
### Apps
- **Defender for Cloud Apps** monitoring SaaS posture.
- **Conditional Access App Control** for session-level controls on SaaS.
- **App consent policies** limiting which third-party apps users can grant Graph permissions to.
### Network
- **Network protection** in Defender for Endpoint blocking malicious destinations.
- **Defender for Cloud Apps** identifying shadow IT via firewall/proxy logs.
- **Microsoft Entra Private Access** and **Internet Access** (Microsoft's SSE / SASE offerings) replacing legacy VPN and adding identity-aware network controls.
## What zero trust replaces
Zero trust replaces the **network-as-trust-boundary** model: where being on the corporate VPN gave broad access to internal apps. In a zero-trust model, every app is published through Entra ID with Conditional Access — including legacy on-premises web apps via **Entra Application Proxy** or **Entra Private Access**.
## Where to start
If you're at the beginning: get to the Tier 1 baseline in the [Microsoft 365 security baselines](/guides/microsoft-365-security-baselines) guide. That's already 80% of practical zero trust for most organisations. The rest is iterative refinement, not a separate project.
## Measuring progress without a single "zero trust score"
Unlike Secure Score, there's no single built-in number for "how zero trust are we" — zero trust maturity is better tracked as a small set of concrete, checkable facts across the five areas above: what percentage of sign-ins are covered by a Conditional Access policy (ideally close to 100%, with named, monitored exceptions only for break-glass accounts); what percentage of admin roles are standing-active versus PIM-eligible; what percentage of managed devices are enrolled and compliance-evaluated versus unmanaged; and what percentage of the tenant's most sensitive data locations carry a sensitivity label. Tracking these four numbers quarterly gives a genuinely actionable maturity signal without needing a vendor's proprietary scoring model layered on top.
## A common misreading of "assume breach"
"Assume breach" is sometimes read as fatalism — as if the model concedes that a breach is inevitable and not worth preventing. The more accurate reading is architectural: design every control (segmentation via sensitivity labels and DLP, Continuous Access Evaluation shortening a stolen token's useful life, PIM limiting how much any single compromised account can do) so that *if* a breach occurs despite the preventive controls, its blast radius and duration are both minimised. Preventive controls (MFA, Conditional Access) and contain-the-blast-radius controls (segmentation, monitoring, short-lived privilege) are complementary, not sequential — a mature zero-trust posture invests in both simultaneously rather than treating detection-and-containment as a fallback only worth building once prevention is somehow "finished."
## Frequently asked questions
**What does zero trust mean in Microsoft 365?**
Verify explicitly, use least privilege, assume breach — implemented as Conditional Access on every sign-in (identity, device, app, risk), PIM and access reviews for privilege, Intune compliance for devices, and Defender and Purview to detect and contain. It is a set of configured controls, not a product.
**Where should I start with zero trust?**
Identity: MFA for everyone (phishing-resistant for admins), block legacy authentication, PIM for admin roles. Then devices: Intune enrolment and compliant-device Conditional Access. Then data: sensitivity labels and DLP. Microsoft's zero-trust deployment guides follow the same order.
**Is Microsoft 365 E5 required for zero trust?**
No. Business Premium and E3 cover the core (Conditional Access, Intune, MFA, basic Purview). E5 adds risk-based policies, PIM, Defender XDR, and Purview premium, which deepen zero trust but are not prerequisites.