[Microsoft Graph] Assign one or more Microsoft 365 licences to a user. Additive, so not marked destructive — though it does consume a seat and therefore costs money, and the available count is worth reading first. Two failures are common and neither says what it means: the user must have a usage location set or the assignment is rejected, and a licence with no free seats fails rather than queueing. Use the subscribed SKU listing to find the SKU id and check remaining seats before calling this. Optionally disable individual service plans within a licence to hand out a subset of what it contains.

[Microsoft Graph] Create a new user account. Requires a display name, a user principal name (their sign-in address, which must use a domain already verified in the directory), a mail nickname and an initial password. Additive and reversible — a mistake here is deleted, and the account is recoverable for 30 days after that — which is why it is not marked destructive. Two things worth getting right at creation rather than afterwards: set the usage location, because licences cannot be assigned without one and the failure message does not say so; and leave forceChangePasswordNextSignIn on unless there is a specific reason not to, so the initial password you set does not become the one they keep. Creating the account does not licence it or add it to any group — those are separate steps.

[Microsoft Graph] Delete a user account. The account goes to the directory's recycle bin and is fully restorable for 30 days — object id, group memberships, licences and all — after which it is removed permanently. Marked destructive because it removes the person's access to everything at once and because the recovery window, while generous, does expire. For an offboarding, disabling the account and revoking its sessions is the safer sequence: it has the same immediate effect, keeps the mailbox reachable for whoever inherits the work, and can be undone the moment somebody realizes the wrong Alice was picked.

[Microsoft Graph] Get the profile of the person whose Microsoft sign-in this connection was made with — the account StackJack is acting as. Useful mainly for orientation and for diagnosing a permissions surprise: when a tool is refused and it is not obvious why, this answers "who does Microsoft think is asking", which is the first thing to establish before looking at roles. In a customer's directory it also confirms that delegated access resolved to the expected identity rather than falling back to your own tenant.

[Microsoft Graph] Get one user account in full, by object id or user principal name (their sign-in address). This is the detail view behind a name found in the listing: department, office, phone numbers, employee id, usage location, when the account was created, and whether sign-in is currently allowed. Reach for it before any change to a person — confirming you have the right Alice Smith costs one call and is the difference between resetting a password and locking out a stranger. If the answer is that no such object exists, the identifier is usually a display name rather than a sign-in address; list users with a search instead.

[Microsoft Graph] Get the person recorded as a user's manager. Worth knowing that this is a real directory relationship rather than a text field, so it is what approval workflows, dynamic group rules and access reviews actually read — and it is also what an offboarding process needs, because a departing manager leaves their reports pointing at a disabled account. A 404 here means no manager is set, which is a legitimate answer for executives and service accounts rather than an error.

[Microsoft Graph] List user accounts that have been deleted but are still recoverable. Entra ID keeps a deleted user for 30 days before removing them for good, and during that window the account can be restored complete with its object id, group memberships and licences — which is what makes an accidental deletion a five-minute problem rather than a rebuild. Each entry carries the date it was deleted, so the remaining window is easy to work out. After 30 days the account is gone and only a fresh one with a new identity can be created.

[Microsoft Graph] List users together with their last sign-in and last non-interactive sign-in times — the licence-reclamation and offboarding-audit read. Sort by the sign-in date or filter on it to find accounts nobody has used in months, which are simultaneously a cost (each may hold a paid licence) and a risk (an unused enabled account is an unwatched way in). Two cautions worth stating: this data needs Entra ID P1 or P2 in the directory being queried and comes back empty rather than erroring without it, and an account showing no sign-in at all is more often a service or shared mailbox account than a dormant human — check what it is before recommending anyone disable it.

[Microsoft Graph] List the enterprise applications a user has been assigned to, and the role they hold in each. This answers "which apps does this person have" from the directory's side rather than by asking each application, and it is what an access review or a licence-cost conversation needs. During offboarding it is also the list of third-party systems that will keep working after the Microsoft account is disabled unless each is dealt with separately.

[Microsoft Graph] List the devices registered to a user in the directory — the machines and phones their identity is attached to. Useful for confirming what a person actually works on before troubleshooting a sign-in problem, and for spotting the residue of old hardware that was replaced but never removed. Note this is the DIRECTORY's view of a device, which is not the same as Intune's management record: a device can be registered here and not enrolled in Intune, and the Intune device tools are where compliance, configuration and remote actions live.

[Microsoft Graph] List the people who report to a user. The other half of the manager relationship, and the one that matters during an offboarding: before disabling a manager's account, this is what tells you whose manager field is about to point at a dead object, which quietly breaks approval flows and any dynamic group built on the org chart. It returns direct reports only, not the whole tree beneath someone.

[Microsoft Graph] List the groups, directory roles and administrative units a user belongs to DIRECTLY. This is the fast answer to "what does this person have access to", and it is the one to start with — but read the transitive version too before concluding anything about access, because most real permission comes through nested groups that do not appear here. Direct membership is what you edit; transitive membership is what actually applies.

[Microsoft Graph] List the Microsoft 365 licences assigned to one user, with the individual service plans inside each and whether each is enabled or switched off. Two jobs this does that nothing else does as directly: it explains a missing feature (someone has the licence but the specific service plan within it is disabled), and it shows whether a licence came from a direct assignment or was inherited from a group, which decides where you would have to go to remove it. A licence inherited from a group cannot be taken off the user — you change the group membership instead.

[Microsoft Graph] List the directory objects a user owns — groups, application registrations and service principals. This is the offboarding read people forget, and the one that causes trouble months later: an application registration whose only owner has left is one nobody can manage, and its client secret will eventually expire and break whatever depends on it with no obvious owner to call. Run it before disabling anyone and reassign what comes back.

[Microsoft Graph] List every group a user belongs to INCLUDING the ones reached through nested groups — their effective membership. This is the honest answer to "why can this person open that", and it routinely returns several times what the direct listing does, because access is normally granted to a broad group that contains the narrow one somebody was actually added to. Use it for access reviews and for investigating an access surprise; use the direct listing when you are about to change a membership, since a nested one cannot be removed from the user's side.

[Microsoft Graph] List the user accounts in an Entra ID (Azure AD) directory — the starting point for almost any question about who works somewhere. Returns each user's id, display name, user principal name, mail address, job title and whether the account is enabled. Use the filter argument to narrow it rather than reading the whole directory: "accountEnabled eq false" finds disabled accounts left behind by a departure process, "userType eq 'Guest'" finds external collaborators, and "startsWith(department,'Finance')" scopes to a team. Prefer the search argument for a name someone half-remembers, because it matches across several fields at once where a filter has to name one. Note the object id and the user principal name are both accepted everywhere a user is asked for, but a display name is neither — resolve a person here first, then pass their id on.

[Microsoft Graph] Permanently remove a deleted user from the directory's recycle bin, ending the 30-day recovery window immediately. There is NO undo of any kind: the object id is gone, and an account recreated with the same name is a different object that inherits none of the original's group memberships, licences or permissions. This exists for the cases where a record genuinely must not remain — a data-deletion request, or an account created in error that should never have existed — and it should not be used to tidy up. Ordinary deletion already removes the person's access; letting the window expire on its own costs nothing and keeps the recovery option open.

[Microsoft Graph] Remove one or more Microsoft 365 licences from a user. Marked destructive because removing a licence can DELETE DATA: taking Exchange Online off an account starts a 30-day clock after which the mailbox and its contents are gone, and the same pattern applies to OneDrive. If the goal is to stop someone using an account rather than to reclaim a seat, disable the account instead and remove the licence only once the mailbox has been dealt with. A licence inherited from a group cannot be removed here at all — that one is changed by editing the group membership, and attempting it on the user fails.

