Building Custom Copilot Plugins for Microsoft 365

If your project data lives in ten different places across
Microsoft 365, how do you get a single, clear status update
without wasting half your day clicking around? Imagine asking
Copilot, "Where are we on Project Apollo?" and getting one
accurate answer instantly—no spreadsheets, no manual reports.
Today, I’ll show you exactly how to build the plugin that makes
that possible… starting from zero.You’ll see the real API calls,
the manifest that tells Copilot what to do, and how to wire up
secure access. The result? One question in, one answer out—every
time.


Where Project Data Hides in Microsoft 365


Most project managers think they know exactly where their updates
live—until that dreaded Friday afternoon report request lands.
You start pulling together the numbers and suddenly you’re
digging through tools you haven’t opened in weeks. Tasks hiding
in Planner. Milestones buried in a SharePoint list someone swore
they’d keep updated. Conversations in Teams channels that contain
half the context for why a deadline just slipped. It’s all there
somewhere; it’s just not in one place, and it’s definitely not
talking to each other without your help. Within Microsoft 365,
project data scatters itself more than most people expect.
Planner is great for action items—dates, assignments,
checklists—but it doesn’t store client approvals. That’s often
handled in a SharePoint list, maybe with a Power Automate
workflow wrapped around it. Meanwhile, the real discussions about
resource changes or scope shifts are happening inside a Teams
channel, where the chat lives in an entirely different data
store. Each of these tools thrives in its own lane, and none of
them are naturally built to merge their information streams
without extra work. The problem is simple enough to describe, but
painful to live with. Your manager, or maybe your client, doesn’t
ask for a Planner view, a SharePoint table, and a Teams
transcript. They ask for an answer: “How’s the project going?”
But behind that question is a mess of API structures, each with
their own way of representing and delivering data. Planner’s API
wraps data in nested objects you have to unwrap. SharePoint’s
REST endpoints demand list IDs and column names you have to know
ahead of time. And Teams? Threads, replies, reactions—all
formatted differently again. Picture a typical project. The
development tasks are tracked in Planner buckets. Every milestone
approval—design sign-off, budget confirmation—is stored in a
SharePoint list maintained by the PMO. Resource allocation
discussions are in Teams messages, often with key details like
“John can’t join next sprint” buried three replies deep. When a
stakeholder asks for a status update, you’re either exporting
data from three interfaces or manually piecing it together in
Excel. By the time you finish, you can’t be sure all of it is
even current. That’s where the risk kicks in. Manual reporting
isn’t just slow—it raises the chance that outdated or inaccurate
information slips through. Maybe a planner task got marked
complete fifteen minutes ago, but you pulled data an hour
earlier. Or an approval got logged in SharePoint after you’d
already snapshot the list. Inconsistent timestamps, different
refresh behaviors, and mismatched field names mean you’re
spending more time reconciling the sources than analyzing
anything. One thing that surprises a lot of people: even inside
the same Microsoft 365 environment, these services don’t share a
single authentication model or query syntax. Some endpoints work
fine with delegated permissions; others demand application-level
permissions with admin consent. Filter parameters can vary from
OData queries in Graph to CAML-style conditions for certain
SharePoint operations. You’re constantly switching mental gears
just to talk to the data you own. You might think, “I’ll just
plug it all into Power BI.” And yes, that can help with
visualization after you’ve done the heavy lifting. But the real
win would be making Copilot itself capable of pulling from
Planner, SharePoint, and Teams directly—without you acting as the
middleman. That means teaching it the exact endpoints,
parameters, and authentication flows each source requires, so you
can ask a natural language question and actually get a complete
answer back. Step one in that process is deceptively simple:
knowing exactly which services are holding the information you
care about. Once you can point to the right containers—Planner
for tasks, SharePoint for approvals, Teams for context—you’re
ready to move past screenshots and spreadsheets. In the next
stage, we’ll take that map and turn it into actual API calls that
Copilot can run on its own. That’s when the scattered pieces
finally start to connect.


Mapping the APIs That Matter


