Copilot Studio Itsm Agent

Autonomous IT Service Desk for Small & Medium Business

A ServiceNow-style IT help desk that runs entirely on the Microsoft 365 you already pay for — no separate ticketing subscription, no per-agent SaaS fees.

> 🏆 Winner — Microsoft Agent Academy Hackathon. Read the announcement

> 🎥 See it in action: Watch the demo

> ⚠️ Project status — working proof of concept. Built in a tight timebox to prove the architecture end to end — and it does: the core ticket → triage → approve → execute pipeline runs on a live Microsoft 365 tenant. It is not production-hardened. Expect rough edges off the happy path, and some paths are designed and specced rather than fully tested — the repo is explicit about which (see the "Designed and specced, but not yet wired" section and the per-flow "Pilot deviations" tables). Treat it as a reference build to learn from and adapt, not a turnkey product.

Recent improvements

• When a request is missing detail, the agent asks for it with an approval card instead of dead-ending. You answer in the box and it re-checks automatically — or cancel, and it closes cleanly. Works for catalog requests and form tickets.
• Outcome messages read in plain English ("your request is done" / "couldn't be completed"), with a service-desk note, the ticket and request numbers, and a link.
• Every page shows a ticket number you can quote when you follow up; the detail view shows the ticket and request numbers together.
• A request the automation can't fulfil goes to an IT Service Desk queue — a new portal page where a fulfiller marks it done or declines — instead of dead-ending. It's logged as catalog demand so you can see what's worth automating next.
• The Service Desk queue shows each hand-off as Request / For / Why, not raw data.
• When a request can't be fulfilled, the ticket is closed honestly — not marked resolved. You're told, and the service desk is alerted. Before, a failure could look like success.

🔍 The problem

Most ITSM platforms (ServiceNow, Jira Service Management, Zendesk) charge per seat, per month, and quickly run into the thousands a year. For a small or medium business, that's hard to justify for what is mostly password resets, group adds, and license requests. This project does the same job on tools an M365 tenant already has — SharePoint, Power Automate, and Copilot Studio — and automates the routine work end to end.

👥 Who this is for

A small-to-medium business that:

• Already runs on Microsoft 365 and doesn't want another expensive SaaS subscription.
• Wants to stay under the Microsoft umbrella — one vendor, one identity model, one security boundary.
• Has one person — comfortable directing an AI agent, not necessarily a developer — to stand it up and look after it. You don't need an IT team, a SharePoint specialist, or a ServiceNow consultant.

🤝 The idea: one person + an AI coworker

You don't build all of this by hand. The whole system is designed to be co-worked with an AI agent:

• Copilot Studio (CP) — you build the help-desk triage agent here. The AI does the topic and knowledge wiring; you review.
• FlowStudio MCP (mcp.flowstudio.app) — an MCP server that lets your AI agent build, read, and debug the Power Automate flows directly, reading action-level run outputs to find and fix problems instead of clicking through the portal.
• Coding agent — this can be Copilot Cowork, GitHub Copilot, Claude Code, or a Codex agent. In my build, I used both Copilot Cowork and the Claude Code agent.

The human's job is to shepherd the agent — describe the intent, review what it produces, approve the changes. One person, paired with an AI coworker, can stand up and maintain what would normally take a team. You don't even have to know how to do the work yourself: the person who ran this build had never deployed an SPFx package by hand and didn't need to learn — the agent did it. The point is that the labour shifts from "build and operate a ticketing platform" to "supervise an agent that does."

📋 What it does

A user submits a ticket — "I forgot my password," "Please add me to the Marketing group," "I need a Power BI license" — through the ITSM Service Portal, a custom SharePoint-hosted app (a full-screen single-page app, not a list form — more on it below).

The moment the ticket is saved, a Power Automate flow fires on that new item and hands the ticket to the Copilot Studio triage agent. The agent reads it, classifies it, checks the knowledge base, and decides what happens next: resolve it from the KB, ask the user for more detail, propose an action, or hand it to the IT Service Desk queue when it can't be automated. If it proposes a change, a manager approves in one tap, a scoped executor performs it in Microsoft 365, and the ticket is closed with an audit record. If the change fails, the ticket is closed honestly — not marked resolved — and the service desk is alerted.

There is no chatbot to converse with. The agent isn't a front door users talk to — it's a triage brain the flow calls in the background, working on the submitted ticket.

🎯 How it works — a walkthrough

The full pipeline at a glance: the Type-Validator gate, the parallel Incident and Request lanes, their convergence at the Dispatcher, and the six executors. Each stage calls the next directly over HTTP — passing the record id and reading it live — and the Dispatcher routes each job to the one matching executor. [Open the interactive version](docs/ITSMprocessdiagram.html).