[Microsoft Graph] Clear the manager relationship on a user, leaving them with none. Marked destructive because the relationship is what approval workflows and dynamic group rules read, so removing it can silently stop an approval chain or drop the person out of a group they were in by virtue of their reporting line — neither of which announces itself. Reversible by setting a manager again, provided you know who it was; read the current one before clearing it.

[Microsoft Graph] Set a new password on a user account. The password you supply takes effect immediately and the old one stops working, so this locks the person out until they are given the new one — which is why it is marked destructive despite being a routine helpdesk action. Leave forceChangePasswordNextSignIn on so the temporary password you communicate does not become their permanent one. Two limits are Microsoft's rather than StackJack's and are worth expecting: an administrator can only reset the password of a user whose own role is no higher than theirs, so a Helpdesk Administrator is correctly refused on a Global Administrator; and resetting a password does not sign the user out of existing sessions, so during an account compromise revoke their sign-in sessions as well.

[Microsoft Graph] Restore a user account from the directory's recycle bin, within the 30-day window. The account comes back with its original object id, which is what makes the restore genuinely complete rather than a lookalike — group memberships, licences and every permission granted to that id are intact, where a freshly created account with the same name would have none of them. Not marked destructive: it undoes a deletion. Use the deleted-user listing to find the object id, since the account no longer answers to its sign-in address.

[Microsoft Graph] Invalidate every refresh token and session cookie a user holds, forcing them to sign in again everywhere — browsers, Outlook, Teams, phones. This is the containment action for a compromised account, and the piece that disabling alone does not do: a disabled account's existing sessions keep working until their tokens expire, which can be hours. Marked destructive because it interrupts the person's work on every device at once. Use it together with a password reset during an incident; on its own it only buys time, since whoever has the password can sign back in.

[Microsoft Graph] Enable or disable a user's account — the standard first step of an offboarding, and the standard containment step for a compromised one. Disabling blocks new sign-ins immediately but does NOT end sessions that are already running; revoking the sign-in sessions is the companion call and both are needed to actually get someone out. Marked destructive because it locks a human out of their work, and because the same call re-enabling an account is how a mistaken disable during an incident quietly restores an attacker's access. It is reversible, unlike deletion, which is why disabling is the right thing to do first while a departure is confirmed.

[Microsoft Graph] Set or replace the person recorded as a user's manager. Additive and immediately reversible by setting a different one, so it is not marked destructive — but it is worth knowing that this relationship is load-bearing rather than decorative: approval workflows, access reviews and dynamic group rules read it, so setting it wrong quietly routes approvals to the wrong person. Assigning a new manager replaces any existing one; there is only ever one.

[Microsoft Graph] Update a user's profile details — display name, job title, department, office, phone numbers, usage location. This is a merge: properties you do not name are left exactly as they were, so it is safe to change one field without restating the rest. Not marked destructive because every field it touches is a label that can be set back. Changing the sign-in address is deliberately NOT part of this tool: renaming a user principal name affects sign-in, licensing and any system that keys on the address, and it belongs in a deliberate process rather than a general update.

[Microsoft Graph] Add a user, device, service principal or another group to a group. Additive and undone by the matching removal, so not marked destructive — but be aware of what it grants: whatever the group was assigned, including anything reached by nesting the group inside a broader one, applies to the new member immediately. Check the group's own memberships and application assignments first if the grant is not obvious. Adding to a DYNAMIC group is refused by Microsoft rather than ignored: its membership comes from a rule, and the rule is the only way in.

[Microsoft Graph] Add an owner to a group. Owners manage the group's membership and settings without needing a directory-wide administrator role, which makes this the least-privilege way to hand a team control of its own group. Additive and reversible, so not destructive — though note an owner can add themselves and anyone else to the group, so the grant is broader than it first appears when the group carries real access.

[Microsoft Graph] Create a security group or a Microsoft 365 group. Additive and deletable, so not marked destructive — but choose the kind deliberately, because it cannot be changed afterwards: a security group grants access and nothing more, while a Microsoft 365 group also provisions a mailbox, a SharePoint site and a Teams team, which is either exactly what was wanted or a surprising amount of infrastructure for a permissions container. Mail-enabled security groups cannot be created through this API at all. The creator is not automatically an owner, so set owners as a separate step, and note a new Microsoft 365 group's SharePoint site takes a few minutes to finish provisioning.

[Microsoft Graph] Delete a group. Recoverable for 30 days, then permanent. Marked destructive, and for a Microsoft 365 group the weight is much greater than the word suggests: the mailbox, the SharePoint site and every Teams conversation go with it, so this is a content deletion rather than a permissions change. Read the group first to see which kind it is, and read its effective membership to see who loses access — for a nested group that number is routinely far larger than the direct member count. If the goal is only to stop the group granting access, removing its application assignments is narrower and reversible.

[Microsoft Graph] Get one group in full by object id, including its kind, description, mail address, visibility, expiry date and — for a dynamic group — the membership rule that decides who is in it. Read this before changing a group's membership: it is what tells you whether the group is dynamic, in which case adding and removing members will be refused and the rule is the only lever, and whether it is a Microsoft 365 group carrying a mailbox and a site that a deletion would take with it.

[Microsoft Graph] List groups that have been deleted but are still recoverable. Entra ID keeps a deleted group for 30 days, and restoring one brings back its object id, its membership and — for a Microsoft 365 group — its mailbox, SharePoint site and Teams conversations. That last point is why this read matters more for groups than for users: a deleted Microsoft 365 group is not just a lost permission, it is a team's content sitting on a 30-day timer, and nobody notices until someone tries to open a file.

[Microsoft Graph] List the enterprise applications a group is assigned to, and the role it holds in each. This is the read that turns "who is in this group" into "what does this group actually get you" — membership means nothing until you know what the group was granted, and this is the directory's own answer. Pair it with the effective-membership listing to size an application's real user base, which is usually the number a licence conversation needs.

[Microsoft Graph] List the DIRECT members of a group — the users, other groups, devices and service principals added to it explicitly. This is the list you edit: a member that appears here can be removed from this group, and one that does not appear but still has access is reaching it through nesting, which the effective-membership read exposes. Note that nested groups appear as members in their own right rather than being flattened, so a short list here can still mean hundreds of people have access.

[Microsoft Graph] List the groups and directory roles that a GROUP is itself a member of — the upward view of nesting. This is what explains an access surprise that the membership reads cannot: everyone in a small team group turns out to reach a sensitive resource because that group was nested inside a broad one years ago. Read it before deleting or repurposing any group, since removing it detaches everyone inside it from whatever the parent granted.

[Microsoft Graph] List the owners of a group — the people who can manage its membership and settings without being directory administrators. Worth checking during offboarding for the same reason owned applications matter: a group whose only owner has left is one that self-service requests cannot be approved for, and for a Microsoft 365 group that quietly blocks the team's own ability to manage itself. An empty owner list is legitimate for groups managed centrally, but it is usually worth flagging.

[Microsoft Graph] List everyone who is effectively a member of a group, flattening every level of nesting. This is the honest answer to "who can actually reach this", and for an access review it is the only one worth quoting — the direct listing routinely understates it by an order of magnitude in a directory that nests groups, which most do. Use it to size the blast radius before granting a group access to something, and use the direct listing when you intend to change a membership, because someone who appears only here cannot be removed from this group.

[Microsoft Graph] List the groups in an Entra ID directory — security groups, Microsoft 365 groups and distribution lists. Groups are where access is granted in practice, so this is the starting point for almost any permissions question. Two filters earn their keep: "securityEnabled eq true" separates access-granting groups from collaboration ones, and "groupTypes/any(c:c eq 'DynamicMembership')" finds the rule-driven groups whose membership cannot be edited by hand. The response distinguishes the kinds only indirectly — a Microsoft 365 group has "Unified" in its groupTypes — and the distinction matters before any deletion, because deleting a Microsoft 365 group takes its mailbox, SharePoint site and Teams team with it.