Knowing where your project data lives is only half the battle.
The real challenge is getting it out in a clean, usable format
that Copilot can consume without choking on it. Planner and
SharePoint may look friendly in the browser, but the moment you
start pulling data programmatically, you hit the reality that
each one speaks a slightly different language. This is where we
narrow the field to the two main gateways we need to master:
Microsoft Graph for most of the M365 ecosystem and the SharePoint
REST API for anything living deep inside lists and document
libraries. On paper, Microsoft Graph is straightforward. You make
a request to an endpoint like `/planner/tasks` and it hands you
back task data. In reality, that “task data” is wrapped in
multiple levels of JSON objects that you need to unwrap just to
get a title, due date, and assigned user. Properties like
`bucketId` or `planId` are opaque until you’ve run a separate
query to resolve them. Contrast that with SharePoint’s REST API,
which doesn’t give you a global feed of items at all. You have to
know the exact list you want, right down to its internal GUID,
and then structure your call as
`/sites/{siteId}/lists/{listId}/items`. If that list has custom
columns, you have to explicitly request those fields; otherwise,
they never come back. Let’s take a real example. You might pull
Planner tasks with Graph using something like: `GET
/planner/plans/{planId}/tasks?$select=title,dueDateTime,assignments`
That will get you the essentials, but you’ll still need follow-up
calls to map user IDs to display names. Now compare that to
milestones in SharePoint: `GET
/sites/{siteId}/lists/{listId}/items?$select=Title,Status,DueDate`
The verbs and the query options feel similar, but under the hood
they behave differently. Graph honors OData querying rules for
filtering and ordering, while SharePoint’s API can be picky about
case sensitivity and internal column names. Once you start
writing these calls, you have to think beyond just the syntax.
Graph enforces per-app and per-user rate limits that can throttle
your requests if you’re not careful. SharePoint endpoints might
not hit you with the same quotas, but they will slow noticeably
if you start returning thousands of rows for no reason. That’s
why filtering at the source is critical. If you know you only
need active tasks due in the next 14 days, it’s better to include
that filter in the request itself than to pull everything and
trim it later. And then there are authentication scopes to
consider. For the Planner endpoint, you might need `Tasks.Read`
at the delegated level. For a SharePoint list, you might be
requesting `Sites.Read.All` or even a narrower, site-specific
scope. Mix those up, and you’ll get mysterious 403 errors that
look like your code is broken when it’s really just an
under-scoped token. Think of it like using two different delivery
companies to get parts for a single build. Both will eventually
get the packages to you, but one labels their boxes with SKUs and
the other just scribbles a description on the side. Until you
open them and match the contents, you can’t start assembling
anything. Copilot works the same way—it needs a consistent,
predictable format to combine these data sets into something
useful. The best move at this stage is to define your exact
calls, with the filters and fields you truly need, and document
them. That way, you’re not reinventing the wheel every time the
plugin needs to run them. Copilot can’t guess these endpoints. It
has to be told, in explicit terms, where to look and what to ask
for. Once you have that list of precise API calls, you’ve
essentially built a blueprint for how your plugin will fetch the
right details at the right time. Next, we’ll turn that blueprint
into something Copilot can actually read—the manifest that acts
as the translator between these APIs and the natural language
questions users will throw at it.


Writing the Manifest That Teaches Copilot


