How to Sync Microsoft 365 Message Center to SharePoint Lists

If you manage Microsoft 365 for a large organisation, you know the Message Center problem. Hundreds of posts a year. No concept of who owns what. Metadata is buried in task bodies. Planner helps up to a point, but it's not enough. NORC hit all three and spent two years trying to make Planner work before building their way out.

Why Syncing Microsoft 365 Message Center to Planner Isn't Enough 

How NORC Built a Microsoft 365 Message Center to SharePoint List Integration: The Full Process

What follows is a phase-by-phase account of how NORC designed and built their SharePoint list, connected it to Message Center via the Microsoft Graph API, and automated assignment and notifications with Power Automate. Each phase covers the decisions made, the design rationale, and the non-obvious details that determined whether it worked.

Phase 1: Requirements Before Any Build

John's first move was documentation, not building.

'It's one thing to just make a SharePoint list. It's another thing to put all this Power Automate behind it and make it work. We wanted to make sure that everybody signed off before we started.' - John Burkholder

The requirements document covered which fields to pull from Message Center, which custom fields to add, a service owner mapping table (workload → person), the follow-up taxonomy, and the notification and assignment rules. Getting stakeholder sign-off upfront is what made the two-week build timeline possible. By the time John touched SharePoint, the decisions were already made.

Phase 2: The SharePoint List Design

The SharePoint list is the centrepiece of the solution, surfaced inside Microsoft Teams as a tab. John designed it to capture two categories of data: everything that comes down directly from Message Center via the Graph API, and the custom fields NORC needed to manage the work.

From Message Center, the list pulls: Title, Body (rich text, with images inline), Workload/Service, Tags, Published Date, Last Modified Date, Message Center ID, and the Major Change flag.

NORC added their own fields on top: Assigned To (one or more service owners per workload), a structured Follow-Up taxonomy, Task Status, Decision Status (Deferred / Disabled / Enabled / Ignored / Investigating), Decision Date and Rationale for audit purposes, an Internal Alternative field for cases where a Copilot feature has an in-house substitute, and a Stakeholders field for people who need visibility but aren't the assigned owner.

The Follow-Up Taxonomy

One of the most considered design decisions was the follow-up taxonomy.

Every Message Center post gets tagged with one of five options:

1. Needs Internal Discussion (handled within the workload team)

2. Needs Group Discussion (cross-team impact, reviewed every Tuesday)

3. Communicate to End Users (engage the IT comms team)

4. Service Desk Awareness (alert the help desk)

5. Turn into Project (stands up a formal project with PM and budget)

This gives the team a consistent, searchable vocabulary across hundreds of posts and drives the weekly review cadence.

Why the body field is append-only

Microsoft updates approximately 60% of Message Center items after publication, changing dates, adding documentation, changing wording. Some posts get updated 10 to 12 times.

John configured the body field as an append-only field in SharePoint, so every Microsoft update is appended with a timestamp rather than overwriting the previous version. You get a complete version history for every post.

Planner cannot do this.

Rich text for inline images

John configured the body field as rich text, which means images from Message Center posts render inline — exactly as Microsoft intended — rather than as attachments. Links are clickable and preserved. Each list item also carries a direct link back to the original Message Center post in the Admin Center.

Phase 3: Connecting to the Microsoft Graph API

Before building the import workflow, John used Microsoft Graph Explorer to inspect the API response.

Signing in with an admin account and querying the admin/serviceAnnouncement/messages endpoint shows every available field and its data type — the essential preparation step before mapping anything to SharePoint columns. The Graph API requires app-level permissions via client credentials; a standard user login won't have access to this endpoint.

Phase 4: Workflow 1 - The Message Center Import

The import workflow runs on a timer and pulls all messages from Message Center into the SharePoint list. It authenticates via an HTTP action using client credentials, creating an app-level token tied to the tenant.

One non-obvious requirement: the Graph API returns a maximum of 100 items per call by default. John enabled pagination in the Power Automate HTTP action with a threshold of 1,000, which causes the flow to automatically paginate through the full message list. Without this, you silently miss updates on any items beyond the first 100.

Once all messages are retrieved, the flow parses the JSON into variables and compares against a lightweight MC Lookup view in SharePoint — containing only Message ID and Last Modified Date, keeping the comparison fast. For each message: if the Last Modified Date has changed, the SharePoint item is updated with the new content appended to the body field; if it's a new message, a new SharePoint item is created with all fields populated; if nothing has changed, the item is skipped.