[Microsoft Graph] Permanently remove a deleted group from the recycle bin, ending the 30-day recovery window immediately. There is NO undo: for a Microsoft 365 group this destroys the mailbox, the SharePoint site and the Teams conversation history outright, and a group recreated with the same name inherits none of it. This exists for cases where a record genuinely must not remain, not for tidying — ordinary deletion has already removed the group's effect, and letting the window expire naturally costs nothing while keeping the recovery option open.

[Microsoft Graph] Remove a member from a group. Marked destructive because it takes away access the person is relying on and nothing tells them what broke — the failure they experience is a document that will not open, not a message about group membership. For a Microsoft 365 group it also removes them from the associated Teams team and its conversations. Only DIRECT members can be removed: somebody who is in the group through nesting is refused here, and the removal has to happen in whichever group holds their direct membership. Reversible by adding them back, provided the loss is noticed.

[Microsoft Graph] Remove an owner from a group. Marked destructive because of what it can leave behind: a group with no owners at all, which nobody outside the directory administrators can then manage, and which blocks self-service membership requests and — for a Microsoft 365 group — the team's own ability to administer itself. Read the owner list first and confirm at least one will remain. Recovering from an ownerless group needs an administrator, so this is easy to undo and easy not to notice.

[Microsoft Graph] Renew a Microsoft 365 group, restarting its expiration clock. Directories with an expiration policy delete groups nobody has renewed — along with the mailbox, SharePoint site and Teams conversations — so this is the call that saves a team's content when the owner has stopped reading the renewal reminders, which is most of them. Purely additive: it extends a lifetime and takes nothing away.

[Microsoft Graph] Restore a group from the directory's recycle bin, within the 30-day window. The group returns with its original object id, which is what makes the restore complete rather than a lookalike — every permission granted to that id comes back with it, where a new group of the same name would have none. For a Microsoft 365 group the mailbox, SharePoint site and Teams conversations are restored too, though the site can take a while to reappear. Not destructive: it undoes a deletion.

[Microsoft Graph] Update a group's name, description or visibility. A merge, so properties you do not name are left alone, and every field it touches is a label that can be set back — hence not destructive. The group's KIND is deliberately not changeable here because Microsoft does not allow it: a security group cannot become a Microsoft 365 group or the reverse, and the only route between them is to create the other kind and move the membership.

[Microsoft Graph] Change the rule that decides who belongs to a dynamic group. This is the sharpest write in the family and is marked destructive for a reason that is easy to miss: the rule is not a filter on a list you can review first, it is the membership itself, so a wrong expression silently adds or removes hundreds of people the moment Entra re-evaluates it — and everything those people gained or lost access to changes with them. Read the current rule and record it before changing anything, because there is no undo beyond putting the old expression back, and a rule that returns nobody looks exactly like a rule that is still processing. Membership is recomputed asynchronously and can take minutes to settle in a large directory.

[Microsoft Graph] Approve a GDAP relationship that an indirect provider created for you as an indirect reseller. Additive — it accepts a grant rather than removing one — but understand what is being accepted: approving activates every role named in the relationship, so read the relationship first and confirm the role list is what was agreed rather than the provider's default. This is not the tool a partner uses on their own relationships; the CUSTOMER approves those through their admin portal, not through this API.

[Microsoft Graph] Grant one of the partner's security groups a set of administrative roles inside a customer's tenant. Marked destructive despite being a grant, which is deliberate and worth understanding: unlike adding one person to one group, this hands every current AND future member of that group live administrative power in somebody else's production tenant, and the customer's own directory shows only the group, never who is in it. Deleting the assignment later stops future access but undoes nothing that was already done with it. Name the narrowest group and the fewest roles that do the job — the roles must be a subset of what the relationship itself carries, and anything beyond that is refused. Assignment is asynchronous and takes a few minutes to become usable.

[Microsoft Graph] Create a GDAP relationship request for a customer. Not destructive: it creates a DRAFT in the "created" status that grants nothing at all — the customer must approve it before any access exists, and until then it is freely editable and deletable. Choose the roles deliberately anyway, because the set you name here is the ceiling for the relationship's whole life and widening it later means going back to the customer for another approval. Leave the customer tenant id empty to create a relationship any customer can accept via the invitation link; supply it to lock the draft to one specific tenant, which is the safer default. The duration is ISO 8601 between P1D and P2Y.

[Microsoft Graph] Remove an access assignment, revoking that partner group's administrative roles in the customer's tenant. Destructive: everyone in the group loses that access, and what they experience is an admin centre that stops working rather than any message explaining why. This is the RIGHT tool for narrowing access — it is far less drastic than terminating the relationship, which ends the customer engagement entirely — but check the remaining assignments first, because removing the last one leaves an active relationship that grants nobody anything and looks exactly like a platform fault. Requires the If-Match ETag from a preceding read.

[Microsoft Graph] Delete a GDAP relationship outright. Destructive and permanent — there is no recycle bin for these, and recreating one means another approval cycle with the customer. Microsoft only accepts this on a relationship that never became active; an active one must be terminated instead, which is a different tool with a different asynchronous lifecycle. In practice this is the tidy-up call for abandoned drafts and rejected invitations, and it is worth reading the relationship's status first so the refusal on an active one is expected rather than confusing. Requires the If-Match ETag from a preceding read.

[Microsoft Graph] Get one GDAP access assignment, naming the partner security group it is built on and the exact customer roles that group receives. Read it before changing or removing an assignment: the response carries the @odata.etag that the update and delete tools require, and the group id it names is where the technicians actually come from — removing someone from that group is usually the narrower fix than touching the assignment at all.

[Microsoft Graph] Get one delegated-admin customer by id, with its display name and tenant id. Use it to confirm you are pointing a customer-directory call at the tenant you think you are — the display names MSPs give relationships drift from the customer's real organisation name over time, and acting in the wrong customer's directory is the mistake this connector most needs to make hard.

[Microsoft Graph] Get one GDAP relationship in full, including the exact set of Entra role definition ids it grants, its activation and end dates, and whether it auto-extends. Read this before any relationship write for two separate reasons: the status decides which writes are legal at all, and the response carries the @odata.etag that the update and delete tools require as their If-Match value. The role list here is the CEILING — an access assignment can grant a subset of it to a technician group but never more, so a role missing from this list explains a 403 that no amount of group membership will fix.

[Microsoft Graph] Get one long-running GDAP operation by id and see whether it succeeded, is still running, or failed and why. This is the tool to poll after a write that answered with a job rather than a result; the operation id comes from the operations listing or from the Location header Graph returned on the original write.

[Microsoft Graph] Get one GDAP relationship request by id, with the action it carried and its outcome. Use it to poll after submitting a relationship for approval or terminating one: both are asynchronous, so the tool that raised the request returns before anything has actually changed, and this is what tells you whether the platform finished the job.

[Microsoft Graph] List the access assignments on one GDAP relationship — which of the partner's own security groups holds which of the customer's Entra roles. This is the answer to "who at my company can administer this customer, and as what", and it is the read every access review needs, because the relationship alone only says what the customer permitted, not who the partner pointed at it. An empty list on an active relationship is the classic half-finished onboarding: the customer has approved everything and no technician can do a thing.

[Microsoft Graph] List the service-management links for one delegated-admin customer — the per-workload administration URLs (Exchange, Teams, SharePoint and the rest) that open that customer's admin centre directly. Useful when a task genuinely needs a portal rather than an API: these are the correct deep links for the customer's tenant, which is otherwise a fiddly URL to construct by hand and easy to construct for the wrong tenant.

