Client Work · Microsoft Power Platform

IT Service Desk: from Teams chat to a tracked workflow

A construction-services firm ran IT support out of a Microsoft Teams chat thread — colleagues answered each other's questions when they happened to know the answer. I replaced it with a Power Apps service desk backed by a SharePoint list and three Power Automate flows, introducing ownership, routing, status notifications, and a management view.

Anonymized. The client's logo and all third-party employee names are permanently redacted. These captures come from the build and acceptance-testing environment, so ticket titles and descriptions are test data entered during development — not real support requests.

At a glance

App screens

Automated flows

Routing categories

Lifecycle states

System of record

Power AppsPower Automate SharePoint OnlineOutlook / Exchange Kanban board viewProcess redesign

What was broken

Before — Teams chat

Goodwill, not a process

No assignment. A request belonged to everyone and therefore to no one. If nobody recognized the problem, the message simply scrolled away.
No accountability. Nothing recorded who picked an issue up, or whether anyone did.
No traceability. Solved problems vanished into chat history, so the same issue got re-diagnosed from scratch the next time it appeared.
No timing data. Time-to-resolution could not be measured, so management had no way to see load, backlog, or recurring failures.
No status. The requester's only recourse was to ask "any update on this?"

After — Power Platform

A workflow with an owner

Structured intake. Category, impact, and affected system are captured up front instead of buried in prose.
Automatic routing. Category determines the assigned owner the moment a ticket lands.
Status notifications. Requester, assignee, and management are emailed automatically as a ticket moves toward resolution.
Durable record. Every ticket is a timestamped SharePoint item — resolution notes included — so history is searchable and time-to-solution is measurable.
Management visibility. A Kanban view shows the whole queue by state at a glance.

How it fits together

Intake

Power Apps

Three screens: submit a request, review your own history, and triage the queue.

→

System of record

SharePoint list

One item per ticket, holding status, priority, owner, category, and timestamps.

→

Automation

Power Automate

Three flows fire on create, on reassignment, and on any status change.

→

Output

Email + Kanban

Notifications to the people involved; a board view for management review.

The SharePoint list is deliberately the single source of truth — the app and the flows are both just clients of it, so the data survives independently of either.

Intake that forces the right questions

The old chat thread produced requests like "printer's acting up again." The form makes the fields that drive routing and prioritization mandatory, so a ticket arrives triageable.

Service Request Form with title, category, affected system, impact, description and collaboration fields — **Service Request Form.** Category and impact are required; the collaboration field keeps the back-and-forth attached to the ticket rather than scattered across chat.

Category dropdown showing six routing categories — **Six categories drive assignment.** Microsoft Application, Non-Microsoft Application, Hardware, Network, Access / Permissions, Other — the selection determines who the ticket is routed to.

Impact dropdown showing Low, Medium and High — **Impact is captured at source.** Low / Medium / High comes from the person experiencing the problem, giving the desk a starting point for priority.

Requestor picker with employee names redacted — **Requestor lookup against the staff directory.** Tickets can be raised on behalf of another employee — useful when someone can't get to a machine at all. Employee names are redacted here.

The requester can answer their own question

"Any update?" was the most common message in the old thread. Giving requesters a read-only view of their own history removes the need to ask.

My Requests screen listing the user's submitted issues with status and created date — **My Requests.** Each person sees their own submissions with current status and created date, and can raise a new one from the same screen.

A queue the service desk actually works from

This is where an unowned message becomes an owned ticket: the desk sets status, assignee, and priority in one place, and every change downstream is automated.

Service Queue screen with status, assigned user and priority controls — **Service Queue.** Triage controls for status, assigned user, and priority. Saving here is what triggers the notification flows.

Three flows carry the communication

Every status change that a human would previously have had to remember to communicate is now sent automatically, to the people who need it.

Power Automate flow sending an email when a SharePoint list item is created — **Flow 1 — new ticket.** On item creation, emails the requester a confirmation containing title, category, impact, affected system, and a deep link to the item.

Power Automate flow with a condition that emails the newly assigned user — **Flow 2 — reassignment.** Watches for changes to *Assigned To* and, gated behind a condition so it only fires on a real change, notifies the new owner.

Power Automate flow emailing the requester when their service item is updated — **Flow 3 — status update.** Emails the original requester whenever their ticket is modified, closing the feedback loop that the chat thread never had.

One record, two ways to read it

Because everything lands in a single SharePoint list, the same data serves the desk's detailed working view and management's status overview without a second system.

SharePoint list of service desk requests with status, priority, assignment, category and impact columns — **System of record.** Status, priority, assignment, created date, category, affected system, impact, requester, resolution notes, and threaded collaboration — the columns that make time-to-resolution reportable. Filtered views (Assigned to Me, High Priority, New Requests) sit across the top.

Kanban board view grouping tickets by status across Unassigned, New, In progress, Completed, Blocked, Duplicate and By design — **Management Kanban.** The same list grouped by state — Unassigned, New, In progress, Completed, Blocked, Duplicate, By design — so backlog and stalls are visible without running a report. Cards drag between columns to update the underlying record.

Design decisions worth calling out

The list is the product, not the app. Making SharePoint the system of record — rather than holding state inside Power Apps — means reporting, permissions, and retention are handled by the platform, and the app stays replaceable.
Routing is data, not code. Assignment is driven by the category value, so changing who owns "Network" is a configuration change rather than an app edit.
The reassignment flow is condition-gated. It fires on a genuine change to Assigned To instead of on every item modification, which is what keeps automated mail from becoming noise people filter away.
Adoption was the real risk. A chat thread is frictionless; a form is not. Keeping intake to a handful of fields and giving requesters their own status view were both deliberate concessions to that.

What I'd build next

Time-to-resolution reporting on top of the existing timestamps (the data is already being captured, it just isn't surfaced); SLA timers with escalation on breach; a knowledge-base article generated from resolution notes so recurring issues stop being re-solved; and Teams notifications alongside email, meeting people where the old process already lived.