Building a Copilot agent in Microsoft Teams for onboarding and offboarding
Onboarding and offboarding are not mirror images. The architecture that treats them as one agent is the architecture that fails, and it fails in the direction that costs you the most.
·
21 min
Key findings
Onboarding and offboarding are not mirror images. An agent optimized for onboarding is permissive, fast and conversational. An agent that can offboard must be conservative, gated and evidential. Build them as one and you get the permissive one.
The moment an agent can create an account, assign a license, or disable a user, it stops being a chat interface and becomes an actuator with standing privilege in your directory.
Application permissions are not sufficient to disable a user. The service principal must also hold a directory role, which makes it a permanently present, administratively privileged object in your tenant.
Onboarding failures announce themselves. Offboarding failures are silent by construction, and the only thing standing between a silent failure and a finding is whether the system produced evidence at the time.
Knowledge 2026-01. Qwalora LLC. Every figure in this note traces to a named source with the date it was read. Where something could not be verified, it is listed as unverified rather than estimated.
Onboarding and offboarding are not mirror images. The architecture that treats them as one agent is the architecture that fails, and it fails in the direction that costs you the most.
01. What most organizations build first
The brief arrives in a recognizable shape. Human resources wants new hires to stop asking the same twelve questions in their first week. Information technology wants to stop discovering on a Thursday that someone left in March and still has a live mailbox. Somebody says the word Copilot, and within a fortnight there is a single agent in Teams called something like HR Assistant that is meant to do both.
It answers questions well. Then somebody asks it to actually do something, and the shape of the problem changes entirely.
The moment an agent can create an account, assign a license, or disable a user, it stops being a chat interface and becomes an actuator with standing privilege in your directory. That is a different system, with different failure modes, and it has to be designed as one.
1
Copilot Credit for a classic answer
2
Copilot Credits for a generative answer
5
Copilot Credits for an agent action
10
Copilot Credits for tenant graph grounding, which makes retrieval the expensive verb at ten times a classic answer
Microsoft, Billing rates and management, updated 3 August 2026, read 21 September 2026. Every row is listed as no charge for a user holding a Microsoft 365 Copilot license.
02. The asymmetry that determines the architecture
The two processes look symmetrical on an org chart. They are not symmetrical in any property that matters to an engineer.
Onboarding against offboarding, property by property
Onboarding
Offboarding
Timing: tolerant. A day late is an inconvenience.
Timing: tolerant. A day late is an inconvenience.
→
Timing: bound. The window is set by your policy, your insurer, or a regulator.
Reversibility: high. Wrong group, remove them from it.
Reversibility: high. Wrong group, remove them from it.
→
Reversibility: low. A revoked session, a deleted account, a converted mailbox.
Blast radius of a false positive: one person gets access they should not have, briefly, and it is visible.
Blast radius of a false positive: one person gets access they should not have, briefly, and it is visible.
→
Blast radius of a false positive: one person loses access they needed, immediately, and it is loud.
Blast radius of a false negative: a new hire waits.
Blast radius of a false negative: a new hire waits.
→
Blast radius of a false negative: a former employee retains access. This is the one that appears in an incident report.
Who notices: the subject, immediately.
Who notices: the subject, immediately.
→
Who notices: nobody, for months.
Evidence required afterward: rarely.
Evidence required afterward: rarely.
→
Evidence required afterward: routinely. By auditors, insurers, funders and counsel.
Read the last two rows together, because that is where the design pressure actually comes from. Onboarding failures announce themselves. Offboarding failures are silent by construction, and the only thing standing between a silent failure and a finding is whether the system produced evidence at the time.
An agent optimized for the first column will be permissive, fast and conversational. An agent optimized for the second column must be conservative, gated and evidential. Those are opposing designs. Build them as one and you will get the permissive one, because that is the one whose requirements are easier to satisfy and whose success is easier to demonstrate.
03. The architecture: three planes, not one agent
Separate the system into three planes and assign each a single job. This is not ceremony. Each plane has a different owner, a different change cadence, and a different failure mode.
The record plane decides that a state change should happen and when. This is your human resources system and, inside Microsoft Entra, Lifecycle Workflows and entitlement management. It is the system of record for joiner, mover and leaver events.
The actuation plane performs the state change. Overwhelmingly this should also be Lifecycle Workflows, because Microsoft has already built and governed the tasks you would otherwise reimplement in a flow.
The interface plane is the agent in Teams. It explains, answers, tracks status, and produces evidence. It is the plane your users touch.
The single most consequential decision in this build is how much actuation you put in the interface plane. The correct default is none.
That is not timidity. An agent that performs privileged directory operations holds standing privilege in your tenant, and the operative word is standing. Lifecycle Workflows holds the same privilege, but it holds it inside a system that is scoped to defined triggers, logged per task per user, bounded by administrative units, and designed by Microsoft for exactly this. An agent holds it behind a natural language interface that anyone in Teams can type into.
Where the joins are
Note where the seams fall in that arrangement, because they are where this goes wrong. The record plane is owned by human resources. The actuation plane is owned by identity. The interface plane is owned by whoever built the agent, which is frequently a fourth party with no operational ownership of either of the other two. Every one of those three teams can be correct about its own plane while the system as a whole fails, and the failure will present as an offboarding that did not complete.
Name an owner for the joins before you build anything.
04. Decisions to make before you open Copilot Studio
Four of these are difficult or impossible to reverse.
Harness, and this one is irreversible
Copilot Studio no longer classifies agents the way it did at the start of the year. It now classifies by harness, and the choice is permanent for that agent.
Your choice of harness affects how your agent or workflow reasons, how complex a task it can take on, what it can do out of the box, and how it’s billed.
Agents created with the GitHub Copilot harness can’t be transferred to the standard harness, and vice versa.
The three are the GitHub Copilot harness, described for “reasoning-heavy, multi-step work and complex business processes”; the standard harness, for “rule-based agents and structured, repeatable conversations”; and the Copilot chat harness, for “extending Microsoft 365 Copilot Chat with your organization’s knowledge.” [1]
For the pattern in this note, the onboarding agent is a knowledge and orchestration surface and the standard harness is sufficient. Reach for the GitHub Copilot harness only when you have a genuine multi-step reasoning requirement, and understand before you do that you are choosing it for the life of that agent.
If you have existing agents built through the Copilot Studio for Teams app, note the deprecation. Microsoft’s documentation states that after the end of June 2026 it is no longer possible to use that app to create classic chatbots. [2]
Channel
Teams and Microsoft 365 Copilot are one channel with a toggle, not two publishing paths.
After you publish your agent at least once, you can connect it to the Teams and Microsoft 365 Copilot channels so users can chat with it in both Teams and Microsoft 365 Copilot.
If you don’t select Make agent available in Microsoft 365 Copilot, your agent is only available in Teams. [3]
Teams-only is the default. Surfacing in Microsoft 365 Copilot is an explicit opt-in. Decide deliberately, because the audience is different: Teams reaches everyone, Microsoft 365 Copilot reaches the licensed population.
Who pays, and for what
This decides whether your agent is free or metered, and most organizations discover it after launch.
Declarative agents that are grounded in instructions and public websites are available at no additional cost.
Agents that access shared tenant data, such as SharePoint or Graph Connector content, are billed based on metered consumption.
Agents utilizing metered consumption are off by default for users in Copilot Chat. [4]
Read that third sentence twice. An onboarding agent grounded in your SharePoint policy library is by definition reaching tenant data, which makes it metered, which means it is off by default for every user who does not hold a Microsoft 365 Copilot license. If your population is mostly unlicensed, your agent is invisible to them until an administrator turns metered agents on.
The unit is no longer messages.
Starting on September 1, 2025, the common currency for agents changed from messages to Copilot Credits.
Copilot Credits measure the time and effort your agent needs to retrieve information, respond to prompts, and use any actions or custom skills. [5]
Microsoft’s published rate table charges a classic answer at 1 credit, a generative answer at 2, an agent action at 5, tenant graph grounding at 10, and agent flow actions at 13 per hundred. Every row is listed as no charge for a user holding a Microsoft 365 Copilot license. [6]
The operational consequence: tenant grounding is the expensive verb, at ten times a classic answer. An onboarding agent that grounds against SharePoint on every turn costs an order of magnitude more than one that answers common questions from its own instructions and grounds only when it must. Write the instructions to answer the top twenty questions without retrieval.
We are not publishing a price. The Copilot Studio pay-as-you-go rate could not be verified against a primary source during this review, and one Microsoft page still describes the retired per-message unit. Confirm your own rate in the Power Platform admin center before you model a budget.
Licensing for the record plane
Lifecycle Workflows and entitlement management are not part of Microsoft 365. Microsoft’s documentation states that lifecycle workflows require “Microsoft Entra ID Governance or Microsoft Entra Suite licenses,” [7] and that entitlement management “requires Microsoft Entra ID Governance or Microsoft Entra Suite subscriptions,” with some capabilities operating under Microsoft Entra ID P2. [8]
There is also a billing change that caught organizations earlier this year. Microsoft’s Entra release notes record that as of January 2026, enforcement of the Entra ID Governance guest billing meter is in effect for entitlement management and lifecycle workflows, requiring a linked Azure subscription to activate the governance for guests add-on. [9] If your access packages include external collaborators, that is a live cost.
05. Do not rebuild what Lifecycle Workflows already does
The most common waste in these projects is reimplementing joiner, mover and leaver tasks as Power Automate steps. Microsoft ships them. The current built-in task set includes, among others: [10]
Joiner. Send welcome email to new hire. Send onboarding reminder email. Generate Temporary Access Pass and send via email to the user’s manager.
Joiner and mover. Request user access package assignment. Assign licenses to user.
Any phase. Add user to groups. Add user to teams. Update user attributes. Run a custom task extension. Remove user from selected groups.
Leaver. Disable user account. Remove users from all groups. Remove user from selected teams. Remove user from all teams. Cancel all pending access package assignment requests. Remove all license assignments. Delete user. Revoke all refresh tokens for user. Remove access package assignment. Remove selected license assignments. A set of manager notification emails keyed to before, on and after the last day.
Two of these deserve attention.
Generate Temporary Access Pass and send to the manager is the correct first-day credential path. It removes the shared-secret problem from onboarding entirely, and it is already built.
Transfer agent identity sponsorships to manager is new, and it tells you where Microsoft thinks the risk is. Agent identities need a human sponsor, and when that sponsor leaves, sponsorship follows their manager rather than going orphaned. If you are building agents, your own agents are now objects in the leaver process. Design for that on day one rather than discovering it when the person who built your onboarding agent resigns.
Build a custom task extension only when the built-in task genuinely does not exist. Every extension you write is code you own, credentials you rotate, and a failure mode Microsoft will not diagnose for you.
06. Building the onboarding agent
This is the part that should be straightforward, and it is, provided you resist the urge to give it hands.
Scope it to what it knows, not what it does
The onboarding agent answers questions a new hire asks in their first thirty days and tracks the state of their own onboarding. It does not create accounts, assign licenses, or grant access.
The reason is not risk aversion. It is that every one of those actions is already a Lifecycle Workflow task, triggered by an authoritative event from your human resources system, with a task-level audit record. Routing the same action through a chat interface adds a natural language parser between the intent and the directory, and subtracts the authoritative trigger. You have made the system less reliable and harder to evidence in exchange for a conversational veneer.
Knowledge sources, and the governance that applies to them
Ground it in the documents that already answer the questions: the employee handbook, the IT getting-started pages, benefits documentation, the security and acceptable use policy, and your role-specific first-week checklists.
Two constraints to design around.
First, the agent inherits the user’s permissions. It surfaces to a new hire exactly what that new hire could already open, retrieved conversationally and at speed. If your SharePoint permissions are loose, the agent does not create the exposure, it makes it retrievable. Audit the permission model on every site you connect before you connect it, not after.
Second, knowledge sources are governable, and the control is now called data policies rather than DLP policies.
Use data policies to control which knowledge sources agent makers can use.
Three connectors can be classified as Business, Non-business or Blocked: knowledge source with documents in Copilot Studio, knowledge source with SharePoint and OneDrive in Copilot Studio, and knowledge source with public websites and data in Copilot Studio. There is a trap in the first one, stated plainly in Microsoft’s own documentation:
Blocking Knowledge source with documents in Copilot Studio only prevents local file uploads. It doesn’t prevent makers from adding files from SharePoint or OneDrive. [11]
An organization that blocks local uploads and believes it has closed the knowledge surface has closed one of two doors.
Instructions that hold up
Three rules produce most of the quality difference.
Answer the top twenty questions from instructions rather than retrieval. It is faster, it is more consistent, and at ten credits for tenant grounding against two for a generative answer, it is materially cheaper.
Require citation on anything policy-adjacent. A new hire acting on an uncited paraphrase of your leave policy is a problem that surfaces months later in a dispute.
Make the agent state when it does not know, and route to a named human rather than a shared mailbox. The failure mode of a helpful agent is a confident wrong answer delivered to someone with no basis to evaluate it, which describes every new hire in their first week.
The one action worth allowing
Status. Let the agent answer “where is my laptop request” or “has my access to the finance site been approved yet” by reading state. Reading is safe, it is the question people actually ask, and it removes the highest-volume ticket category without granting a single write permission.
07. Building the offboarding agent
Here the design inverts, and the sentence that should govern the entire build is this one, from Microsoft’s own Graph documentation on disabling an account:
In app-only scenarios in addition to Microsoft Graph permissions, the app must be assigned a higher privileged administrator role as indicated in Who can perform sensitive actions. [12]
Application permissions are not sufficient to disable a user. The service principal must also hold a directory role. Whatever identity your offboarding automation runs as is therefore a permanently present, administratively privileged object in your tenant with the ability to disable users, and it is reachable from a chat window if you wire it that way.
That is the finding. Everything below follows from it.
The offboarding agent does not offboard
It initiates, tracks and evidences. Lifecycle Workflows executes.
A workable division:
The agent, on request from an authorized manager. Confirms the leaver’s identity. Presents what will happen, itemized, before anything happens. Presents what will not happen automatically and requires a human. Records who asked and when. Triggers the workflow through a single bounded action.
Lifecycle Workflows. Disables the account. Revokes refresh tokens. Removes group and team memberships. Removes license assignments. Removes access package assignments. Notifies the manager on the schedule you configured.
A human. Everything in section 09.
The approval gate is the architecture
Never allow an offboarding to execute from a single conversational turn. The gate needs four properties: the requester is verified as authorized for that specific subject, the action set is displayed in full before confirmation, the confirmation is an explicit affirmative rather than an inferred one, and the whole exchange is written to a durable log that is not the chat transcript.
That last property is the one people skip. A Teams conversation is not an audit record. It is deletable, it is editable within its retention window, and it is not structured. Write the decision to somewhere you would be willing to produce under a subpoena.
Authentication
Microsoft’s guidance on connections is general rather than specific to privileged directory work:
Use application permissions (service principal): The backend calls Microsoft Graph by using app credentials. No user consent is required.
If your calls require user-specific data, use SSO. If calls are tenant-wide, use application permissions. [13]
We could not locate a Microsoft document that recommends an authentication model specifically for privileged directory operations initiated by an agent, and we could not confirm that managed identity is a supported Copilot Studio connection authentication mode. Both are listed as unverified in section 12. Do not assume either.
What we can say from the disable-account documentation is structural and does not depend on unverified guidance: any service principal that can disable accounts holds a directory role, which makes it a privileged object, which means it belongs under privileged identity management, conditional access, and a named human owner. Treat it exactly as you would treat a break-glass account, because its capabilities overlap considerably.
Agent identity is no longer optional
This changed during 2026 and it changes your inventory.
Copilot Studio automatically creates a Microsoft Entra Agent ID for each new agent you create.
Previously, you could opt out of Entra Agent ID at the environment level. Starting May 2026, all new agents have Microsoft Entra Agent IDs, and you can no longer opt out of automatic agent identity creation. [14]
Microsoft Entra Agent ID reached general availability in April 2026, described as “an identity and security framework that extends Microsoft Entra capabilities to AI agents.” [15] There is a date discrepancy in Microsoft’s own documentation, with the Copilot Studio release notes placing mandatory Agent ID at July 2026 and the administration page at May 2026. The fact is not in question; the effective date is, and we have not resolved it.
The practical consequence is that every agent in your tenant now has a directory identity whether or not anyone planned for one, those identities have human sponsors, and sponsorship transfers to the sponsor’s manager when the sponsor leaves. Your agents are now in scope for your own leaver process.
Microsoft also shipped an agent inventory in May 2026, described as an “agent inventory schema to discover and audit all Copilot Studio agents in your organization from the admin center, API, or Azure Resource Graph.” [16] Run it before you build. Most organizations that believe they have no agents have between five and fifty, built in Teams by people who had no idea they were creating directory objects.
08. Permissions, with exact strings
Least-privilege Microsoft Graph application permissions, verified 21 September 2026. Two of these changed during 2026 and older guides will give you the superseded values.
Operation
Least-privilege application permission
Source
Create a user
User.Create
[17]
Assign a license
LicenseAssignment.ReadWrite.All
[18]
Add to a group
GroupMember.ReadWrite.All
[19]
Update a user
User.ReadUpdate.All
[20]
Disable an account
User.EnableDisableAccount.All and User.Read.All, plus a directory role
[20]
Revoke sign-in sessions
User.RevokeSessions.All
[21]
User.ReadUpdate.All displaced User.ReadWrite.All as the least-privilege update permission. If your implementation is running on User.ReadWrite.All, it is over-permissioned rather than broken, and it is worth the change.
Relevant Entra built-in roles, all confirmed under their current names on 10 September 2026: [22] User Administrator, “can manage all aspects of users and groups, including resetting passwords for limited admins.” License Administrator, “can manage product licenses on users and groups.” Groups Administrator. Helpdesk Administrator. Privileged Authentication Administrator, “can access to view, set and reset authentication method information for any user (admin or non-admin).” Identity Governance Administrator, “manage access using Microsoft Entra ID for identity governance scenarios.”
License Administrator and Groups Administrator are the non-privileged pair and should carry as much of your automation as they can. Reserve User Administrator for the operations that genuinely require it.
The dependency nobody scopes
Converting a departing employee’s mailbox to a shared mailbox is a standard offboarding step and there is no Microsoft Graph API for it. Microsoft documents it as an Exchange Online PowerShell operation:
with permissions deferred to the Exchange feature permissions table. [23]
This is an architectural constraint, not a footnote. It means your offboarding automation has a PowerShell dependency, which means a runbook or an automation account, which means a second credentialed identity with Exchange recipient management rights. Scope it at design time. It is routinely discovered in week three, after the architecture is fixed.
09. What must not be automated
Five things. Each one is here because automating it creates a liability that exceeds the effort it saves.
Termination for cause. The timing, sequence and evidence preservation are decided by counsel and human resources, not by a workflow. An automated leaver process triggered by an HR record change can revoke access before a litigation hold is in place.
Mailbox and file disposition where there is any prospect of a dispute. Converting, delegating or deleting are all spoliation risks. A human decides, a human documents the decision.
Anything involving a departing administrator. Their own credentials, their standing permissions, their break-glass access, and now their agent sponsorships. The blast radius is categorically different and it deserves a manual, witnessed runbook.
The final access attestation. Somebody has to look at the list of everything the person still holds and sign that it is now empty. The agent produces the list. A named human signs it. That signature is the artifact an auditor or an insurer asks for, and an agent cannot provide it.
Any system outside the tenant. Your payroll platform, your customer relationship management, your code repositories, your building access. Agents in Teams reach Microsoft’s graph. The systems that most often retain a departed employee are the ones that never touched it, and a dashboard that reports offboarding as complete while three external systems remain open is worse than no dashboard, because it converts an open question into a false answer.
10. Failure modes to design against
The agent as an exposure lens. Covered in section 06. The permissions were always wrong; the agent made them retrievable. Audit before connecting.
The confident wrong policy answer. Mitigate with mandatory citation and an explicit do-not-know path.
Silent workflow failure. A Lifecycle Workflow task can fail for one user without failing the run. If nobody watches per-user task outcomes, you have a leaver who is reported as processed and is not. Alert on task-level failure, not run-level success.
Standing privilege drift. The service principal gets one more permission for one more edge case, four times, over eighteen months. Review its permission set on a fixed schedule and require a written justification for every addition.
Chat as the audit record. Addressed in section 07. It is not one.
The orphaned agent. Its builder leaves. Sponsorship moves to their manager, who does not know what it does, what it can reach, or that they now own it. Include agent sponsorship in your own leaver checklist.
11. How you know it works
Do not declare this live on the strength of a demonstration. Six tests, each with a stated pass condition.
Retrieval boundary. Ask the agent, as a genuine new hire account, for something that account should not be able to open. Pass: it does not surface it.
Citation. Ask five policy questions. Pass: five citations, each resolving to a current document.
Authorization on the leaver path. Attempt to initiate an offboarding as a user who is not the subject’s manager. Pass: refused, and the attempt is logged.
Gate integrity. Attempt to trigger execution without explicit confirmation, including by rephrasing. Pass: nothing executes.
Task-level failure visibility. Force a single task to fail inside an otherwise successful workflow run. Pass: an alert fires naming the user and the task.
Evidence. Run a complete offboarding end to end, then produce the record you would hand an auditor without touching the chat transcript. Pass: it exists, it is complete, and it is durable.
If test six fails, you have built an automation, not a control. The distinction matters at exactly the moment you least want to discover it.
12. What we could not verify
Stated rather than estimated.
Copilot Studio pay-as-you-go pricing. Not confirmed against a primary source during this review. One Microsoft page continues to describe the retired per-message unit while the Copilot Studio documentation describes Copilot Credits. Confirm your own rate before modeling a budget.
Lifecycle Workflows task definition identifiers. Task names are verified. The GUIDs returned during research showed patterns characteristic of fabrication and are deliberately omitted. Read them from the live documentation.
OneDrive ownership transfer. No primary source confirmed. No Graph API is known to exist for it. Treat as a manual administrative step until verified.
The Exchange Online role required for Set-Mailbox -Type Shared. The documentation defers to a permissions table not examined here.
Managed identity as a Copilot Studio connection authentication mode. No confirming documentation found. Do not assume it is supported.
A Microsoft recommendation specific to privileged directory operations initiated by an agent. The general tenant-wide guidance in [13] is the closest primary statement located.
The effective date of mandatory Entra Agent ID. Microsoft documentation gives both May 2026 and July 2026.
Sources
All read 21 September 2026.
[1] What is Copilot Studio (Overview), Microsoft Learn, page updated 22 August 2026. learn.microsoft.com/en-us/microsoft-copilot-studio/fundamentals-what-is-copilot-studio
[2] Quickstart: Create a classic agent and publish it to Microsoft Teams, updated 5 May 2026. learn.microsoft.com/en-us/microsoft-copilot-studio/fundamentals-get-started-teams
[3] Connect and configure an agent for Teams and Microsoft 365 Copilot, updated 17 August 2026. learn.microsoft.com/en-us/microsoft-copilot-studio/publication-add-bot-to-microsoft-teams
[4] Agents for Microsoft Copilot Chat, updated 18 August 2026. learn.microsoft.com/en-us/copilot/agents
[5] Standard harness licensing, updated 3 August 2026. learn.microsoft.com/en-us/microsoft-copilot-studio/billing-licensing
[6] Billing rates and management, updated 3 August 2026. learn.microsoft.com/en-us/microsoft-copilot-studio/requirements-messages-management
[7] What are lifecycle workflows?, updated 14 April 2026. learn.microsoft.com/en-us/entra/id-governance/what-are-lifecycle-workflows
[8] What is entitlement management?, updated 24 June 2026. learn.microsoft.com/en-us/entra/id-governance/entitlement-management-overview
[9] Microsoft Entra releases and announcements, January 2026 entry. learn.microsoft.com/en-us/entra/fundamentals/whats-new
[10] Lifecycle Workflows tasks and definitions, updated 19 August 2026. learn.microsoft.com/en-us/entra/id-governance/lifecycle-workflow-tasks
[11] Data policy example: configure a policy for knowledge sources for agents. learn.microsoft.com/en-us/microsoft-copilot-studio/dlp-example-5, and Configure data policies for agents, updated 15 May 2026. learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention
[12] Update user, Microsoft Graph REST API v1.0, updated 4 July 2026. learn.microsoft.com/en-us/graph/api/user-update
[13] Create and manage connections, updated 25 August 2026. learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-connections
[14] Manage Entra Agent IDs, updated 15 September 2026. learn.microsoft.com/en-us/microsoft-copilot-studio/admin-use-entra-agent-identities
[15] What is Microsoft Entra Agent ID?, updated 24 June 2026. learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id
[16] What’s new in Copilot Studio, May 2026 entry, page updated 20 August 2026. learn.microsoft.com/en-us/microsoft-copilot-studio/whats-new
[17] Create user, Microsoft Graph REST API v1.0. learn.microsoft.com/en-us/graph/api/user-post-users
[18] assignLicense, Microsoft Graph REST API v1.0, updated 23 July 2025. learn.microsoft.com/en-us/graph/api/user-assignlicense
[19] Add members, Microsoft Graph REST API v1.0, updated 14 May 2026. learn.microsoft.com/en-us/graph/api/group-post-members
[20] Update user, as [12].
[21] revokeSignInSessions, Microsoft Graph REST API v1.0, updated 23 July 2025. learn.microsoft.com/en-us/graph/api/user-revokesigninsessions
[22] Microsoft Entra built-in roles, updated 10 September 2026. learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference
[23] Convert a mailbox in Exchange Online, updated 30 May 2024. learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-user-mailboxes/convert-a-mailbox
Qwalora holds no reseller, referral or affiliate arrangement with any vendor named in this note, and takes no commission on anything it recommends.