[Microsoft Graph] List the customers this partner can administer, as the delegated-admin surface sees them. Distinct from the relationship listing and worth knowing which you want: this is one row per CUSTOMER, so it is the clean answer to "who are my managed tenants", while the relationship listing is one row per GRANT and a customer with three overlapping relationships appears three times there. The tenant ids returned here are what every other tool in this connector accepts as its target directory.

[Microsoft Graph] List the long-running operations on one GDAP relationship. Several GDAP writes do not finish when the call returns — removing the Global Administrator role from an active relationship and terminating a relationship both hand back a job rather than a result — and this is where that job's progress lives. If a change looks like it did not take, check here before repeating it: a second attempt against an in-flight operation is how a relationship ends up in a state nobody intended.

[Microsoft Graph] List the requests raised against one GDAP relationship — the lock-for-approval, approve, reject and terminate actions and how each of them finished. This is the audit trail for how a relationship reached its current status, and the place to look when a customer says they approved something that is not active: a request sitting at "pending" means the platform is still provisioning, while "failed" means the action was rejected and the relationship never moved.

[Microsoft Graph] List every GDAP relationship this partner tenant holds — one per customer per grant, with the roles it carries, its duration and its status. This is the entry point for the whole connector: the customer tenant ids it returns are what every other tool's tenant parameter takes, and the status tells you whether that access is usable today. Filter "status eq 'active'" for the customers you can actually administer right now, or "status eq 'expiring'" for the renewal list, which is the report most MSPs never build and then get surprised by. A relationship listed as active still grants nobody anything until an access assignment maps a technician group onto it.

[Microsoft Graph] Finalize a draft GDAP relationship and lock it for the customer's approval, moving it from "created" to "approvalPending". Not destructive — it grants nothing and the customer still has to accept — but it is the point of no return for EDITING: once locked, the roles and duration can no longer be changed, and getting them wrong means deleting the draft and starting over. After this succeeds, send the customer their invitation link at https://admin.microsoft.com/AdminPortal/Home#/partners/invitation/granularAdminRelationships/ followed by the relationship id.

[Microsoft Graph] Reject a pending GDAP relationship that an indirect provider created for you as an indirect reseller. Marked destructive because it is terminal and one-way: the relationship cannot be revived, and restoring the intended access means asking the provider to create a new one and waiting for that cycle again. Read the relationship first — a rejection because the role list looked wrong costs days, where asking the provider to amend the draft costs minutes. Note that a rejected request may read back with the action "unknownFutureValue" rather than "reject", which is Graph's evolvable-enum behaviour and not a failure.

[Microsoft Graph] End an active GDAP relationship. This is the single most destructive call in the connector: it removes the partner's entire administrative access to that customer's tenant, every access assignment on it stops working, and no technician can manage that customer afterwards — including, if this was the last relationship, whoever needs to fix it. It is not reversible; restoring access means creating a new relationship and getting the customer to approve it again, which needs a human at the customer who may not be reachable. Termination is asynchronous, so the relationship moves to "terminationRequested" and then "terminated" over the following minutes; poll the operations listing rather than repeating the call. Use it for genuine offboarding, and prefer deleting individual access assignments when the goal is only to narrow who can act.

[Microsoft Graph] Replace the set of customer roles an existing access assignment grants. Destructive for the same reason a dynamic group's membership rule is: the role list IS the access, so this single call both grants and revokes — any role you omit is removed from everyone in that group, immediately and with no warning to them. Read the assignment first, decide against its current list rather than from memory, and send the full intended set; this is not an additive call. Requires the If-Match ETag from that read, which Microsoft mandates and which is what prevents two concurrent edits from silently discarding one another.

[Microsoft Graph] Update a GDAP relationship's name, duration, requested roles or auto-extension. Requires the If-Match ETag from a preceding get, which is Microsoft's requirement rather than StackJack's, and which is what stops two technicians overwriting each other on an access-control record. Not destructive, because what it can reach is bounded by status: while the relationship is "created" it is a draft nobody has access through yet, and once it is "active" the only property that can change is the auto-extension — a scheduled future expiry, reversible by setting it back, with no effect on access today. The one exception to that is asynchronous: removing the Global Administrator role from an active relationship returns a long-running operation instead of a result, so poll the operations listing rather than assuming it finished.

[Microsoft Graph] Assign licence SKUs to a group, so every member receives them automatically. This is the right way to license a role rather than a person — new starters get licensed by being added to the group and nobody has to remember — and it is additive, so not destructive. Be deliberate about the group though: the assignment applies to every current member and everyone added later, so pointing it at a broad group can consume a SKU's remaining units in one action. Assignment is asynchronous and fans out over minutes or longer; check the group's processing state rather than assuming it finished.

[Microsoft Graph] Get the licences assigned to a group and the current state of applying them to its members. Group-based licensing fans out asynchronously, so a processing state of ProcessingInProgress means members are still being licensed and an empty-looking result is premature rather than wrong. A state of ProcessingWithErrors means some members failed — usually a missing usage location or an exhausted SKU — and each affected user's own assignment states name the reason.

[Microsoft Graph] Get one purchased SKU in full, including every service plan it contains and each plan's provisioning status. Read it before a partial assignment: disabling plans is done by service plan id, those ids live only here, and guessing one produces a refusal rather than a partial licence. It is also how to answer "does this licence include Intune" without consulting a product page that may not match what the tenant actually bought.

[Microsoft Graph] Get the per-SKU assignment state for one user — where each licence came from, whether it applied cleanly, and the exact error when it did not. This is the diagnostic read of the family and the answer to the two questions the friendly licence list cannot settle. First, provenance: a state carrying a group id was INHERITED, and an inherited licence cannot be removed from the user — the removal has to happen on that group or the user has to leave it. Second, failure: an error of CountViolation means the tenant ran out of units, MutuallyExclusiveViolation means a conflicting licence is already assigned, DependencyViolation means a prerequisite plan is switched off, and ProhibitedInUsageLocationViolation means the service is not offered in the user's country.

[Microsoft Graph] List every licence SKU the tenant has bought, with how many units were purchased, how many are assigned and how many remain. This is the true-up read and the starting point for anything licensing-related: the sku ids it returns are what every assignment tool takes, and the service plans inside each SKU are what a partial assignment disables. The gap between enabled and consumed units is the number a renewal conversation turns on, and a SKU showing warning units is one already past its grace period.

[Microsoft Graph] List everyone assigned a particular licence SKU. This is the read that turns a purchased-unit count into names — the reclamation list before a renewal, and the answer to "who is this SKU actually for". Pair it with the sign-in activity on those users to find licences paid for by people who have not signed in for months, which is where most licence savings in a real tenant come from. Note this reflects assignment however it arrived, so people licensed through a group appear here too.

[Microsoft Graph] Remove licence SKUs from a group, which unlicenses every member who was relying on that group for them. The most destructive call in this family by blast radius: it is the per-user removal multiplied by the membership, so the same 30-day mailbox and file deletion clock starts for everyone who had no other source for the licence. Read the group's effective membership first to see the real number — for a nested group it is routinely far larger than the direct member count — and remember that members who ALSO hold the licence directly keep it, which is why the after-state is rarely uniform. Removal fans out asynchronously like the assignment does.

[Microsoft Graph] Re-evaluate a user's group-based licence assignments. Not destructive — it changes nothing by itself, it asks Entra to try again — and it is the specific fix for a user stuck in an error state after the underlying cause was resolved. Having bought more units, cleared a conflicting licence or set a missing usage location, this is what makes the assignment take effect rather than waiting for Entra to notice on its own schedule.

[Microsoft Graph] Add a DNS domain to the tenant. This is step one of three and on its own achieves nothing visible: Entra creates the domain UNVERIFIED, and until ownership is proven no mailbox or user can use it. Follow it immediately with the verification-DNS-records read, publish those records in the domain's zone file, and then call the verify action. Additive and reversible, so not destructive — an unverified domain added by mistake deletes cleanly because nothing references it yet. The domain name itself becomes the object's id.

