saifbrand/zendesk-triage-escalate

Free workflow. Every new support ticket is auto-classified for urgency; urgent ones are escalated, tagged, and get an internal note explaining why — all in one governed run, with a signed receipt per node.

The story (real trigger → real business value)

A support team's first-touch problem: someone has to read every new ticket to decide if it's urgent before it sits in the queue. This workflow does that read for them. It runs on saifbrand/zendesk (also published for this contest) plus one pure transform node — no other paid module required.

1. create — zendesk.create_ticket (effect) — the inbound request becomes a ticket.

2. classify — pure transform, no external call — scans subject+body for urgency keywords (urgent, down, broken, outage, refund, angry, asap, cannot log in...), outputs {urgent, reason}.

3. escalate (cond: nodes.classify.urgent) — zendesk.update_ticket → priority=urgent.

4. tag (cond: nodes.classify.urgent) — zendesk.add_tags → adds auto_escalated.

5. note (cond: nodes.classify.urgent) — zendesk.add_comment (internal) → explains exactly which keyword triggered escalation, so an agent never wonders "why did this jump the queue."

Reliability

Non-urgent path verified separately: when no keyword matches, nodes 3–5 are cleanly skipped (not errored) — the receipt shows nodes_skipped explicitly, so a benign ticket costs zero extra writes.
Missing fields: create_ticket requires only subject+body; every other field (requester, tags, priority) is optional and defaults sanely inside the module.
Failure handling: any node raising an error rolls back the whole saga (RailCall's governed-effect guarantee) — a partial escalation is never left half-applied.
Dedup: the workflow acts on one ticket_id per run (no double-tagging), and Zendesk's own tag semantics mean re-running against the same ticket is idempotent for the tag node.

The receipts

Both branches were run against a live Zendesk trial account through RailCall's real workflow_engine (not a mock) before publishing:

Urgent path    → outcome: COMPLETED, nodes_taken: [create, classify, escalate, tag, note]
Non-urgent path → outcome: COMPLETED, nodes_taken: [create, classify], nodes_skipped: [escalate, tag, note]

Each node mints its own schema-tagged receipt (railcall_zendesk_apply_receipt.v1, railcall_transform_receipt.v1); the workflow receipt merkle-roots them into one step_receipt_root — a coherent, verifiable trail of exactly what ran and why.

Install

curl -fsSL https://railcall.ai/install.sh | bash
railcall market install saifbrand/zendesk              # the module this workflow drives
railcall market install saifbrand/zendesk-triage-escalate

Configure the same Zendesk OAuth credential described in the saifbrand/zendesk module README, then run the workflow from Studio with your own ticket context.

Known limitations

Urgency detection is keyword-based, not sentiment-model-based — tune the list in the classify node's transform code for your own vocabulary.
Escalates only on create — a ticket that turns urgent later (customer reply) isn't re-classified by this workflow; that would be a second, reply-triggered workflow.