Autotask Ticket Triage Agent

A worked example of an advanced workflow: a Claude-managed scheduled agent that, every hour, finds new Autotask support tickets, classifies each by priority, writes the priority back, moves the ticket to In Progress, and posts a one-line summary to a Slack channel. There are no servers and no code to deploy: the agent is a saved prompt plus a schedule plus two MCP connectors, running in Claude's cloud.

What it builds

The finished workflow runs unattended on an hourly cron. Each run it pulls untriaged tickets, reasons about severity from the ticket content, updates the record in Autotask, and notifies your team, turning a queue of raw "New" tickets into a prioritised, in-progress queue with a Slack trail.

Prerequisites

Before building, your Claude account needs all of the following:

Known gotchas

These are the things that cost real time the first time through. Account for them up front and the build genuinely takes minutes.

• One-hour minimum cadence. Claude-managed routines reject any cron faster than hourly — */5 * * * * fails outright. Real-time triage needs a separate webhook-triggered service and is out of scope for a routine.
• permitted_tools must be populated per connector. A routine with a connector attached but an empty permitted_tools list runs with no tools and silently does nothing — no error, no output. List the exact tool names the routine needs.
• The Slack connector is attachable, but won't appear in the /schedule connector list. Don't conclude Slack is unsupported. Read its connector_uuid and url from an existing routine that already uses Slack (RemoteTrigger list → get → mcp_connections).
• Don't make the routine call list_* discovery tools every run. Enumerating queues or categories is slow enough to hit the 60-second tool timeout and stall the run. Discover the tenant's status and priority IDs once at build time and bake them into the routine prompt.
• Autotask IDs are tenant-specific. Status, priority, and queue IDs differ per Autotask instance — discover them, never assume. Priority IDs are typically not ordered by severity, so map by name.
• Routine tool calls prompt for permission. Each new tool a routine touches surfaces an approval. Pre-allow them in your client's permission settings (an mcp__<server> rule allows every tool on that server) or click "Always allow" as they appear.

The one-shot build prompt

With the connectors above in place, paste this to Claude. It discovers your tenant's IDs, creates the routine, and verifies it end to end.

Build me a scheduled Autotask ticket-triage agent. Do all of this end to end:

1. Confirm the WYRE MCP Gateway works: call autotask_test_connection.
2. Discover this Autotask tenant's IDs ONCE now (do not bake list_* calls into
   the routine): call autotask_list_ticket_statuses and
   autotask_list_ticket_priorities. Record the "New" and "In Progress" status
   IDs and the four priority IDs (Critical/High/Medium/Low).
3. Slack: confirm a Slack connector is connected. Get its connector_uuid and
   url - if it does not show in the /schedule connector list, read it from an
   existing routine that already uses Slack (RemoteTrigger list -> get ->
   mcp_connections). Note the destination channel name + ID.
4. Create a Claude-managed scheduled routine named "Autotask Ticket Triage":
   - Schedule: hourly (cron "0 * * * *"). Faster cadences are rejected.
   - Attach TWO connectors, each with permitted_tools populated:
       * WYRE MCP Gateway: autotask_search_tickets, autotask_get_ticket_details,
         autotask_update_ticket
       * Slack: slack_send_message
     An empty permitted_tools list = the routine runs with no tools.
   - Routine prompt: every run, find status-New tickets; for each, read details,
     classify PRIORITY by the rubric below, call autotask_update_ticket once to
     set priority AND move status to In Progress, then slack_send_message a
     one-line summary to the channel. Do NOT call any list_* tools - the IDs
     are baked in. On update failure, leave the ticket New and post a
     "needs a human" message instead. Never skip silently.
5. Create one test ticket at status New, trigger a manual run, and verify:
   ticket moved to In Progress + reprioritised, one Slack message posted, and a
   second run does not re-process it.

Priority rubric:
- Critical: server/site down, multiple users affected, or security incident.
- High: a single user fully blocked from working.
- Medium: service degraded but the user can still work.
- Low: requests, questions, cosmetic issues.
When torn between two priorities, pick the lower-severity one.

The resulting routine prompt

This is the lean prompt the build process installs into the scheduled routine itself. Substitute your tenant's discovered status and priority IDs.

You are the Autotask ticket triage agent. You run once per hour. Keep it lean.

Use ONLY: autotask_search_tickets, autotask_get_ticket_details,
autotask_update_ticket, slack_send_message. Do NOT call any autotask list_*
tools - all IDs are below.

1. autotask_search_tickets with status = <New status ID>. If none, stop, post nothing.
2. For EACH New ticket, one at a time:
   a. autotask_get_ticket_details - read title, description, companyID, ticketNumber.
   b. Classify PRIORITY: Critical (server/site down, multi-user, security);
      High (one user fully blocked); Medium (degraded, still working);
      Low (requests, questions, cosmetic). When torn, pick lower severity.
   c. autotask_update_ticket once: set priority AND set status to In Progress
      in the same call. The status change is the idempotency guard.
   d. slack_send_message to the channel: a one-line triage summary. No @-mentions.
3. If autotask_update_ticket fails, leave the ticket New and slack_send_message
   a "needs a human" message instead. Never skip silently.

How it works

Idempotency is structural

The agent only ever picks up tickets in the New status, and triaging a ticket moves it to In Progress. That single status transition is both the workflow signal and the "already handled" marker: the next run won't see the ticket again. No database, timestamp window, or dedupe logic is needed.

Failures escalate to a human

If the agent can't classify a ticket confidently, or an update call fails, it leaves the ticket in New and posts a "needs a human" message to Slack instead. A ticket is never silently skipped and never mis-prioritised without a person being told.

Everything goes through MCP

A routine reliably reaches only the MCP connectors attached to it. That includes notifications: use the Slack connector's slack_send_message tool, not an outbound webhook. The routine sandbox blocks arbitrary network egress, so a curl to a webhook URL will fail where a connector tool call will not.

Extending it

The example classifies priority and leaves queue and category untouched, deliberately: enumerating those per run is what triggers the slow list_* calls. To add queue or category routing, bake the queue and category lists into the routine prompt the same way the status and priority IDs are baked in. The same shape extends to other PSAs and to different queues. The gateway exposes the tools; the workflow is the prompt.

Questions or a workflow you'd like documented? Open an issue in the msp-claude-plugins repository.