Microsoft 365 logo
Live

Microsoft 365

Ask once across every tenant — identity, licensing, devices, and security posture.

Microsoft 365 is where most of your clients' identity already lives, and it is where the questions that matter get asked: who is missing MFA, which paid seats nobody uses, which laptops fell out of compliance, what Conditional Access really covers, which apps somebody consented to last quarter. Connect each tenant and a session answers those across all of them at once. Consent is per tenant and per capability pack, granted by the client's own Global Admin — reads are the base, and user, licensing and device changes are deliberate additions on top.

The story

What changes once it’s connected.

One tenant is a browser tab. Thirty tenants is thirty browser tabs, thirty admin centers that all look identical, and a quarterly security review you keep pushing because nobody wants to click through Entra thirty times to count who never registered MFA. Connect your clients' Microsoft 365 tenants here and the counting stops being manual: ask once and the answer spans every tenant the session can reach, with the client name attached to each row.

The coverage follows how a tenant is actually administered. Users with their licenses, department, on-prem sync state and group memberships, and the lifecycle actions behind an onboard or an offboard. Groups, tenant group policy, Teams and SharePoint site inventory. Owned SKUs with the seat math worked out, and who holds what. Intune devices with compliance state and last check-in, alongside the compliance policies, configuration profiles, published apps and MAM policies they are judged against. Then the security surface an MSP is expected to be able to produce on demand: tenant-wide MFA registration, privileged role membership, Conditional Access and named locations, the authentication-methods and authorization policies, Secure Score, Identity Protection risk, and the enterprise apps and OAuth consents nobody audited. Mailbox settings and inbox rules for the BEC check. Sign-in logs, usage counts, service health, and Message Center.

Writes exist, and they are fenced. Each capability pack is its own Entra app registration holding only the Graph permissions that pack needs, and the client's Global Admin consents to them one screen at a time — a pack they decline is not merely disabled, its token is never minted, so the tools underneath it cannot run. Reading is not one pack: the read surface alone is split across six of them — directory, groups and licensing; Intune; security and audit; Teams and SharePoint; service health; apps and consent — so a client can hand over the directory read and keep the audit read to themselves. Changing users and group membership is a pack of its own. So is licensing. So is device sync, reboot and lock. The two genuinely irreversible tiers — deleting or restoring an account, wiping or retiring a device — stand alone, and every call in them is rejected unless it echoes the exact target back: the person's sign-in address, the deleted object's id, or the device's exact name.

Things you can ask

Ask it like you’d ask a teammate.

>Which clients have MFA gaps right now?
>How many seats is Family Worship Center paying for on each SKU but not assigning?
>Who has Global Admin at every connected tenant, and do they all have MFA?
>Which devices are out of compliance, and what compliance policies is that tenant running?
>Disable that departing user, revoke their sessions, and take their license back.
>What's Contoso's Secure Score, and which improvement actions come with it?
>Which enterprise apps have been consented to in this tenant, and by whom?
>Is Microsoft degraded right now, or is it just this client?

Skills included

Every skill, in the open.

64 skills across 8 areas

Reads by default, and every write is a separate capability pack the client's own Global Admin consents to, tenant by tenant — a pack that was never consented cannot be used at all, because no token is ever minted for it. With the user-and-group manage pack a session can create an account and hand back a one-time temp password, edit display name, job title, department and usage location, disable and re-enable sign-in, reset a password, revoke every refresh token a person holds, clear their registered phone and Microsoft Authenticator methods, create a security group, and add or remove group members. The licensing pack assigns and removes SKUs on a user and does nothing else — it never buys, cancels or resizes a subscription. The device-manage pack triggers a sync, a reboot, or a remote lock. Two destructive tiers stand on their own and are granted separately from all of that: user delete and restore, where a delete drops the account into Microsoft's 30-day recycle bin, and device wipe and retire. Every destructive call is refused outright unless the exact target is echoed back — the account's sign-in address, the deleted object's id, or the device's exact name.