…and the same pipeline as real flows: every stage from the diagram, numbered in order (1.1 → 6.1, then the X/S/T side flows) in Power Automate.

1. INTAKE      A user submits a ticket in the ITSM Service Portal (SPFx app) → a Ticket row is created
2. TYPE GATE   Is it an Incident or a Request? Route accordingly before any automation runs
3. AI TRIAGE   A flow fires on the new ticket and calls the Copilot Studio agent to classify it
               and try a knowledge-base answer (read-only — it can't make a change here)
4. APPROVAL    If it needs a change, a Teams Adaptive Card goes to the manager. One tap to approve
5. DISPATCH    An approved job is validated and the dispatcher routes it to the one matching executor
6. EXECUTION   That executor (of six) is called over HTTP and makes the actual change:
               · Microsoft Graph for identity, groups, licenses
               · an Azure Function for Exchange mailbox permissions
   AUDIT       The result is logged, the ticket is closed, and the requester is notified

Walk through it step by step:

1. A ticket is submitted. A user logs the request in the ITSM Service Portal — a full-screen SPFx app hosted on a SharePoint page (see below) — and it lands as a row in a SharePoint list. SharePoint is the system of record; there's no separate database to run.
2. A flow picks it up and calls the agent. The instant the ticket is saved, a Power Automate flow fires on the new item and passes it to the Copilot Studio triage agent. The agent classifies the ticket against your service catalog, tries to deflect it with a knowledge-base answer, and returns one of four outcomes — resolve from KB, ask for more detail, propose an action, or hand off to the IT Service Desk queue when it can't be automated. It has read-only access — it proposes, never changes. When it asks for more detail, the requester gets an approval card with the questions; answering re-runs validation automatically, and you can go back and forth until it has enough or cancel.
3. A human approves. Anything that changes the tenant pauses for a manager's approval in Teams. Nothing privileged happens without that tap.
4. A scoped robot does the work. Once approved, one narrowly-scoped service principal — and only that one — performs the change through Microsoft Graph (or Exchange, via an Azure Function). The agent itself holds no power to make changes.
5. Everything is recorded. The outcome is written to an audit log, the ticket is closed, and the requester is told what happened — in plain English, with the ticket and request numbers. A failed change closes the ticket honestly instead of marking it resolved, and a hand-off waits in the Service Desk queue until a fulfiller clears it.

The live pipeline in action — the manager's one-tap approval card in Teams, then the change landing in the tenant:

🖥️ The front end — a custom SharePoint-hosted portal

The portal isn't a SharePoint list form. It's the ITSM Service Portal, a full-screen SPFx (SharePoint Framework) web part — a React single-page app, built with SPFx 1.22 / Heft / TypeScript — hosted as a SharePoint page and backed by a dozen-plus SharePoint lists behind it. It follows the open-source vibe-sharepoint-template pattern, which treats SharePoint Online as a Vercel-like host for internal apps (CSS injection hides the SharePoint chrome for an app-like feel). The direction to the agent was essentially "point at this template and follow it" — it produced the ITSM-specific app from there. One web part hosts the whole experience:

…and the submit-a-ticket form a user fills in — on submit it becomes a SharePoint Tickets row that triggers the whole pipeline:

• Home dashboard, Service Catalog with item detail dialogs, Knowledge Base with inline articles, My Tickets + ticket detail, Approvals, a Service desk hand-off queue (lists requests the automation couldn't fulfil; a fulfiller marks each done or declines, which closes the request and resolves the ticket), and an Admin view.
• A license request uses a dropdown of the licenses you already own plus an Other (not listed) option, so it arrives as structured data the validation flow reads on a fast path instead of free text.
• A typed service layer (TicketService, CatalogService, KnowledgeService, ApprovalService, …) reads and writes those SharePoint lists directly — read-only except explicit user actions, and no privileged Graph calls ever run in the browser.
• It's packaged to an .sppkg and deployed to the site-collection app catalog on /sites/ITSM via a certificate-authenticated GitHub Actions CI/CD pipeline (--appCatalogScope sitecollection, --skipFeatureDeployment → available across that site collection). See [docs/SPFX-DEPLOYMENT.md](docs/SPFX-DEPLOYMENT.md).

The cool part: this SPFx portal was built and shipped by AI agents, not a front-end team. The IDE agent (Claude Code) wrote the React/TypeScript front end and first deployed it to SharePoint directly. Copilot Cowork later took over patching it — changing the portal's code and shipping each change to the app catalog through the certificate-authenticated CI/CD pipeline the IDE agent had already built. A real production SharePoint app — built and maintained by AI agents under one person's supervision.

🤖 How we built it — co-worked by two AI agents

This is how the repo was actually built: one person directing two AI coworkers, which created the whole stack — the SharePoint lists, all the Power Automate flows, and the SPFx portal — with almost nothing hand-built. Two kinds of agent split the work:

• Copilot Cowork — equipped with FlowStudio MCP, it authors the Power Automate flows and helper flows and reaches the GitHub repo and workflow to deploy the SPFx package to SharePoint. With the right helper flows it can also create SharePoint lists, pages, and list items. (The FlowStudio MCP plugin for Copilot Cowork is now in Microsoft's marketplace. The FlowStudio MCP server also works with Claude, GitHub Copilot, and any MCP-compatible agent.)
• An IDE agent in VS Code (in this build, Claude Code — the cloud agent) — does the one thing Cowork genuinely can't: author the Copilot Studio agent, via the Microsoft Copilot Studio extension. It also provisioned most of the SharePoint lists (PnP PowerShell, as a scoped service principal) and wrote a share of the Power Automate flows — but neither of those is exclusive to it: Cowork created some lists through helper flows, and both agents author flows through FlowStudio MCP.

The human directs and reviews; both agents were used together. Each step below notes which agent does it.

1. Provision the SharePoint lists. (IDE agent, or Cowork via helper flows.) Run the PnP PowerShell scripts in [infra/sharepoint/](infra/sharepoint/) to create the 19 solution lists (Tickets, Service Catalog, Approval Policies, Provisioning Jobs, License Costs, Catalog Demand, etc.) and seed the taxonomy. In this build the IDE agent ran them, authenticating as a scoped service principal (SP-IT-Provisioning, Sites.FullControl.All, certificate in Key Vault) — no standing admin account. Copilot Cowork can stand up the exact same lists a different way — a helper flow that creates each list and its columns through the SharePoint connector — so this step is not IDE-agent-only. Only the mechanism differs (a flow's connection vs. PnP PowerShell as a service principal); either agent produces the same schema.
2. Author the help-desk agent in Copilot Studio. (IDE agent — not Cowork.) This step needs an IDE agent with the Microsoft Copilot Studio extension; Copilot Cowork can't author Copilot Studio agents. Use the topic and knowledge definitions in [agents/triage/](agents/triage/) as the blueprint.
3. Build the flows with FlowStudio. (Copilot Cowork and Claude Code — both wrote flows.) Through the FlowStudio MCP server, the agents create the flows in [flows/](flows/) — orchestrator, approval, dispatcher, and the six executors — some authored by Copilot Cowork, others by the Claude Code agent; when a run fails, the agent reads the action outputs and fixes the definition. Every flow was agent-written; none of the flow JSON was hand-authored — and it's fast: ~20 production flows ship in this repo, and 40-plus counting helper flows and earlier iterations retired along the way.

That "when a run fails, read the action outputs and fix it" loop is exactly what FlowStudio MCP enables — the agent reads a live flow's run detail, confirms the bug, and patches the definition itself:

1. Set up the scoped service principals. One Entra app per executor (identity, groups, licensing, exchange, sharepoint, teams), each with a single Graph permission family. Secrets live in Azure Key Vault.
2. Build and deploy the ITSM Service Portal (SPFx). (IDE agent builds the app and sets up the pipeline; Cowork patches the code and ships through it.) The IDE agent scaffolds the SPFx React app in [src/](src/) and stands up the one-time deployment pipeline — a deployment Entra app registration, a certificate, the GitHub environment secrets, the site-collection app catalog on /sites/ITSM, and the spfx-build-deploy.yml GitHub Actions workflow. After that, Copilot Cowork patches the portal's own code — it changes a module or a line in the React/TypeScript source and pushes, and the existing pipeline builds it; the app-catalog deploy runs as a workflow_dispatch that Cowork or a person triggers. So Cowork makes real code changes and ships them through the pipeline the IDE agent built — it reuses that pipeline, it just didn't set it up. Full setup and required secrets are in [docs/SPFX-DEPLOYMENT.md](docs/SPFX-DEPLOYMENT.md).
3. Wire and test. (Cowork and human.) Connect the agent's action to the flow, then run one real request — "reset a password" — end to end. Cowork drives the test; the human approves the manager card in Teams (that approval is part of the loop), and both confirm the change actually landed in the

…

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ninihen1
• Source: ninihen1/copilot-studio-itsm-agent
• License: MIT
• Homepage: https://youtu.be/4oKlENZGW5M

Install and usage instructions live in the source repository linked above.