Connect Microsoft Graph
Microsoft Graph is how StackJack reaches Microsoft 365 and Entra ID — the users, groups, licences, devices, mailboxes, Teams, security alerts and Intune policies that make up most MSPs' daily work.…
Written By Christopher Scaminaci
Last updated About 22 hours ago
Microsoft Graph is how StackJack reaches Microsoft 365 and Entra ID — the users, groups, licences, devices, mailboxes, Teams, security alerts and Intune policies that make up most MSPs' daily work. Connecting it gives your AI a large set of graph_ MCP tools — MCP (Model Context Protocol) tools are the standardized commands an AI assistant can call through StackJack.
It is the sibling of the Microsoft Azure connector and shares the same sign-in, but it is a separate connection: Azure covers infrastructure and billing, Graph covers identity, devices and collaboration. Connecting one does not connect the other.
Nothing to enter, unless you bring your own app
Like Azure, this connector asks for no key, no secret and no URL by default. StackJack has its own Microsoft application, so you connect by signing in and approving the request — that is the entire setup. (Organizations that prefer to consent to an application they own can bring their own app registration instead — see Bring your own app registration below.)
- Check who can approve. Most of what this connector does needs a Global Administrator to approve it once, on behalf of everyone. If you are one, you can approve it yourself as you connect. If you are not, either ask an administrator to connect first, or ask them to approve the request when Microsoft prompts. A message saying approval is needed is Microsoft asking for that consent — it is not an error, and it is a one-time step for the whole organization.
- Connect with Microsoft. On the Connectors page, open Microsoft Graph and choose Connect with Microsoft. Sign in with the account you use for Microsoft 365 admin work and approve the request.
- Check what you can reach. Ask your AI to list your users. If something you expected is refused, that is usually a question about your own admin role rather than the connection — see below.
Your admin role decides what you can do
This is the most important thing to understand about this connector, and it is what separates StackJack from tools that connect to Microsoft 365 with a robot account.
Microsoft Graph checks two things on every call: the permissions you approved when connecting, and your own Microsoft 365 admin role. An action needs both. Approving the full list of permissions does not make you an administrator — a Helpdesk Administrator who approves everything still has a Helpdesk Administrator's reach, and will correctly be refused when they try to reset a Global Administrator's password.
That is the design, not a limitation, and it buys you three things:
- Your existing least-privilege model keeps working. You do not have to trust an AI assistant with more access than the person using it already has.
- The audit log names a real person. Every action in a customer's Microsoft 365 audit log shows the technician who performed it, not a shared service account. That is the record you would want to be accurate if a change is ever questioned.
- Refusals are meaningful. When Graph refuses, it is enforcing your role correctly. Two people on the same team will legitimately get different answers from the same tool.
When something is refused, check your role first — it is the far more common cause and takes seconds to verify. Only if your role clearly covers the action is the permission the problem, and reconnecting re-runs consent to add anything newly required.
Managing your customers' Microsoft 365
If you manage customers through Microsoft's delegated access (GDAP), your USER access comes along automatically — there is no separate connection per customer. One thing does need setting up per customer, once: admin consent for the StackJack application in that customer's tenant (see the next section).
Every Graph tool takes an optional customer directory (their Microsoft tenant ID or a verified domain such as contoso.onmicrosoft.com). Leave it out and the tool works on your own tenant. Provide it and the tool works on that customer's, with whatever delegated access you already hold there.
Consent once per customer tenant
GDAP answers "which PEOPLE may act in this customer's directory". Microsoft also asks a second, separate question on every call: "has this customer's tenant admitted the APPLICATION the call comes through?" GDAP roles do not answer it — the application must be admin-consented in the customer tenant, once. Until that happens, calls into that customer fail with a consent error (Microsoft's code AADSTS65001), and reconnecting your own sign-in will not fix it — consent is granted per tenant, not per user.
To grant it:
- On the Connectors page, open Microsoft Graph and use Authorize a customer tenant: enter the customer's tenant ID or a verified domain and generate the consent link.
- Send the link to an administrator in the customer's tenant. Any of these roles can approve it: Global Administrator, Application Administrator, or Cloud Application Administrator.
- They open the link, review the permissions, and approve. Allow a few minutes for Microsoft to propagate the consent, then the customer's tools work for every technician with GDAP access.
If Microsoft answers that multi-factor authentication is required (AADSTS50076): for GDAP access, MFA is enforced in your own partner tenant, at the Microsoft sign-in behind Connect with Microsoft, and the customer tenant always trusts it. A customer tenant cannot run its own MFA challenge for a GDAP user, so an MFA requirement is never fixed on the customer's side. Make sure the account is covered by MFA in your tenant, then reconnect Microsoft Graph from Connectors and complete the prompt.
If a consented customer tenant refuses for another reason: ask its admin to read the sign-in log entry for the reason code. A Conditional Access policy that blocks external accounts needs the specific partner accounts excluded from it.
In practice you just name the customer when you ask:
- "List my delegated customers."
- "Which users at Contoso have not signed in for 90 days?"
- "Show me Contoso's Conditional Access policies."
Your access to a customer comes through a security group, not through your own admin role. If a customer's tools are refused while your own tenant works fine, the usual cause is that you personally are not in the group assigned to that customer — an admin in your partner tenant adds you to it. Being a Global Administrator in your own tenant grants nothing in theirs.
Every person signs in for themselves
There is no shared Microsoft Graph identity for a team to fall back on. The stored connection is one person's own Microsoft sign-in, carrying their admin roles and — where they hold delegated access — their reach into your customers' tenants, so StackJack will not run anyone else's calls under it.
- Owners keep the fallback. The organization's owner and co-owners can use the stored connection before they personally sign in.
- Everyone else must connect their own account, including Administrators. Until they do, Graph tools refuse for them with
personal_sign_in_required. It is not a preference — it is the only way that member gets a Microsoft identity at all. - Nothing has to be prepared for them while the organization is on StackJack's own Microsoft application: a member can connect whether or not an owner ever configured the connector.
That is also what makes the per-person role model and the audit trail real. One shared identity would collapse the whole team's work onto one name and give everyone the reach of whoever set it up.
Members connect from the Connectors page, in their personal sign-ins section. The rules in full: Who can use which identity.
Bring your own app registration
Some organizations prefer to consent to an application they own — their name on the consent screen, their control over the app's permission list, their secret to rotate. StackJack supports that:
- Create the app in your tenant. StackJack ships a provisioning script that registers a multitenant Entra application carrying StackJack's redirect URLs and the delegated permission set for the tier you pick. You can equally build it by hand or push it with your own automation — the script prints everything the registration needs.
- Paste the credentials into StackJack. On the Connectors page, open Microsoft Graph → Advanced — use your own app registration, and enter the Application (client) ID and client secret. Once your organization is on its own application, reconnecting with these fields empty keeps that application. To return to StackJack's application, tick Switch back to the StackJack application on the next Connect — the option appears once the organization's shared connection is on a custom app — and connect again. If the option does not appear but your organization still connects under its own application, disconnect the connector and connect again with the fields empty. Disconnecting removes the organization's shared connection and un-links existing MCP keys from the connector, so plan it like any credential change. If you also tick the "remove its tools" box, the connector's tools stay off until the organization connects again — your own reconnect turns them back on automatically, but a team member's personal reconnect cannot. The switch changes the organization's shared connection; team members' sign-ins and agent credentials keep their current application until each is reconnected or re-enrolled. Each Microsoft connector card (Microsoft Graph and Microsoft Azure) stores its own application choice, so switch back on each card you use.
- Connect with Microsoft as usual. From then on every sign-in in your organization — yours, your teammates', your automations' — runs under your app. Customer-tenant consent links from Authorize a customer tenant name your app too.
Two things to plan for: your app must be multitenant if you manage customers through GDAP (single-tenant apps cannot be consented in a customer directory), and rotating your app's client secret invalidates existing sign-ins — update the secret in StackJack first, then each person reconnects.
Choosing how much to consent
Whether you use StackJack's application or your own, the connect flow lets you pick a permission tier for your organization:
- Full (default) — every capability the connector ships.
- Standard — everything except directory-privileged writes (role management, app registrations, Conditional Access policy writes, privileged device operations, and similar). The read-only forms of those same areas are still requested, so listing your delegated customers, your domains, your organization and your directory roles keeps working.
- Read-only — the read-only form of every capability the connector ships. It is not a shorter list of the same permissions: where the connector normally asks to read and write your mail, this tier asks only to read it.
The tier sets what the Microsoft consent prompt asks for, and a tool that needs a permission nobody consented to fails with Microsoft's own permissions error instead of acting. Two things it does not do: it does not revoke permissions your organization already consented to, and it does not narrow a customer-tenant consent link — that link grants whatever the application's own registration lists. Start narrow if your organization is hesitant; you can re-connect on a wider tier later, and Microsoft prompts only for the newly added permissions.
The permissions each tier requests
The provisioning script looks every permission up in your own tenant while it runs, so it never prints a list you can copy out of it. The names are below for anyone who builds the app registration by hand, or who mirrors the same permission set in another tool. They are Microsoft's own delegated permission names, spelled exactly as the Entra portal spells them on an app registration's API permissions page.
Two things to read them with. A narrower tier is not a shorter version of a wider one — Standard and Read-only both ask for read permissions that Full never asks for, because at Full the matching write permission already covers the read. And the first four entries in every list (openid, profile, email, offline_access) are the sign-in permissions any connection needs; offline_access is the one that lets a connection keep working without sending you back to the sign-in page.
Full — 59 permissions
openid
profile
email
offline_access
User.Read
User.ReadWrite.All
Group.ReadWrite.All
Directory.ReadWrite.All
AdministrativeUnit.ReadWrite.All
AppRoleAssignment.ReadWrite.All
Directory.AccessAsUser.All
Device.Read.All
Application.ReadWrite.All
RoleManagement.ReadWrite.Directory
Policy.Read.All
Policy.ReadWrite.ConditionalAccess
Policy.ReadWrite.AuthenticationMethod
AuditLog.Read.All
Reports.Read.All
Organization.ReadWrite.All
Domain.ReadWrite.All
IdentityRiskyUser.ReadWrite.All
IdentityRiskEvent.Read.All
Mail.ReadWrite
Mail.Send
Calendars.ReadWrite
Files.ReadWrite.All
Sites.ReadWrite.All
MailboxSettings.ReadWrite
Contacts.ReadWrite
Mail.ReadWrite.Shared
Mail.Send.Shared
Calendars.ReadWrite.Shared
Contacts.ReadWrite.Shared
Team.ReadBasic.All
Channel.ReadBasic.All
ChannelMessage.Read.All
TeamMember.ReadWrite.All
Team.Create
TeamSettings.ReadWrite.All
Channel.Create
ChannelSettings.ReadWrite.All
ChannelMessage.Send
Chat.ReadWrite
Presence.Read.All
SecurityEvents.ReadWrite.All
SecurityAlert.ReadWrite.All
SecurityIncident.ReadWrite.All
ThreatHunting.Read.All
DeviceManagementManagedDevices.PrivilegedOperations.All
DeviceManagementManagedDevices.ReadWrite.All
DeviceManagementConfiguration.ReadWrite.All
DeviceManagementApps.ReadWrite.All
DeviceManagementServiceConfig.ReadWrite.All
DeviceManagementRBAC.Read.All
DeviceManagementRBAC.ReadWrite.All
DeviceManagementScripts.ReadWrite.All
DelegatedAdminRelationship.ReadWrite.All
UserAuthenticationMethod.ReadWrite.All
Standard — 54 permissions
openid
profile
email
offline_access
User.Read
User.ReadWrite.All
Group.ReadWrite.All
Directory.ReadWrite.All
AdministrativeUnit.ReadWrite.All
Device.Read.All
Policy.Read.All
AuditLog.Read.All
Reports.Read.All
IdentityRiskEvent.Read.All
Mail.ReadWrite
Mail.Send
Calendars.ReadWrite
Files.ReadWrite.All
Sites.ReadWrite.All
MailboxSettings.ReadWrite
Contacts.ReadWrite
Mail.ReadWrite.Shared
Mail.Send.Shared
Calendars.ReadWrite.Shared
Contacts.ReadWrite.Shared
Team.ReadBasic.All
Channel.ReadBasic.All
ChannelMessage.Read.All
TeamMember.ReadWrite.All
Team.Create
TeamSettings.ReadWrite.All
Channel.Create
ChannelSettings.ReadWrite.All
ChannelMessage.Send
Chat.ReadWrite
Presence.Read.All
SecurityEvents.ReadWrite.All
SecurityAlert.ReadWrite.All
SecurityIncident.ReadWrite.All
ThreatHunting.Read.All
DeviceManagementManagedDevices.ReadWrite.All
DeviceManagementConfiguration.ReadWrite.All
DeviceManagementApps.ReadWrite.All
DeviceManagementServiceConfig.ReadWrite.All
DeviceManagementRBAC.Read.All
DeviceManagementRBAC.ReadWrite.All
DeviceManagementScripts.ReadWrite.All
RoleManagement.Read.Directory
Application.Read.All
UserAuthenticationMethod.Read.All
IdentityRiskyUser.Read.All
Domain.Read.All
Organization.Read.All
DelegatedAdminRelationship.Read.All
The last seven are the read permissions this tier adds back for the privileged writes it drops, so that listing your delegated customers, your domains, your organization, your directory roles and your risky users keeps working.
Read-only — 47 permissions
openid
profile
email
offline_access
User.Read
User.Read.All
Group.Read.All
Directory.Read.All
AdministrativeUnit.Read.All
Device.Read.All
Application.Read.All
RoleManagement.Read.Directory
Policy.Read.All
AuditLog.Read.All
Reports.Read.All
Organization.Read.All
Domain.Read.All
IdentityRiskyUser.Read.All
IdentityRiskEvent.Read.All
Mail.Read
Calendars.Read
Files.Read.All
Sites.Read.All
MailboxSettings.Read
Contacts.Read
Mail.Read.Shared
Calendars.Read.Shared
Contacts.Read.Shared
Team.ReadBasic.All
Channel.ReadBasic.All
ChannelMessage.Read.All
TeamMember.Read.All
TeamSettings.Read.All
ChannelSettings.Read.All
Chat.Read
Presence.Read.All
SecurityEvents.Read.All
SecurityAlert.Read.All
SecurityIncident.Read.All
ThreatHunting.Read.All
DeviceManagementManagedDevices.Read.All
DeviceManagementConfiguration.Read.All
DeviceManagementApps.Read.All
DeviceManagementServiceConfig.Read.All
DeviceManagementRBAC.Read.All
DelegatedAdminRelationship.Read.All
UserAuthenticationMethod.Read.All
Microsoft Azure asks for the same one permission on every tier. That connector requests a single delegated permission — https://management.azure.com/user_impersonation — alongside the four sign-in permissions, and the tier you pick changes nothing about it. Azure publishes only that one permission, and what you can actually reach through it is decided by your own Azure role assignments rather than by anything consented here.
Working in a shared mailbox
Mail, calendar and contact tools act on your own mailbox by default. Most of them also accept a
shared or delegated mailbox address — support@contoso.com, a reception calendar, a departmental
address book — and act there instead.
This needs two things, and StackJack can only supply one of them. Connecting grants the Microsoft permission. The second half is Exchange delegate access to that specific mailbox, granted per mailbox by its owner or by an Exchange administrator: Full Access to read and manage its contents, and Send As or Send on Behalf to send from it. No Microsoft Entra admin role gives you this — not even Global Administrator. If a tool reports that access was denied for a shared mailbox, that grant is almost always what is missing, and the fix is in the Exchange admin centre rather than here.
Sending from a shared mailbox works too, and it is worth knowing which name recipients will see. That depends on the Exchange permission you hold, not on anything set here:
- Send As — the message appears to come from the shared mailbox itself. Nothing indicates who actually sent it.
- Send on Behalf — the message shows as sent by you on behalf of the shared mailbox.
If you hold neither, sending is refused even though reading works, which is the usual explanation when a shared mailbox can be read but not sent from.
One limit worth knowing before you plan around it:
- Mailbox settings are always your own. Out-of-office replies, Outlook categories and inbox rules read and write your mailbox regardless of what else you ask for. Microsoft publishes no shared equivalent for these, so this one is not a matter of asking for more access — there is nothing to ask for.
Calendars work more completely: everything including accepting, declining, forwarding and cancelling meetings can be done in a calendar shared with you. Free/busy lookups are the exception and always run from your own account — they read other people by name rather than by opening their calendar.
What this connector deliberately does not do
Stated up front so it does not read as a gap. Most of these are statements about the purpose-built tools; the raw request tools described below reach further, with the same consent and the same Entra role.
- It has no tools for the Exchange Online admin surface. Transport rules, mail-flow connectors, retention policies and mailbox permissions beyond what Graph exposes are not part of Microsoft Graph at all — they need Exchange's own administration interface, and no raw request reaches them either. This is the largest honest gap in Microsoft 365 coverage and is worth knowing about rather than discovering.
- It has no tools for Microsoft Purview / compliance — eDiscovery, DLP policies, retention labels and insider risk. Where Graph publishes these, a raw request can reach them.
- It has no tools for Planner, To Do, Viva, Bookings or the Excel workbook API. Those are end-user productivity surfaces rather than tenant management. They are on Graph, so a raw request can reach them.
- It does not cover Microsoft 365 Government or the 21Vianet cloud in China. Those are separate clouds needing their own setup, and Microsoft's delegated-access APIs are unavailable in the China cloud regardless.
- The purpose-built tools use only Microsoft's generally available v1.0 endpoint, so a Microsoft preview change cannot break an automation built on them. The most-missed consequence is Intune scripts: platform scripts, shell scripts and proactive remediations are still preview-only in Microsoft's API, so no tool covers them. The raw request tools are the exception and can be pointed at the beta endpoint deliberately — read the warning about that below before you build on it. Microsoft promoting an API to v1.0 does not, on its own, create a purpose-built tool for it, and it does not change what your organization has consented to.
- It does not watch for changes. Tools answer questions when asked; there are no subscriptions to Microsoft change notifications.
- It does not give automations access by default. An automation has no signed-in person of its own, so it cannot borrow your connection. If you want one to work in Microsoft 365, an administrator enrols a dedicated sign-in for that specific automation — see below.
Letting an automation use Microsoft 365
An automation can be given its own Microsoft connection, enrolled per automation by someone with agent-configuration access. It is worth understanding exactly what that means before doing it, because it is the one place where this connector's per-person model needs a deliberate decision rather than following automatically.
The automation acts as whichever Microsoft account was signed in during enrolment, with that account's admin role, and — if that account holds delegated access — in your customers' tenants too. So the choice of account is the choice of how much an unattended process can reach. Two practices worth following:
- Enrol a dedicated account rather than a person's. A purpose-made account with only the roles that automation needs keeps the blast radius honest, and keeps the audit trail readable — actions show up under a name that means "this automation" rather than under a technician who was not at their desk.
- Give the automation only the tools it needs. Sending mail and wiping devices are real actions with real recipients and real hardware; an automation that never needs them should not be offered them.
Removing an automation's connection revokes it immediately and does not affect anyone's personal connection.
Things that catch people out
A tool says approval is required. That is Microsoft asking for tenant-wide admin consent, not a failure. One Global Administrator approves once and everyone can connect afterwards.
A query is rejected as unsupported. Graph splits filtering into a basic set and an advanced set, and refuses an advanced expression sent as a basic one. The usual triggers are "starts with" or "ends with" matching, a not-equals, or filtering and sorting in the same request. Simplify — filter or sort, not both — or use a search instead, which StackJack always sends in the advanced form.
Large lists come back partial. StackJack caps a single call at 1,000 items across 10 pages and tells your AI where the list left off so it can continue. This is a StackJack safety limit rather than a Microsoft one.
Two areas throttle much harder than the rest. Conditional Access and Identity Protection allow about one request per second for your entire tenant, shared with every other tool you run, and the sign-in and audit reports are nearly as tight. Ask about those one page at a time rather than sweeping. Throttling is temporary, clears on its own, and never counts toward disabling your connection.
Destructive actions
Some Graph tools reach real people, lock someone out, or change who has access. StackJack marks those as destructive and they are all Pro-tier. Whether your AI application asks you to confirm before running one depends on that application's own settings — see Destructive tools and confirmation. Review those settings, and restrict the tools you grant, before you allow destructive Graph actions.
The sharpest ones are worth knowing by name:
- Sending, replying to or forwarding mail delivers a real message to real recipients and cannot be recalled. It goes from your own mailbox by default, or from a shared mailbox you have Send As or Send on Behalf rights to — in which case the recipients may see the mailbox's name rather than yours.
- Wiping or retiring a device factory-resets or unenrolls a customer's endpoint as soon as it next checks in, with no undo from here.
- Resetting a password or revoking sign-in sessions locks a human out of their work until they are helped back in.
- Adding an application password or key mints a working credential that can be used from anywhere.
- Changing a Conditional Access policy can lock an entire tenant out, including you.
- Granting a directory role, an Intune role, or a delegated-access assignment changes the access-control boundary itself. Intune role changes are worth singling out: an Intune role assignment names both who gets the role and which devices they may act on, and updating one replaces both lists rather than adding to them.
- Disabling or deleting a device stops that machine passing Conditional Access, so the person using it loses access to their work accounts with nothing on screen to explain why. Deleting the device record also takes its BitLocker recovery keys with it — read those out first if the disk is encrypted.
- Archiving a team or a channel makes it read-only for everyone at once, with no notice to its members.
Marking these clearly is what lets the rest of the connector be used freely.
Advanced: raw API requests
Reach for a purpose-built tool first. They escape the identifiers you pass, add the headers Graph needs, cap the page size, and their descriptions say what the answer means. Use the raw tools only where no purpose-built tool exists.
Two tools send a request you compose straight to Microsoft Graph:
graph_raw_getsends one GET. It is Free-tier and read-only.graph_raw_requestsends one POST, PUT, PATCH or DELETE. It is Pro-tier and marked destructive. It refuses GET, so a read cannot be run through the write tool.
What they change, and what they do not:
- They widen coverage, not permission. Your connector subscription, your endpoint's tool selection, your plan and your monthly allowance all still apply. Graph still authorizes each call on the overlap between what your organization consented to and your own Entra role, so a raw request returns exactly what you could reach anyway.
- They are the only way to reach Microsoft's beta endpoint. Every purpose-built tool is pinned to v1.0. Beta is not a newer v1.0: Microsoft documents it as subject to change without notice and not for production use, and properties appear and disappear between releases. An automation built on a beta shape breaks quietly when Microsoft changes it. Use v1.0 unless the data exists only on beta.
- Paging is yours to drive. A continuation link comes back in the body; pass it back to get the next page. Nothing pages for you.
- Advanced queries need a header these tools do not add. Graph's advanced filtering requires a consistency header, and the raw tools send none. Use the purpose-built tool that knows to add it.
- A merging write clears what you set to null. PATCH on Graph leaves out properties alone, while an explicit null empties them. Only the body distinguishes the two.
- Some surfaces refuse a raw write outright. The delegated-access relationship and assignment writes require a concurrency header that these tools do not send, so use the purpose-built tools there.
- Most write responses come back empty. Graph answers many actions with an acceptance and no body, which arrives as
{}. That is not a failure and it is not proof of completion — read the object back to confirm. - The path is fenced. It is relative to the version segment, with no scheme, no directory traversal and no version segment of its own. Anything else is refused before the request is sent.
See the generated Microsoft Graph tool reference for the current inventory, plan assignment, input schemas, and destructive-action labels.
Microsoft Graph tools
graph_ · 530 tools · Free 284 · Pro 246
Users
Groups
Delegated Admin (GDAP)
Licensing
Organization & Domains
Applications & Service Principals
Directory Roles & PIM
Authentication Methods
Conditional Access
Administrative Units
Devices
Intune Devices
Intune Configuration
Identity Protection
Audit Logs
Directory Objects
Security
Usage Reports
Files
Calendar
Contacts
SharePoint
Teams
Chats & Presence
Intune Applications
Partner Center (CSP)
Raw Requests
More in Connector guides
Connect Acronis Cyber Protect CloudConnect Action1Connect AddigyConnect AlertOpsStill need help? Ask the team