[Microsoft Graph] Remove a domain from the tenant. This is the SAFE delete and it refuses while any user, group or application still references the domain — treat that refusal as the system working rather than an obstacle, and list the domain's references to see what is holding it. Removing a domain that mail is still delivered to stops that mail arriving, which is why it is destructive even when the delete succeeds. The tenant's initial onmicrosoft.com domain can never be deleted. If the refusal has to be overridden, that is the separate forcing delete, and it is a different and much larger operation.

[Microsoft Graph] Delete a domain even though objects still reference it, by RENAMING every referencing user and group onto the tenant's initial onmicrosoft.com domain first — and, unless told otherwise, disabling those user accounts. This is the most consequential operation in this family: people lose the address they are known by, mail to the old domain stops, and by default they cannot sign in afterwards. It is a separate tool from the ordinary delete rather than a flag on it, because the ordinary delete's refusal is the only thing standing between a routine tidy-up and a tenant-wide rename. List the domain's references first so the blast radius is a known number, and remove Exchange as the provisioning service beforehand or the operation fails partway. It runs asynchronously, so re-read the domain to confirm it actually completed.

[Microsoft Graph] Get one domain in full. The id is the fully qualified domain name itself — contoso.com, not a GUID — which is unusual for this API and worth knowing before an agent goes looking for an object id that does not exist. Beyond the verification flags this carries the password policy overrides for the domain (how long passwords live and how far ahead users are warned) and, on a domain mid-operation, a state block describing an asynchronous verification or force-delete still running.

[Microsoft Graph] Get the root domain a subdomain hangs off. A subdomain inherits its authentication type from its root, so when a subdomain behaves unexpectedly at sign-in this identifies the domain whose settings are actually in force. Called against a domain that is already a root, it answers empty rather than failing.

[Microsoft Graph] Get the tenant's own organization record — display name, postal address, contact emails, preferred language, default usage location, every verified domain, and the service plans the tenant is entitled to. This is the orientation read for a tenant you have just connected to, and the id it returns is the TENANT id that the organization update tool requires. Two properties repay attention on an MSP's own record: partnerTenantType states what kind of Microsoft partnership this tenant holds, and defaultUsageLocation is what stops licence assignment failing for every newly created user. Note Graph returns this as a collection containing exactly one object, so read the first entry of value rather than expecting a bare object.

[Microsoft Graph] Get the company branding applied to the tenant's sign-in experience — background image and colour, banner logo, sign-in page text, username hint and the self-service password reset links. Useful when a customer reports an unbranded or wrong-looking sign-in page, because that is almost always missing or partially configured branding rather than a fault. This returns the DEFAULT branding object; per-language overrides live in the localizations listing, and a tenant that has never configured branding answers 404 rather than an empty object, which is the expected answer rather than an error.

[Microsoft Graph] List the tenant's certificate-based authentication configuration — the trusted certificate authorities that let users sign in with a smart card or client certificate instead of a password. Relevant mainly to government and regulated customers, where an expired or missing CA in this collection is what breaks sign-in for everyone using a card. Entra permits only a single configuration object in the collection, so this returns at most one entry.

[Microsoft Graph] List the users, groups and applications whose identity references a domain. This is the impact assessment before any domain removal, and the answer to a delete that was refused: the ordinary domain delete fails while ANY object still references the domain, and this names them. Run it before considering the forcing delete, because that operation renames every object listed here onto the tenant's initial onmicrosoft.com domain and by default disables the user accounts among them.

[Microsoft Graph] Get the DNS records that make Microsoft 365 services actually work on a verified domain — the MX record mail delivery depends on, the SPF TXT record that stops the tenant's own mail being marked as spam, and the CNAME and SRV records Teams and Skype signalling need. This is the read that answers "the domain is verified, so why is mail not arriving": verification and service configuration are separate steps, and a domain can pass the first while none of these records exist. Compare each returned record against what is actually published in the zone.

[Microsoft Graph] Get the DNS records that must be published in a domain's zone file BEFORE ownership can be verified. This is step two of adding a domain and the only step StackJack cannot do for the customer: the records go into the registrar or DNS host, by a human with access to it, and the verify action fails until they have propagated. Read this immediately after creating a domain and hand the values to whoever administers DNS. These are NOT the same as the service configuration records, which come later and make mail and Teams actually work.

[Microsoft Graph] List every DNS domain associated with the tenant, with the four flags that answer most domain questions at a glance: isVerified says whether ownership was proven, isDefault marks the domain new users are created under, isInitial marks the permanent onmicrosoft.com domain Microsoft issued and which can never be deleted, and isRoot distinguishes a root domain from a subdomain. The supportedServices collection is what actually decides whether mail and Teams route to a domain, so a verified domain missing Email there is verified but not in use. Start a domain onboarding or a mail-delivery investigation here.

[Microsoft Graph] List the setting templates Entra publishes, each naming the settings it contains, their types and their default values. Read this BEFORE changing any directory setting: the update takes name-value pairs, the names are defined by the template rather than free text, and a misspelled name is accepted and silently does nothing. This is also how to see what a tenant's behaviour currently is when no settings object exists for a template — the template's defaults are what is in force.

[Microsoft Graph] List the tenant-wide directory settings currently in force — despite the endpoint's name these are not per-group settings but organization-wide policy, and they are where several answers live that people expect to find elsewhere: whether members may invite guests, whether ordinary users may create Microsoft 365 groups, the group naming and blocked-word policy, and the custom banned password list. Each entry is a template that has been instantiated and customized; a setting NOT listed here is still at its Microsoft default rather than absent. Read the setting templates to see what the defaults are and which names are valid.

[Microsoft Graph] List the per-language overrides of the tenant's sign-in branding. Each entry is keyed by a locale and replaces only the properties it sets, falling back to the default branding for the rest — so a customer reporting that one language looks wrong is describing a localization, not the default. An empty list means every language sees the default branding.

[Microsoft Graph] Promote a verified subdomain to be a root domain in its own right, so it stops inheriting authentication settings from its parent and carries its own. Marked destructive because it is ONE-WAY: Microsoft publishes no demote operation, so the previous inheritance cannot be restored through this API, and every user signing in on that subdomain is authenticated by the new settings from that moment. The subdomain must already be verified. Do this deliberately as part of a planned split — typically when an acquired business on a subdomain needs its own federation — and not to tidy up a domain list.

[Microsoft Graph] Update a verified domain's supported services, password policy or default status. The supported-services list is the property that decides whether mail and Teams actually route to this domain — Email, OfficeCommunicationsOnline and Yammer are the values that can be set here — and it REPLACES the existing list rather than adding to it, so send every service the domain should keep. Note it cannot be emptied here: an omitted or blank value leaves the current list alone rather than clearing it, which is what makes every other parameter safe to omit, so removing the last service is a portal operation rather than this tool. Making a domain the default changes which domain new users are created under and does not touch existing accounts. Federated authentication is deliberately NOT settable through this tool: switching a domain between managed and federated needs a permission this connector does not request, and getting it wrong stops sign-in for everyone on the domain.

[Microsoft Graph] Update a tenant-wide directory settings object — guest invitation policy, who may create Microsoft 365 groups, the group naming policy, the banned password list. Read the current settings first and send the FULL set of name-value pairs you want in force: the setting names come from the object's template and are not free text, and a name that does not exist in the template is accepted and silently does nothing, so a typo looks exactly like a successful change. Sending the complete set also makes the result identical whether Graph merges the collection or replaces it. The values parameter is a JSON array such as [{"name":"AllowToAddGuests","value":"false"}], and every value is a STRING even when it represents a boolean.