Copilot can’t see your APIs until you hand it a map. That map is
the plugin manifest. Without it, Copilot has no idea where your
data lives, what parameters it needs, or how to turn a vague
request into a precise API call. The manifest is essentially a
contract between your data and Copilot’s natural language layer.
It says, “When a user asks about this kind of thing, here’s where
you go and here’s how you ask for it.” At its core, the manifest
is just a structured JSON file. It lists the endpoints your
plugin can call, the methods they support, and the inputs they
require. Each operation you define in the manifest has a
description that tells Copilot—in plain language—what it does.
You include parameters: their names, types, whether they’re
required, and a short explanation of what they represent. It’s
not enough to say “projectId.” You need to tell Copilot that
projectId corresponds to a Planner bucketId or a SharePoint list
filter so it can make the right connection when parsing user
intent. Get a manifest entry wrong, and you’ll see two kinds of
failure. In one case, Copilot might hit the wrong endpoint or
pass the wrong parameter, serving up irrelevant results. In the
other, it refuses to call your API entirely because the manifest
and user request don’t match well enough to be confident. Both
lead to the same frustration: trips back to Teams or Outlook to
manually check the data you wanted Copilot to fetch for you. A
clean example in JSON might define a parameter like this: {
"name": "projectId", "type": "string", "required": true,
"description": "The unique ID for a project, mapped to Planner's
bucketId or SharePoint's list filter."} The operation would then
reference that parameter in a URL template for your Graph or
SharePoint call. The manifest’s role here is twofold: it tells
Copilot that this value must come from the conversation context,
and it links the human-friendly “Project Apollo” to the API’s raw
ID value. Good manifests read like minimal but clear
documentation. Keep descriptions short enough for Copilot to
process quickly, but long enough to remove ambiguity. Use
parameter names that map cleanly to the way a user speaks. If
your audience says “milestone name,” make that the parameter
name; don’t hide it behind something like “ms_key” unless you
want Copilot constantly guessing. Order parameters logically and
set defaults if certain inputs will almost always be the same.
The manifest directly shapes how Copilot handles natural
language. When a user says “Show me the status of Project
Apollo,” Copilot uses your manifest to translate “Project Apollo”
into `projectId=abcd123` and inserts that into the correct API
call. Without a well-thought-out manifest, that translation
breaks down, and Copilot falls back on generic answers or none at
all. One common pitfall is mismatched naming. If your manifest
says “ProjectName” but your API call expects “project_id,” you’ve
just built a silent failure into your plugin. Another is
forgetting to include authentication requirements in the
manifest. You can have perfect endpoints, but without telling
Copilot what auth token to present or how to obtain it, the calls
won’t pass the security gate. Even with the cleanest structure,
none of it matters if authentication isn’t handled. Right now,
the manifest is just instructions—it hasn’t proved to the data
sources that Copilot has permission to read them. You can define
every operation in detail, but until you connect those to valid
credentials, Copilot will be locked out of the very sources
you’ve mapped. When the manifest is solid, Copilot goes from
blindly guessing to confidently navigating. It understands what
you have, where it is, and how to retrieve it without you
mediating the process every time. But opening those channels to
sensitive data comes with risk, and that’s where the next
piece—authentication and security—becomes the gatekeeper for
everything you’ve built so far.


Securing and Deploying Your Plugin


The quickest way to get yourself removed from a project is to let
Copilot have unrestricted access to confidential data. You can’t
just hand over API endpoints and hope for the best. Every request
Copilot makes still goes through your organization’s security
perimeter, so if it’s going to touch project status, contracts,
or sensitive conversations, access has to be both deliberate and
auditable. Security here isn’t about paranoia—it’s about
compliance, privacy obligations, and retaining control over who
can see what, when, and how. Authentication is the gatekeeper.
Without it, you’re effectively bypassing your company’s identity
and access management. That’s a nightmare for IT and legal teams
and a guaranteed way to get any plugin blocked from production.
The flip side is, if you make authentication too clumsy, no one
will use the tool. The goal is to integrate Copilot so it can
retrieve exactly what it needs in real time, under the same
security protocols you already enforce for human users. That
process starts with Azure Active Directory. You’ll register your
plugin as an application there, which gives it a unique client ID
and, in most cases, a client secret. During registration, you
define the API permissions it needs—no more, no less. This is
where least privilege becomes more than a buzzword. If all you
need Copilot to do is read Planner tasks, request
`Tasks.Read`—not `Tasks.ReadWrite.All`. For SharePoint lists,
stick to `Sites.Read.All` unless you have a specific reason for
write access. Over-permissioning your plugin doesn’t just
increase risk—it creates a bigger surface area for any potential
breach. With the Azure AD app in place, you implement OAuth 2.0.
That means when Copilot tries to call your API, it gets
redirected to Microsoft’s identity platform, authenticates, and
is issued an access token carrying those specific permissions.
Tokens expire, so your plugin also needs a refresh token flow to
maintain access silently in the background without prompting the
user repeatedly. This is where many developers misstep—forgetting
to test what happens when a token expires mid-session, or not
handling the refresh logic correctly. Granting permissions for
Graph and SharePoint follows the same broad pattern. The Graph
side might look like running `Connect-MgGraph -Scopes
"Tasks.Read"` for delegated access during testing, while
SharePoint’s permissions hinge on adding the correct API access
in the Azure portal. Don’t forget admin consent—many scopes
require an administrator to explicitly approve them
organization-wide before they’ll work. Common mistakes trip
people up here more than anywhere else. A mismatched redirect URI
in your registration will block the OAuth flow entirely.
Forgetting to store your client secret securely will force you to
re-issue new credentials. Skipping token refresh testing means
discovering the failure during a live demo. These aren’t
complicated fixes, but they’re easy to overlook if you only test
in short bursts. Once authentication is working, deployment is
about making sure that the plugin runs within the same compliance
envelope as everything else in Microsoft 365. That means checking
that every call it makes is logged, that responses aren’t cached
insecurely, and that your organization’s existing data loss
prevention rules still apply. Before rolling it out broadly, run
scenarios with real project data but in a controlled environment.
Verify that Copilot can retrieve a Planner task list without
accidentally surfacing unrelated tasks from other projects. Make
sure a SharePoint milestones query doesn’t pull in columns that
weren’t intended to be shared. When you finish this step, you’re
not just giving Copilot access—you’re giving it access in a way
that’s defensible if anyone questions it later. You have a
registered app, scoped permissions, a tested authentication flow,
and deployment that respects corporate governance. At that point,
your plugin stops being a risk factor and starts being a
dependable part of your reporting process. Now you can start to
see the real shift: project managers no longer hopping between
Planner, SharePoint, and Teams, but asking Copilot a single
question and getting back a reliable, policy-compliant answer
without touching the underlying systems themselves.


Conclusion


The real value here isn’t the plugin itself—it’s the shift in how
your team accesses and trusts project data. Instead of chasing
updates across Planner, SharePoint, and Teams, you create a
single, reliable path for answers. That kind of consistency
changes how decisions get made. Start by mapping your own data
sources. Identify the areas where one API call could replace a
morning of manual checks. Then work out the manifest and security
pieces step by step. With the right APIs, clear structure, and
locked-down access, one Copilot question can replace an entire
day of gathering, cleaning, and combining updates.


Get full access to M365 Show - Microsoft 365 Digital Workplace
Daily at m365.show/subscribe