Choose the right chat surface, verify who’s asking, and track the request through to completed IT work.
A Teams channel, a personal chat with an agent, and Microsoft Copilot can look like three doors into the same help desk. They aren't. Each one carries a different amount of information about who's asking, who else is listening, and what the agent is allowed to reach.
So the first decision in IT self-service in Teams and Copilot isn't the chat window. It's the job. Decide what a completed request should give the employee, then choose a surface that can establish the identity the job requires. The rest of this guide gives you a surface matrix, one worked access request, and a checklist that separates “answered,” “submitted,” and “done.”
Start with the job the request needs done
Not every request needs the agent to change anything. “How do I install the design plug-in?” is resolved by a correct answer from approved knowledge. Forcing a ticket or a system change onto that question adds work without adding value.
Other requests depend on the person. “Why can't I open the design app?” needs the agent to know which employee is asking before it reads their account. “Add me to the Design-Tools app group” goes further: it asks for a change that someone has to authorize, execute, and confirm.
The surface choice follows from the right-hand column.
Which Microsoft Teams surface fits which IT job?
The answer depends on the product you deploy and how it's configured. The clearest public documentation covers agents built in Microsoft Copilot Studio and Microsoft's own Employee Self-Service agent.
The matrix reflects documented limits checked on October 21, 2026. The Copilot Studio publishing guide covers “standard harness” agents; test other agent runtimes separately. These aren't rules for every Teams app or vendor.
Two details matter in practice. Microsoft's Employee Self-Service agent is currently designed for Microsoft Copilot, and its publishing guide says it isn't supported in the standalone Teams experience. And a custom Teams app or another vendor's agent may handle identity differently, so treat every “test” cell as a test, not an absence.
A shared channel still has a job. It can answer the public question and offer a private next step, either an approved 1:1 sign-in path or a human. That routing is part of the larger picture of where IT self-service lives across your systems.
One access request, from chat message to confirmed change
Here's a fictional request, used only to show the method. The names, IDs, and times are illustrative, not from a real deployment.
At 9:12 AM, an employee posts in a shared design channel: “Add me to the Design-Tools app group – I'm on design now.” The agent replies in the channel without checking or revealing anything about that person: “I can help with that privately. I've sent you a direct message.” Every other participant sees only that.
In the 1:1 chat, three questions come before any action.
Who's asking? Being signed in to the Teams client proves the person signed in to Teams. It doesn't mean the agent received a token for that person.
The agent needs a verified principal, such as a validated user ID from your identity provider, attached to this exact message. A display name doesn't qualify, because names can repeat or change.
Are they eligible to ask? “I'm on design now” is a claim, not an entitlement. The agent reads the human resources (HR) system of record, which shows a transfer to Design effective October 19.
The group's approved policy says Design members may request access and the current manager must approve. The employee doesn't need directory admin rights to request. They need to be eligible.
Who can make the change? An executor identity holds permission to add members to this one group under this policy. It doesn't borrow a broad service credential to skip the employee's eligibility. The approval request goes to the manager named in the HR record, not one the employee suggests.
The agent's closing message matches the postcondition. The employee asked for group membership, so the agent reports confirmed membership. It doesn't say the app is ready, because a group record isn't proof that a paid feature works.
If the employee had asked to use the app, the postcondition would change. The agent would need to show authorized use, such as an assigned seat and a successful sign-in to the app. If no seat were free, the honest state is pending. It would name the license owner and the next step, not “done.”
The flow ends differently when the record disagrees. If HR still showed Marketing, the agent would decline privately, say which record it checked, and point them to their manager. It wouldn't add them on the strength of the message. This is the gap between reading documents and reading systems that AI for IT support has to close.
A checklist from verified identity to completed work
Use one row per state. Each row asks for evidence, and each names what doesn't count. You can merge rows for your own forms, but don't merge “answered,” “submitted,” and “completed within entitlement.”
The last row separates ownership from completion. A license owner accepting a seat task means the work has an owner. It doesn't mean the employee can work.
What breaks: the sign-in, the entitlement, or the action
For this evaluation, separate failures into three groups, each with a different owner. Name that owner so the next person knows where to take the failed request.
Sign-in failures belong to the identity or Microsoft 365 admin. The agent got no verified principal, maybe because SSO isn't configured on that surface or the request came from a shared thread. The agent can still answer public questions. For anything personal, it offers the private 1:1 path or a human, and doesn't guess who's asking.
Entitlement failures belong to the resource owner or the owner of the HR data. The requester isn't eligible, or the record is stale. The agent declines with the reason privately and routes the record question to whoever can fix it. It doesn't override policy because the request sounds reasonable.
Action failures belong to the owner of the system being changed. The queued job failed, timed out, or never showed up on read-back. The agent reports the real state, follows the retry policy, and escalates with the request ID and evidence attached. It never closes the request as done.
Questions for any vendor demo, including Computer
Bring this checklist to every evaluation. It applies to Microsoft's tools, third-party agents, and Computer, by DevRev alike. Ask the vendor to run one safe, fictional request like the one above, live, on the surface your employees will actually use. The broader service desk automation use case is useful context; it does not establish that the exact Teams surface or action you need is supported.
- Which surface are you showing, and is that path native or configured for this demo?
- Where does the verified principal come from, and how is it bound to the exact message?
- What happens when the same request starts in a shared channel?
- Which source decides eligibility, and when is it rechecked?
- What identity executes the change, and what's it allowed to touch?
- How do you tell a queued job from a confirmed change?
- What evidence closes the request, and who sees it?
For Computer, judge the answers on the configuration you're shown, not on a feature list. Don't assume any Teams presence, identity setup, or system change works unless you see it on your own test request. Where the answers feed a purchase decision, line them up with your committee's enterprise AI agent buying criteria.
Where your current path stops
Pick one access request your service desk handled last week. Trace it from the first message to the moment the employee could actually work. Note where identity was assumed, where eligibility was taken on trust, and where “submitted” was reported as “done.”
That stopping point is your real deployment requirement, whichever surface you choose.
Comparing deployments? Bring one scoped Teams request and walk it, live, from a verified-identity question to confirmed, accepted IT work. Ask what a demonstration can cover before assuming it supports your surface or action.