[Microsoft Graph] Update the tenant's organization record — the notification addresses Microsoft uses to reach the customer, the postal address, and the preferred language. The technical notification address is the one worth getting right on every tenant an MSP manages: it is where Microsoft sends service incidents and expiry warnings, and left pointing at a departed employee those notices go nowhere. This is a merge, so properties you omit are left alone, and it needs the tenant id that graph_get_organization returns. Read-only properties such as the tenant id, creation date and verified-domain list are refused by Graph with a message naming the property.

[Microsoft Graph] Prove ownership of a domain by having Entra look for the verification record in its public DNS. Step three of adding a domain, and it succeeds only once that record has been published AND propagated — a failure here usually means DNS has not caught up rather than that anything is wrong, so re-read the verification records and check them against the live zone before assuming a fault. Not destructive: it grants a capability rather than removing one. Note that a successful verification does NOT configure the domain for Microsoft 365 — mail, SharePoint and Teams each need their service configuration records published afterwards.

[Microsoft Graph] Add a certificate credential to an app registration, for rolling an expiring certificate without downtime. Adding a certificate hands whoever holds its private key the ability to authenticate as this application with all of its permissions, which is why this is Pro and flagged destructive even though it removes nothing. Two hard requirements from Microsoft: only the PUBLIC key should ever be uploaded, and the request must carry a proof — a self-signed JWT signed with the private key of a certificate already on this application. An application with no existing valid certificate cannot use this action at all and must be updated through graph_update_application instead, which is the supported path for the first certificate.

[Microsoft Graph] Add a user as an owner of an app registration. Additive and reversible, so not destructive — but understand what it grants: an owner can change the application, add credentials to it and therefore authenticate as it, without holding any directory role. Prefer at least two owners on anything business-critical, because an application whose only owner leaves is one nobody can renew a secret for.

[Microsoft Graph] Generate a new client secret for an app registration and return its value. Microsoft generates the secret — it cannot be chosen — and the response is the ONLY time the value is ever shown: no later read recovers it, and a lost secret can only be replaced, not retrieved. Treat the response as a credential: whoever holds it can authenticate as this application with every permission the app has been consented, without a sign-in, an MFA prompt or a conditional-access check. Always set an end date; an omitted one gives Microsoft's default of two years, which is longer than most of the projects these get created for.

[Microsoft Graph] Add a certificate credential to a service principal, for rolling an expiring certificate. Whoever holds the matching private key can then authenticate as that application in this tenant, which is why this is Pro and flagged destructive despite removing nothing. Requires a proof — a self-signed JWT signed with the private key of a certificate already on this principal — and cannot be used at all on a principal with no existing valid certificate; that case goes through the service principal update instead. Upload the public key only.

[Microsoft Graph] Add a user as an owner of a service principal. Additive and reversible. Be aware of what it means on a principal holding broad application permissions: an owner can add a credential to it and then authenticate as that application, so ownership of a highly-permissioned principal is equivalent to holding its permissions.

[Microsoft Graph] Generate a new client secret on a service principal and return its value — the same one-time disclosure as the app-registration version, and the same warning: this response is the only time Microsoft ever shows the secret. Adding a secret to a service principal is worth a second thought, because it is the local identity of an application that may be published by somebody else: a secret here authenticates as that application in THIS tenant, with whatever it has been granted here. For an app the tenant owns, the credential normally belongs on the app registration instead.

[Microsoft Graph] Register a new application in this directory. Creating the registration is additive and harmless on its own — a new app with no credentials, no permissions and nobody consented can do nothing. Two properties are worth setting deliberately: signInAudience decides whether only this tenant can use it or any Microsoft work account can, and changing it later is restricted; and requiredResourceAccess declares the permissions the app will ASK for, which grants nothing by itself and still needs consent. Creating an application does not create its service principal — an app registration with no service principal cannot sign in to its own tenant.

[Microsoft Graph] Consent to delegated permissions for a client application, on behalf of one user or of everyone in the tenant. Destructive because of what an AllPrincipals grant is: administrator consent for the whole directory, letting the application act as any user for the scopes named, immediately and without anyone being asked. Scopes are a space-separated list and must be permissions the resource application actually publishes — read them from the resource service principal's oauth2PermissionScopes rather than guessing, because an unrecognized scope is accepted into the grant and simply never works. Both clientId and resourceId are service principal OBJECT ids, not client ids.

[Microsoft Graph] Create a service principal for an application in this directory — giving an existing app registration an identity here so it can sign in and be assigned access. The only required property is appId, the CLIENT id of the application. This is what an app registration needs before anything can authenticate as it in its own tenant, and it is also how a multi-tenant application is provisioned into a customer directory ahead of consent. Creating the principal grants it nothing; permissions still arrive through consent or assignment.

[Microsoft Graph] Delete an app registration into the 30-day recycle bin, where it can be restored with its object id, client id and credentials intact. Destructive despite being recoverable: everything authenticating as this application stops working the moment it is deleted, and because those are integrations rather than people, the failure usually surfaces as a scheduled job that silently stopped rather than as somebody complaining. Check the sign-in logs for the app's client id before deleting anything that looks unused. Deleting the application does NOT delete its service principals in other tenants.

[Microsoft Graph] Revoke a delegated permission grant entirely. This is the remediation for an illicit-consent finding, and it takes effect for everyone the grant covered as soon as their current access tokens expire — up to about an hour, which is why disabling the service principal is the stronger containment when an application is believed to be actively malicious. Destructive by the standing access-removal rule: revoking a legitimate grant breaks the application for every user of it, and restoring it means re-consenting rather than undoing.

[Microsoft Graph] Delete an application's identity in this tenant, taking its consent grants and role assignments with it. The application stops working here immediately for everyone. Prefer disabling first: it has the same containment effect, is reversible with one call, and leaves the assignments intact if the app turns out to be legitimate. Deleting the service principal does not delete the application registration, and for a Microsoft first-party service the principal is often recreated automatically the next time the service is used — with none of its previous assignments.

[Microsoft Graph] Get one app registration in full: its redirect URIs, the API permissions it requests, its credentials and their expiry dates, and whether it is single- or multi-tenant. Read it before changing anything about the app, and read it when an integration breaks after a change — a mismatched redirect URI and an expired secret produce different sign-in failures that look identical from the outside. Note that the secret VALUES are never returned by any read: Microsoft shows a client secret exactly once, when it is created.

[Microsoft Graph] Get one service principal in full — an application's identity inside this specific tenant. The properties that matter most in an investigation are accountEnabled (whether the app can sign in at all), appRoles and oauth2PermissionScopes (what it can be granted), and appOwnerOrganizationId, which names the tenant that published it and is how a genuine Microsoft service is told apart from a third-party app with a Microsoft-sounding name. Disabling this object is what stops an application working in this tenant without affecting anyone else who uses it.

[Microsoft Graph] Assign an app role on a resource application to a user, group or service principal. This one call covers two quite different jobs, and which one it is depends entirely on the principal. Granting a role to a USER or GROUP is ordinary access management — it is how people are given access to an application that requires assignment. Granting one to a SERVICE PRINCIPAL is the sharpest act in this connector: it hands an application a tenant-wide APPLICATION permission such as Mail.Read or Directory.ReadWrite.All, which works with no user signed in and is therefore limited by nobody's role and no conditional-access policy. Destructive either way, and worth stating which you are doing before you do it. All three ids are object ids: the resource service principal that DEFINES the role, the principal receiving it, and the appRole's own id from that resource's appRoles collection.

[Microsoft Graph] List the owners of an app registration — the people who can change it, add credentials to it and consent on its behalf without holding any directory role. Ownership is the quiet privilege in an Entra tenant: it is granted once during a project and survives the project, so an offboarding review that checks only role assignments misses it entirely. An application whose only owner has left the company is the other finding worth acting on, because nobody can renew its expiring secret.

