Workflow Blueprints BLUEPRINT · CM-WF

Ticket Triage with Judgment

A new Dataverse ticket fires a workflow that pulls customer history, has an agent node classify the ticket against your product KB, and routes it — P1s page on-call in Teams, everything else lands assigned with a draft reply waiting for human review.

advanced updated June 2026
⚡ Event — new row in Dataverse tickets table → Dataverse trigger (new ticket) → Get customer history → Agent node (structured output) → Branch on priority + confidence → Teams page (P1) → Assign + queue draft for review
Outcome

Every ticket arrives pre-classified, pre-prioritized, and pre-drafted — with a human still holding the send button.

What this automates

Triage is the most expensive boring job in support: a senior person reads each new ticket, decides what it is, how urgent it is, who should own it, and types the first reply — and 80% of those decisions are pattern-matching they’ve done a thousand times. This blueprint moves the pattern-matching to an agent node and keeps the judgment calls where they belong.

It’s the advanced blueprint on this site because it touches a shared system, makes decisions that affect customers, and forces you to think about confidence, branching, and the line between drafting and sending. Get this one right and you understand workflow design.

The design

StepNodeWhat it does
1Dataverse triggerFires when a row is added to the tickets table
2Dataverse — get customer rowsPulls the customer’s recent tickets and account tier; this context is what separates judgment from keyword matching
3Agent node (the brain)Classifies against the product KB; returns custom structured output — see below
4Condition — priority = P1?Branches on the agent’s structured priority token
5aTeams — post to on-call channelP1 path: adaptive card with category, customer history summary, and the agent’s reasoning; tags the on-call rotation
5bCondition — confidence ≥ 0.7?Non-P1 path: high confidence assigns to suggested_owner and queues the draft reply for review; low confidence routes the whole ticket to a human triager untouched

The agent node, configured

Inline agent, Add panel → Agent. Pick a stronger model — this is multi-signal classification with a drafting task attached, not a one-liner. Knowledge: your product KB SharePoint site — without it the agent classifies from vibes. Work IQ stays off; this agent should reason from the ticket and the KB, not from whoever-triggered-it’s inbox. Output: custom JSON schema with five fields — category (string), priority (string: P1–P4), suggested_owner (string), draft_reply (string), confidence (number 0–1). Each field becomes a dynamic token for the branches downstream — that’s the whole point of structured output.

Instructions for the node:

You triage support tickets. The new ticket and the customer's recent
history are below as dynamic content.

Decide, using the product knowledge base:
- category: one of [Billing, Bug, How-to, Outage, Account, Other]
- priority: P1 only if production is down or data is at risk for this
  customer; P2 for blocked work; P3 default; P4 cosmetic
- suggested_owner: the queue from the routing table in the KB page
  "Support routing". If no rule matches, return "triage".
- draft_reply: a reply a support engineer could send after editing —
  acknowledge the specific problem, cite the relevant KB article if one
  exists, never promise timelines or refunds
- confidence: 0-1, your honest certainty in category AND priority
  together. Repeated issue from history with a clear KB match: high.
  Vague ticket, new customer, or no KB coverage: low. Never inflate.

Ticket subject: [Subject token]
Ticket body: [Description token]
Customer tier: [Tier token]
Recent tickets: [History token]

The confidence rule is the load-bearing wall. Below 0.7, the workflow doesn’t act on the classification at all — the ticket goes to a human triager exactly as it arrived. This is what keeps the automation honest: the agent handles the thousand tickets it has seen before and hands over the ones it hasn’t, instead of confidently mis-routing them. Tune the threshold with real data after a couple of weeks — start strict.

And the line you do not cross on day one: the draft reply is never auto-sent. It’s queued for a human to read, edit, and send. The temptation is obvious — the drafts will look good, and someone will ask why a person is still in the loop. The answer: the first auto-sent reply that promises the wrong thing to an angry P1 customer costs more trust than six months of triage automation earned. Earn the right to auto-send with months of edit-rate data, not on launch day.

Build it (half a day, mostly testing)

  1. Flows → New workflow in Copilot Studio. Trigger: Dataverse, when a row is added, your tickets table.
  2. Add a Dataverse list-rows action for the customer’s last N tickets plus their account row.
  3. Add the Agent node. Attach the KB SharePoint site as knowledge, set the custom JSON schema, paste the instructions, wire the dynamic tokens.
  4. Use node-level testing on the agent node with five real historical tickets — including one ambiguous one — before building any branches. If confidence doesn’t drop on the ambiguous ticket, rewrite the confidence rule until it does.
  5. Build the P1 branch: Teams adaptive card to the on-call channel. Then the confidence branch: high → update the ticket row with category/priority/owner and store draft_reply in a review field; low → assign to the triage queue with a “low confidence” note.
  6. Run shadowed for a week — workflow classifies, humans still triage everything — and compare. Publish for real only when agreement is boringly high.

Cost and governance notes

  • Credits: this fires per ticket, all day, every day — run the agent usage estimator against your real ticket volume before launch. The agent node is the expensive step; the Dataverse actions are noise by comparison.
  • Permissions: the agent node runs as the triggering user. For an event-triggered shared workflow that’s effectively a designated account — make sure it can read the KB site and the Dataverse tables, and confirm your DLP policies allow the agent node in this environment before you build, not after.
  • Async: history lookup plus a reasoning model can brush the two-minute limit on busy days; enable asynchronous responses so spikes don’t kill runs mid-triage.

Variants worth building once this works

  • Severity sampler: weekly scheduled workflow pulls 20 random high-confidence tickets and posts them to a QA channel — your ongoing answer to “is it still accurate?”
  • Deflection edition: for How-to tickets with confidence ≥ 0.9, send the customer the KB link as a suggestion while the human reviews the draft — assist, not auto-resolve.
  • Multi-product routing: one workflow per product line with its own KB knowledge source beats one mega-agent juggling three routing tables.
← All workflow blueprints Agent blueprints →