Skip to main content

Autotask walkthrough

Use this walkthrough to check the everyday Autotask journey in Ops AI: choose a customer, find the right tickets, inspect the evidence and return to the saved conversation. An optional internal-note check needs separate permission. This does not certify every Autotask feature or automatic webhook/SOP workflow.

Before starting​

  • Sign in to the correct MSP workspace at Ops AI.
  • Have an authorised customer, an existing Autotask connection and a verified customer mapping. If any is missing or ambiguous, stop and ask the workspace administrator.
  • Agree what customer data the operator or external assistant may access. Keep credentials, session tokens, customer message bodies and attachments out of public reports or help-site search queries. Only give an external assistant data it is authorised to receive.
  • Use normal UI controls. A refusal is not permission to switch accounts, edit policies, use direct vendor APIs or retry a consequential action through another route.
  • Read-only ticket requests do not intentionally change vendor records, but still make vendor/model calls and save conversation/run records. Use a bounded number of prompts.

For an external assistant, the instructions below are a procedure, not permission to write. Let the account owner handle new sign-in, MFA and any approval the product requires from a human.

1. Select and confirm the customer​

Open Copilot (/app/copilot) and choose Customer focus. Select the agreed customer from the searchable list. Start a fresh conversation and verify the selected name before sending.

Use this prompt, replacing the bracketed text:

Read-only Autotask check for [customer]. List up to five open tickets for this customer only, with ticket number, numeric ticket ID, title, status and customer. State whether this is a complete list or a partial page. Do not create or change anything.

Check the tool evidence as well as the prose. Each ticket must belong to the selected customer. A mismatch is a failed check: stop before opening further customer details or making changes. The customer selector supplies context; verify the actual returned scope rather than treating it as proof on its own.

Open means statuses outside the Autotask account's configured terminal-status set. Status IDs and labels differ by account. A missing status-policy/configuration error is not an empty ticket list. Ask the administrator to resolve it; do not invent a numeric status.

Ask for a known ticket by its full ticket number (for example, TYYYYMMDD.NNNN) or use a number returned in step 1. Ask for its current status and a concise summary, without changing it. Compare the customer and ticket number with an authorised Autotask view or an operator's known reference. The numeric API ID and the displayed ticket number are different identifiers.

Then search a distinctive phrase from a known ticket title:

Search Autotask tickets for “[distinctive phrase]” within [customer] only. Return the matching ticket numbers and titles, and explain any limits on the search. Read-only.

Text search matches title or description; results are not necessarily newest first. A recent search window, a result limit or restricted API-user visibility can make results incomplete. An empty result alone does not establish that a ticket does not exist.

3. Continue and reload​

If more tickets are available, ask:

Show the next page for the same customer and filters. Do not repeat the previous tickets. Tell me if there is no continuation or if the result is incomplete.

Check for duplicate ticket IDs, changed customer/filter scope and unsupported claims of “all tickets”. retrieval.complete is the tool's completeness signal; total can mean only rows returned. If the first result is complete, record continuation as not applicable.

Refresh the browser and reopen the same conversation from the session list. Check that the messages and available tool/run evidence remain, then verify Customer focus again before any new prompt. Do not resend a write to test persistence.

Only test a second customer if access to that customer is also authorised. Change the focus, state the new name explicitly and confirm that old-customer tickets are not relabelled as new ones.

4. Optional: one approved internal note​

Skip this section unless the account owner has explicitly authorised the exact test ticket, note text, one write and verification. Prefer a dedicated synthetic ticket. Creating that ticket is a separate write; do not use a real customer incident merely to avoid requesting permission.

Before creating a test ticket or adding a note, the administrator must verify applicable Autotask workflow/email rules and notification settings. Internal controls portal visibility; it is not a guarantee that account-specific automation cannot send a notification.

  1. Read the chosen ticket and confirm its company, numeric ID and displayed number.
  2. Ask Copilot to prepare one internal note with the exact authorised text and target. Do not ask it to close the ticket, log time, notify anyone or perform a second action.
  3. Inspect the proposal: exact ticket, customer, note text and note_type=internal. A draft or pending approval is not a completed vendor write.
  4. The authorised human reviews the product's approval/apply control. Do not change autonomy settings or use a different route if the action is refused or requires another decision.
  5. After approval, inspect the recorded execution outcome and re-read the ticket notes through an authorised read surface. Confirm exactly one matching note, the right ticket/company and internal visibility. Record the returned note ID when available.
  6. Refresh the conversation and relevant run/approval view. Confirm the outcome is persisted. Approved, completed and verified in the vendor are separate facts.

If a request times out or its outcome is unclear, stop. Record outcome unknown and perform read-only reconciliation; do not resend, replay, approve twice or create a replacement ticket. If an optional test workflow was authorised and created, disable only that workflow afterwards; retain test records and audit evidence unless their deletion was separately authorised.

SOP rehearsal is a separate check​

Use SOPs → [SOP] → Dry Run only for an authorised procedure and customer context. The modal accepts Trigger context (optional JSON). Read tools can call live vendors; writes are simulated, approval gates do not pause, and simulation can still be refused by policy or fail. Check the run's simulation marker and individual results.

A dry run does not prove a live write, real approval resumption, webhook delivery or notification safety. Do not turn on automatic execution or replay production webhooks to complete this walkthrough. See SOPs for versioning and execution routes.

Record the result​

For each check record: pass / fail / blocked / not run / not applicable, time, customer scope, conversation/run ID, expected versus actual result and a minimal redacted evidence reference. Never turn “not run” into “pass”. Group repeated symptoms of one failure together.

Finish with what is usable, what remains blocked, any unknown write outcome and whether cleanup was verified. An assistant's successful checks support the account owner's acceptance; they do not replace it. Stop when this agreed journey is covered rather than expanding into other vendors.

Related: Copilot, Approvals, Autotask setup, Integration troubleshooting.