[Microsoft Graph] List the app registrations defined in this directory — the applications the tenant itself owns, not the third-party apps it merely uses. This is the inventory behind "what have we built or registered", and the read to start any credential-expiry audit from: each application carries its passwordCredentials and keyCredentials with their end dates, so the registrations whose secrets expire this month are visible here before the integration they power stops working. Filter on appId to resolve a client id someone quoted from the portal into the object this family's other tools take.

[Microsoft Graph] List every delegated permission grant in the directory — the tenant-wide consent inventory. Use this rather than the per-app listing when the question is "what has anyone consented to here", which is the sweep after a phishing report: filter on consentType eq 'AllPrincipals' to see only the grants an administrator made for everyone, or on a principalId to see what one user consented to on their own behalf. Each grant names a clientId and a resourceId, both service principal object ids, so resolving them through the service principal reads turns the answer into names.

[Microsoft Graph] List app registrations in the 30-day recycle bin. A deleted application is recoverable for 30 days and permanently gone afterwards, and the deletion does not announce itself — the usual way this read gets used is an integration that stopped working with no configuration change, where the application it authenticated as is sitting here. Restoring it keeps the same object id, client id and credentials, so nothing downstream needs reconfiguring.

[Microsoft Graph] List the app-role assignments made ON this service principal — who has been given a role in this application. For an app with defined roles this is its access list, and for an app configured to require assignment it is the complete set of people who can sign in to it at all. The principalType on each entry says whether the assignment reached a user directly, a group (in which case its membership is the real answer), or another application.

[Microsoft Graph] List the app-role assignments GRANTED TO this service principal — the application permissions it holds against other APIs, such as Mail.Read or Directory.ReadWrite.All over the whole tenant. These are the permissions that work with no user signed in, so they are not limited by anyone's role or conditional-access policy, and they are the ones worth auditing first. Each assignment names the resource it applies to and the appRoleId; resolve that id through the resource service principal's appRoles to get the permission's readable name.

[Microsoft Graph] List the delegated permission grants for one client application — what it may do on behalf of a signed-in user. The consentType is the property to read first: AllPrincipals means an administrator consented for the entire tenant and every user is covered, while Principal means one named user consented for themselves. The scope string holds the actual permissions as a space-separated list. This is the read that answers "what did we agree to give this app", and an AllPrincipals grant carrying Mail.Read or Files.ReadWrite.All on an app nobody recognizes is the classic illicit-consent finding.

[Microsoft Graph] List the owners of a service principal. Distinct from the app registration's owners and frequently a different set of people: ownership here is local to this tenant and carries the ability to add credentials to the principal, which means authenticating as that application with whatever it has been granted. Worth checking on any service principal holding broad application permissions, because an owner of such a principal is effectively holding those permissions too.

[Microsoft Graph] List the service principals in a directory — every application that has an identity in this tenant, including Microsoft's own first-party services and every third-party app anyone has consented to. This is the read behind "what applications have access to this tenant", and the honest answer in a real customer is hundreds, most of them Microsoft's. Filter on appId to find a specific app, or on accountEnabled to find principals someone disabled. Note that Microsoft serves this collection 100 objects at a time whatever page size is requested, so a full sweep takes many pages.

[Microsoft Graph] Permanently remove a deleted app registration from the recycle bin. There is no recovery of any kind after this — a replacement registration gets a NEW client id, which means every consent, every credential and every configuration file naming the old one has to be redone in every tenant that used the app. A separate tool from the ordinary delete on purpose: recoverable and permanent deletion are different decisions, and a flag on one tool is something an agent gets wrong in a single token.

[Microsoft Graph] Remove a certificate credential from an app registration. Anything authenticating with that certificate fails from this moment, and re-adding the same certificate later is a fresh upload rather than an undo. Like the matching add, this requires a proof — a self-signed JWT signed with the private key of a certificate still valid on the application — so removing the LAST certificate through this action is not possible; that case goes through graph_update_application. Confirm the replacement is in use before removing the old one.

[Microsoft Graph] Remove an owner from an app registration. Destructive by this connector's standing rule that taking access away is the sharper direction: removing the last owner leaves an application only a Global or Application Administrator can maintain, and the consequence surfaces months later when its secret expires and nobody can renew it. List the owners first and confirm somebody else remains.

[Microsoft Graph] Delete a client secret from an app registration by its keyId. Everything currently authenticating with that secret stops working immediately and cannot be made to work again — the value is unrecoverable, so the only remedy is a new secret and a configuration change everywhere it was used. During a rotation, add the replacement and confirm it is in use BEFORE removing the old one; the keyId comes from reading the application, and choosing the wrong entry from a list of similar-looking secrets is the mistake this call does not let you undo.

[Microsoft Graph] Remove a certificate credential from a service principal. Anything authenticating with it fails from this moment. Requires a proof signed with a certificate still valid on the principal, so the last certificate cannot be removed this way. Confirm the replacement is in use first.

[Microsoft Graph] Remove an owner from a service principal. Destructive by the standing rule that removing access is the sharper direction — and the failure mode here is delayed rather than immediate: nobody notices until a certificate needs rolling and the people who could do it are gone. List the owners first.

[Microsoft Graph] Delete a client secret from a service principal by its keyId. Whatever was authenticating with it fails immediately and the value cannot be recovered, so during a rotation the replacement should be added and confirmed in use first. The keyId comes from reading the service principal.

[Microsoft Graph] Restore an app registration from the 30-day recycle bin. The restored application keeps its object id, client id, credentials and consent grants, so integrations that authenticate as it start working again with no reconfiguration anywhere. Not destructive — it puts something back. Only works within the 30-day window; after that the registration is unrecoverable and a replacement needs a new client id and fresh consent from every tenant that used it.

[Microsoft Graph] Remove an app-role assignment, revoking that access. For a user or group it takes away their access to the application, which they experience as the app disappearing or refusing them. For a service principal it removes an application permission — the correct remediation when an app is found holding more than it needs, and the one to reach for after an application-permission audit. Effective on the next token the application requests rather than instantly, so an app holding a current access token keeps the permission for up to about an hour; disabling the service principal is the immediate containment. The assignment's own id comes from the two app-role listings.

[Microsoft Graph] Turn an application's sign-in on or off in this tenant. This is the containment action for a compromised or unwanted application — faster and more complete than revoking individual consent grants, because nothing can authenticate as the application here at all while it is disabled, and it is reversible by setting it back. Destructive because disabling is instant and tenant-wide: every user of that app loses it at once with a sign-in error that names the app rather than explaining the cause, so confirm which application the principal belongs to before disabling anything that is merely unfamiliar. Most principals in a tenant are Microsoft's own first-party services.

[Microsoft Graph] Update an app registration's properties. Graph merges rather than replaces at the top level, so an omitted property is left alone — but a nested object supplied in full REPLACES what was there, which is the trap on this particular resource: sending a web object with one redirect URI removes every other redirect URI the app had, and the sign-ins that used them fail immediately with an error that names the URI rather than the deletion. Read the application first and send the complete list. This is also the supported way to add a CERTIFICATE to an app that has none, because the dedicated key tools cannot be used until one valid certificate already exists.

[Microsoft Graph] Replace the scopes on an existing delegated permission grant. The scope string is the whole state rather than a list to append to, so whatever is sent becomes the complete set and every permission left out is revoked — read the grant first and send the full list including the ones being kept. Destructive in both directions for that reason: this call both grants and removes, and a shortened string looks like a successful update while breaking the parts of an application nobody tested.

[Microsoft Graph] Update a service principal's local properties — its display name in this tenant, its notes, its home-page URL, its tags. Deliberately does NOT change whether the application can sign in: that is a different decision with a tenant-wide consequence and has its own tool. The property most worth knowing here is appRoleAssignmentRequired, which when true means only assigned users and groups can use the application at all — a real access control, and turning it on without first assigning anybody locks everyone out of that app.