Clients & connection3Which tenants are connected, what each client's Global Admin actually consented to, and who this session is. Start here when an answer comes back thinner than you expected — usually a pack was declined, not a bug.⊘ Read-only, and bounded by the session: where a session has been pinned to particular client connections, only those are listed, not the whole book. It cannot connect a tenant, request a pack, or withdraw one — consent happens on the client's side, in Microsoft's own screens.
  • whoamiThe identity behind this session — which org it belongs to, what scopes its token carries, and how many client tenants are in reach of it.
  • list_clientsEvery connected tenant on the roster, each one showing pack by pack what the client granted and whether the last health probe came back clean.
  • get_client_healthOne tenant's connection opened up — which packs are granted, which are still sitting pending, when consent was given, and how the latest probe went.
Users & sign-in13The people in a tenant: search and read them, see their licenses, their groups, and whether they're synced from on-prem AD — plus the whole lifecycle sequence behind an onboard, a password reset, or an offboard.⊘ Directory identity only — no mailbox, file, Teams message or SharePoint document is readable or writable from here. Temp passwords are shown once and cannot be retrieved afterwards. It edits the four profile fields named above and no others: it does not set a manager, change a sign-in address, or grant an admin role. Clearing MFA methods removes phone and Authenticator registrations and leaves the password method alone.✎ Writes: With the user-and-group manage pack granted: creates an account and returns a one-time temporary password that must be changed at first sign-in; edits display name, job title, department and usage location; disables and re-enables sign-in; resets a password to a fresh one-time value; revokes every refresh token so all of a person's sessions must re-authenticate; and deletes their registered phone and Microsoft Authenticator methods, forcing MFA re-registration. With the user destructive pack granted: deletes an account into Microsoft's 30-day recycle bin, or restores one out of it — both refused unless the exact confirm string is echoed back, the account's sign-in address to delete and the deleted object's id to restore.
  • search_usersFind a person in a client tenant from a fragment of their display name or their sign-in address.
  • get_userOpen one account in full — job title, department, the licenses assigned to it, whether sign-in is enabled, and whether it's synced up from on-prem AD.
  • list_user_groupsEvery group an account belongs to directly, security and Microsoft 365 alike — inherited nesting isn't flattened out.
  • list_usersWalk a tenant's whole directory alphabetically, up to 500 at a time — the read for when you want everybody rather than one lookup.
  • create_userStand up an account and get back a one-time temporary password the person must replace at first sign-in — displayed once, never recoverable, so hand it over out of band.
  • update_userCorrect the profile on an existing account — display name, job title, department, or the usage location that licensing depends on.
  • disable_userBlock an account's sign-in while leaving its mailbox, files and licenses untouched — step one of an offboard.
  • enable_userSwitch a disabled account's sign-in back on.
  • reset_passwordRoll a user's password over to a new one-time value they must replace at next sign-in — it surfaces exactly once, so capture it before you move on.
  • revoke_sessionsTear up every refresh token an account holds so each signed-in session has to authenticate again — step two of an offboard, and the fastest answer to a stolen laptop.
  • reset_mfa_methodsClear someone's registered phone and Authenticator methods so they have to enroll MFA from scratch — used when a phone is lost, and it never touches their password.
  • delete_userDrop an account into Microsoft's 30-day recycle bin — destructive, and refused until the account's exact sign-in address is typed back as confirmation.
  • restore_userBring a soft-deleted account back out of the recycle bin, gated the same way on echoing that deleted object's exact id.
Groups & Teams10How a tenant is organized: security, Microsoft 365 and dynamic groups with their membership, the tenant-wide rules new groups inherit, and the Teams and SharePoint inventory sitting on top of them.⊘ Group creation covers security groups only — Microsoft 365 groups, distribution lists and Teams cannot be created here, and no team, channel or SharePoint site is created, renamed or deleted. Dynamic membership rules are shown but never edited. The Teams and SharePoint reads are inventory: names, descriptions, visibility and URLs, never a message, a file, or a sharing permission.✎ Writes: With the user-and-group manage pack granted: creates a security group, and adds or removes one member of a group at a time.
  • list_groupsEvery group in a tenant — security, Microsoft 365 and dynamic alike — with its mail state and, where one exists, the rule that decides membership.
  • get_groupOne group on its own, found either by object id or by its exact display name.
  • list_group_membersWho sits directly inside a group, by name and sign-in address.
  • create_groupMake a new security group with a display name and optional description — security groups are the only kind this creates.
  • add_group_memberDrop an existing user into a group.
  • remove_group_memberTake a user back out of a group.
  • list_group_settingsThe tenant-wide group rules — guest access, naming policy, and the defaults every new Microsoft 365 group inherits.
  • list_teamsEvery team in the tenant with its description and its visibility — the collaboration inventory, not its contents.
  • list_team_channelsThe channels inside one team, standard and private, each with its name and membership type.
  • list_sharepoint_sitesEvery SharePoint site in the tenant with its URL and creation date — where content lives, not what's in it.