Phase 5: Workflow 2 - Assignment and Notifications

This is a deliberate separate workflow that triggers when a new item is created. John keeps it separate from the import flow by design.

"I don't want to break the import process by having the assignment logic go wrong. The import runs no matter what. If I need to fix the assignments, that's a separate problem." - John Burkholder

The assignment workflow checks the Workload/Service field and routes the item to the right service owner via conditional logic — Exchange goes to the Exchange owners, Teams to the Teams owners, and so on across every workload in the organisation. The service owner mapping came directly from the requirements document.

The workflow also checks tags: a Data Privacy tag routes to the security team; Feature Update, Major Update, New Feature, and Retirement tags auto-populate the Stakeholders field.

If a workload has no mapped owner because NORC doesn't use that service, the item is automatically closed. When someone is assigned, they receive a Teams notification.

Phase 6: Transition and Weekly Review Cadence

NORC ran a one-week parallel transition, running the old Planner process alongside the new SharePoint list to validate alignment, before cutting over completely. The process now runs a weekly Tuesday afternoon review meeting covering everything tagged Needs Group Discussion. Items tagged Needs Internal Discussion stay within individual workload teams.

What This Build Really Costs

Two weeks of elapsed time sounds fast, but John came in with deep SharePoint and Power Automate experience, a fully mapped requirements document signed off before a line of flow was written, and the ongoing ownership commitment to keep it running. That combination is not common.

The build itself is only part of the cost. The Graph API pagination quirk, the append-only field decision, the fault isolation between the two workflows, the service owner mapping logic hand-coded for every workload. Each of these is a decision that needs to be made correctly and maintained as the organisation changes. Service owners leave. New workloads appear. Microsoft changes the API. Someone needs to own all of that.

For organisations that have that person, the in-house route is genuinely viable. For everyone else, ChangePilot handles all of it, including the parts that are hardest to maintain.

What's Next for NORC

John shared the roadmap for where they're taking their in-house solution:

• Third-party change tracking - pulling in Azure, desktop apps, and third-party vendors (AvePoint, EndNote) via their own APIs, with Copilot used to normalise non-standard API responses to the list schema

•  Power BI dashboard for reporting across the list

• Copilot integration directly into the list

• ServiceNow integration for NORC's broader enterprise change management process

• Service asset tracking tied to specific projects and changes

Several of these are already available in ChangePilot,  including Power BI reporting, third-party change tracking, and AI-generated summaries.

Frequently Asked Questions

Why is Planner not sufficient for Microsoft 365 Message Center management?

Planner's native Message Center sync buries most metadata - workload, tags, rollout dates, user/admin impact flags — in the task body as unstructured text. You can't filter, report, or route on it. There's also no concept of service owners; every assignment is manual. List views in SharePoint give you the filtered reporting and structured data that Planner doesn't.

What Graph API endpoint do I need to pull Message Center data?

The endpoint is admin/serviceAnnouncement/messages. Use Microsoft Graph Explorer with your admin account to inspect the response schema before building your flow. You'll need app-level permissions via client credentials — your user login won't have access to this endpoint.

How do I handle Microsoft updating Message Center posts after they're published?

Microsoft updates roughly 60% of items — some get updated 10 to 12 times. Configure your body field as append-only in SharePoint. Every update is appended with a timestamp, preserving the full version history. This is something Planner cannot do.

Do images from Message Center come through to SharePoint?

Yes — if you configure the body field as rich text, images render inline exactly as Microsoft intended. Links are also preserved as clickable hyperlinks. The list item also links back to the original Message Center post in the Admin Center.

Why keep the import and assignment workflows separate?

Fault isolation. If the assignment logic has a problem, the import still runs — your list stays current. If both were in one flow, a bug in the assignment conditions would break message ingestion entirely. Keeping them separate means you can fix and redeploy each independently.

How long does it take to build this?

John completed requirements, build, testing, and a one-week parallel transition in two weeks. The key was getting stakeholder sign-off on requirements and the service owner mapping table before touching Power Automate. Building without that upfront alignment would have taken much longer.

What should I do about Message Center posts for services we don't use?

Build an auto-close condition into your assignment workflow. If a workload has no mapped service owner, close the item automatically. This prevents noise from accumulating in your list over time.

Do I need an admin account to connect to the Graph API?

You need app-level permissions via client credentials for the admin/serviceAnnouncement/messages endpoint. A regular user account won't have access. Set up a service principal or app registration with the appropriate Graph API permissions.