[Microsoft Graph] Activate a directory role in this tenant from its template, creating the role object so members can be added to it. Not destructive and grants nobody anything — it makes a role that Entra already defines available to assign. This is the fix for "that role does not exist in this tenant", which is what the directory-role listing reports for any role nobody has ever been assigned. Takes the roleTemplateId from the role-template listing.

[Microsoft Graph] Activate a role the signed-in user is already eligible for — the just-in-time elevation at the centre of Privileged Identity Management. The principalId must be the signed-in user's own object id; this action cannot activate anybody else's eligibility, which is what makes it self-service rather than a grant. Destructive because the result is real administrative power, live immediately for the duration requested. Two conditions come from the role's PIM policy rather than from this call: it can require approval, in which case the request sits pending until a human acts, and it can require the caller to have completed multifactor authentication in the current session.

[Microsoft Graph] Add a user, group or service principal to a directory role, granting that role's administrative permissions permanently and immediately. Destructive despite being an addition, and for the reason the whole connector applies to privilege grants: this hands someone power over other people's accounts, and removing the membership afterwards undoes nothing they did while they held it. Read the role definition before granting, and prefer the least-privileged role that covers the task — Global Administrator is rarely the correct answer and is the hardest grant to walk back. In a tenant using Privileged Identity Management, a permanent grant here bypasses the approval and time limits that PIM exists to impose.

[Microsoft Graph] Assign a directory role through Privileged Identity Management with a time limit — an ACTIVE grant that expires on its own. This is the right shape for temporary administrative access: a contractor for the length of a project, or a technician for the duration of an incident, without depending on anyone remembering to revoke it. Supplying neither a duration nor an end date creates a PERMANENT assignment, which is the same thing as an ordinary grant and defeats the point of using this tool. Re-issuing this call with a new schedule is also how an existing assignment is extended or renewed.

[Microsoft Graph] Create a unified RBAC role assignment — the way to grant a role SCOPED to part of the directory rather than all of it. The directoryScopeId is the reason to use this over the directory-role membership tool: "/" grants tenant-wide, while an administrative unit id confines the grant to that unit's members, and an application object id confines it to that application. Scoping is the single most effective way to reduce the blast radius of an administrative grant. Destructive as every privilege grant here is.

[Microsoft Graph] Create a custom directory role from a set of resource actions. Not destructive: a definition nobody has been assigned grants nothing. The care belongs in the actions chosen — take them from the built-in role definitions rather than inventing strings, because an action that does not exist is accepted into the definition and simply never grants anything, producing a role that looks correct and does nothing. Custom roles need Entra ID P1 in the directory.

[Microsoft Graph] Give up a role the signed-in user activated, before it expires on its own. The one write in this family that is NOT destructive, and the exception is narrow: it removes only the CALLER's own just-in-time activation, nobody else loses anything, and the same person can activate again in one call because the underlying eligibility is untouched. Good practice after finishing privileged work rather than holding the role for the rest of its window.

[Microsoft Graph] Remove a unified RBAC role assignment, revoking those permissions immediately. Takes the assignment's own id from the assignment listing rather than a principal and role, which is deliberate on Microsoft's part: one person can hold the same role at several scopes, and naming the assignment is the only way to remove exactly the one intended.

[Microsoft Graph] Delete a custom role definition. Everyone assigned it loses those permissions at once, and because a custom role usually exists to give a specific team a specific capability, the people affected are the ones who will notice fastest. List the assignments for this definition before deleting. Built-in roles cannot be deleted.

[Microsoft Graph] Get one activated directory role by its object id, including the roleTemplateId that identifies WHICH Entra role it is. The template id is the stable, tenant-independent identifier — Global Administrator is 62e90394-69f5-4237-9190-012177145e10 in every tenant on earth — while the object id differs per tenant. When comparing role configuration across customers, compare template ids.

[Microsoft Graph] Get one role definition with its full permission set. Read it before granting the role to anybody: rolePermissions lists the exact allowedResourceActions, and the difference between two similar-sounding roles is usually one action that matters — the ability to reset another administrator's password, or to consent to application permissions on the tenant's behalf.

[Microsoft Graph] Get one PIM policy, expanding its rules — which is where the settings that matter actually live. The rules are what say whether activation needs approval and from whom, whether MFA or a justification is required, the maximum activation duration, and whether permanent assignment is allowed at all. Reading the policy without expanding rules returns its name and scope and none of that, which reads as an empty policy rather than an unexpanded one.

[Microsoft Graph] List who holds a directory role. This is the answer to "who are the Global Administrators here", the first read of any tenant security review, and the number Microsoft recommends keeping under five. Two cautions: members can be service principals as well as people, and an application holding a privileged role is easy to miss in a list of names; and this shows PERMANENT membership, so a tenant using Privileged Identity Management will show far fewer administrators here than can actually become one — the eligibility schedules hold the rest. This collection is returned whole with no paging.

[Microsoft Graph] List every directory role Entra defines, whether or not this tenant has ever used one. This is the catalogue — the place to find a role's template id and its description before granting it, and the answer to "which role is the least privileged one that can do this". Granting Global Administrator because it was the recognizable name in a list is the single most common over-privileging mistake in Entra, and reading this first is what avoids it.

[Microsoft Graph] List the directory roles that are ACTIVE in this tenant. Not the catalogue of roles that exist in Entra — only the ones this tenant has ever used, because Entra activates a role lazily the first time somebody is assigned to it. A role missing from this list has no members by definition, which is why "that role is not in the list" almost never means what it appears to. For the full catalogue, read the role templates instead. This collection is returned whole with no paging.

[Microsoft Graph] List the role assignments in effect right NOW — the closest thing this API offers to "who is an administrator at this moment". This is the read for an incident: it includes people currently elevated through a just-in-time activation, who are absent from the permanent assignment listing and present here only until their activation expires. Comparing this against the eligibility instances is what separates "is an administrator" from "could be one".

[Microsoft Graph] List the requests that assigned, activated, extended or removed role assignments — the PIM audit trail, including every self-activation with the justification the person typed. This is the read behind "who elevated to Global Administrator last night and why", and the one to reach for when an approval is believed to be stuck: a request in PendingApproval status is waiting on a human, and its justification and ticketInfo say what it was for.

[Microsoft Graph] List the scheduled role ASSIGNMENTS — active grants managed through Privileged Identity Management, including the ones with an expiry date. The assignmentType property is the one to read: Assigned means a standing grant, while Activated means the person elevated from an eligibility and will drop back when it expires. A tenant with many Assigned entries carrying no end date is running PIM in name only.

[Microsoft Graph] List unified RBAC role assignments — the permanent grants, including the SCOPED ones that the directory-role member listing cannot express. Filter by roleDefinitionId to answer "who holds this role" or by principalId to answer "what does this person hold"; expanding the principal turns the object ids into names in the same call, which is usually worth doing. The directoryScopeId is what makes this read worth having: "/" means the whole tenant, while anything else scopes the grant to one administrative unit or application, and a scoped Helpdesk Administrator is a very different finding from a tenant-wide one.

[Microsoft Graph] List the unified RBAC role definitions — every built-in Entra role plus any custom roles this tenant has defined, each with the exact permissions it carries in rolePermissions. Unlike the directory-role listing, this is complete whether or not a role has ever been used. Filter on isBuiltIn eq false to see only the tenant's own custom roles, which are worth reviewing on their own: a custom role is where an over-broad permission hides behind a reassuring name.

[Microsoft Graph] List the role eligibilities that are in effect right NOW, as opposed to the schedules that define them. The distinction matters when eligibility is time-bounded: a schedule starting next month or expired last week still exists as a schedule and is absent from this collection. Use this when the question is what a person can currently elevate into, and the schedules listing when the question is what was arranged.