Licensing4What the tenant is paying for and who's actually holding it: owned SKUs with the seat math worked out, one person's assignments, and the moves that free a seat up or fill one.⊘ It never buys, cancels or resizes a subscription; assignment only shuffles seats the client already pays for. The licensing pack carries the assignment permission alone and cannot read the SKU catalogue under its own token, so resolve the SKU with list_skus first or pass its GUID. Handed only a part number, it still tries the lookup, and if that comes back forbidden it falls through and sends the part number to Graph as though it were a SKU id — which Graph then rejects, so the failure surfaces at the assignment rather than at the lookup. A user also needs a usage location set before any license will attach to them.✎ Writes: With the licensing pack granted: assigns a SKU to a user and removes a SKU from a user. That changes who holds a seat — it does not change how many seats the client owns.
  • list_skusEvery SKU the tenant owns with the arithmetic already done — bought, consumed, and how many seats are sitting idle.
  • get_user_licensesWhat one person is licensed for, listed by SKU part number.
  • assign_licensePut a user on a SKU, named either by its GUID or by its part number.
  • remove_licenseTake a SKU off a user and hand the seat back to the pool for someone else.
Exchange & mail2The two mailbox-level reads that answer real tickets: how a mailbox is configured, and what rules are quietly running inside it.⊘ Settings and rules only. No message, attachment, calendar item or mailbox content is readable from here, and nothing in this area writes — a hostile forwarding rule gets reported to you, not removed by the session.
  • get_mailbox_settingsOne mailbox's configuration — out-of-office state and text, time zone, working hours, and how meeting invites are handled.
  • get_mailbox_rulesThe inbox rules on a mailbox, where the quiet forward-and-delete an intruder left behind is what you're looking for.
Intune & devices12Managed hardware and the policy behind it: enrolled devices with compliance state and last check-in, the compliance, configuration and app-protection policies they're judged against, the published app catalogue — and the remote actions that follow a missing laptop.⊘ It acts on devices Intune already manages — it cannot enroll one, and it cannot create, edit or assign a compliance policy, configuration profile or app-protection policy; those four inventories are read-only and need the tenant to actually hold Intune licensing before they return anything. A device reports a compliance state, never a breakdown of which specific rule it tripped — the non-compliant list and the policy inventory are two separate reads that you line up yourself. There is no remote-control path here either: no screen, no shell, no file browsing.✎ Writes: With the device-manage pack granted: makes a device sync its Intune policy immediately, reboots it now, or remote-locks it. With the device-destructive pack granted: factory-wipes a device, which does not preserve user data though it can optionally leave enrollment intact, or retires it, which strips company data and management off and leaves the owner's personal data in place. Both destructive actions are refused until the device's exact name is echoed back.
  • list_devicesEvery Intune-enrolled device in a tenant with its OS and version, model, assigned user, compliance state, and when it last checked in.
  • get_deviceA single managed device pulled up by its id or by its exact device name.
  • list_noncompliant_devicesOnly the devices currently sitting outside compliance — the remediation list, without the healthy estate wrapped around it.
  • list_compliance_policiesThe compliance policies a tenant defines and who they're assigned to — the standard the estate is being held to, read on its own rather than joined to any one device's verdict.
  • list_configuration_profilesWhat Intune is actually pushing at the estate: the configuration profiles and the settings inside them.
  • list_managed_appsThe app catalogue published through Intune, each with its publisher and the date it was added.
  • list_app_protection_policiesApp-protection (MAM) policies — the rules that follow company data onto phones nobody ever enrolled.
  • sync_deviceTell a device to check in with Intune right now instead of waiting for its next scheduled sync.
  • reboot_deviceSend a restart to a managed device and have it happen now, rather than whenever the user next gets round to it.
  • lock_deviceRemote-lock a device so it demands its passcode again — the first move when a laptop goes missing.
  • wipe_deviceFactory-reset a device and everything on it, optionally leaving enrollment behind — destructive, and it will not run until the device's exact name is echoed back.
  • retire_devicePull company data and management off a device while the owner's own files stay put — lighter than a wipe, still destructive, still gated on that same exact-name confirmation.
Security & posture13The security review, on demand: MFA registration across the tenant and per person, who holds privileged roles, what Conditional Access and the tenant policies actually enforce, Secure Score, Identity Protection risk, and the app-and-consent inventory nobody has audited.⊘ Read-only throughout — this area reports posture, it never enforces it. No Conditional Access policy is created or switched on, no risky user is dismissed or remediated, no consent is revoked and no service principal is disabled. Some of it depends on what the client licenses from Microsoft rather than on this connection: Identity Protection risk needs Entra ID P2, and Conditional Access policies and named locations need P1 — without those, there is simply nothing for Microsoft to return.
  • mfa_registration_reportThe whole tenant's MFA registration in one answer — how many people have it, who doesn't, and which of the people who don't are administrators.
  • get_user_mfa_statusThe authentication methods one named person has actually registered — the single-user version of that report.
  • list_adminsWho holds which privileged directory role, Global Admin included — the admin-access audit an MSP is expected to have on file.
  • list_conditional_access_policiesEvery Conditional Access policy with its on/off/report-only state and its grant controls, so a coverage gap is visible without opening each one; the client needs Entra ID P1 for any of it to exist.
  • list_named_locationsThe trusted IP ranges and country locations those policies point at — another P1 feature on the client's side.
  • get_authentication_methods_policyWhich MFA methods the tenant permits at all — Authenticator, FIDO2, SMS and the rest — and how each one is configured.
  • get_authorization_policyThe tenant's default-permission posture: what an ordinary user may do, what guests can see, and whether people can consent to apps by themselves.
  • get_secure_scoreMicrosoft's own Secure Score for the tenant, current against maximum, together with the top improvement actions Microsoft publishes alongside it.
  • list_risky_usersThe accounts Identity Protection currently rates as at risk, with the level attached — Entra ID P2 territory.
  • list_risk_detectionsThe individual events behind those flags — detection type, level, IP, location and when each fired; also a P2 feature.
  • list_enterprise_appsEvery service principal standing in the tenant — the inventory of what has been integrated, shadow IT very much included.
  • list_app_registrationsThe applications registered in the tenant itself, with their sign-in audience and creation date.
  • list_oauth_grantsWho consented to what: the delegated OAuth permission grants, which is where a malicious consent shows itself.
Tenant, audit & service health7What the tenant is, what has been happening in it, and whether Microsoft's side is behaving: organization and domain facts, sign-in events, usage counts, service health, and the Message Center notices about what's changing next.⊘ Read-only, and it's a record rather than a lever — no incident is acknowledged, no Message Center post is dismissed, no tenant setting is changed here. Sign-in log access is an Entra ID P1 feature on the client's side. And there is no directory change log in this set: a session can tell you who signed in, not who edited a policy last Tuesday.
  • get_org_configThe tenant's own record — display name, verified domains, whether it syncs from on-prem AD, its type, and the plans assigned to it.
  • list_domainsThe verified domains hanging off the tenant, with the default and initial ones flagged and their capabilities listed.
  • get_signin_logsThe sign-in record for a whole tenant or narrowed to one person — app, IP, location and result on every event, readable only where the client holds Entra ID P1.
  • get_usage_reportsThirty days of active-user counts per service — the evidence for whether people use what they're licensed for.
  • get_service_healthMicrosoft's current status for every service this tenant subscribes to — the 'is it them or is it us' check.
  • list_service_issuesOpen and recent incidents and advisories for the tenant, most recently updated first.
  • list_message_centerThe Message Center posts a tenant has been sent — the roadmap and change notices that explain next month's surprise.

Connecting

Wire it in, in an afternoon.

How to connect

  1. 01Start the guided connect in the app and choose which capability packs this tenant should grant — reads on their own, or reads plus the user, licensing and device tiers.
  2. 02The client's own Global Admin walks Microsoft's admin-consent screens, one per pack, in a single sitting. Each pack is a separate Entra app registration carrying only the Graph permissions that pack needs, and any pack they decline just stays ungranted.
  3. 03Confirm the tenant back in the wizard and it's answerable from that point. Every other client tenant connects the same way, independently of this one.

Patch your stack in.

Start the Switchboard free trial against your own environment — read-only, traced answers, live in an afternoon. The apps are on the shelf when you want them.

MSPStuff