# ConnectWise Manage Tickets

> ConnectWise PSA ticket management: ticket fields, service boards, statuses, priorities, SLAs, ticket notes, and workflow automation. Essential for MSP technicians handling service delivery through ConnectWise PSA.

- Skill: `wyre-ai/connectwise-manage-tickets` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add wyre-ai/connectwise-manage-tickets`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wyre-ai/connectwise-manage-tickets/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: WYRE-AI (https://skillmd.com/u/wyre-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wyre-ai/connectwise-manage-tickets

---


# ConnectWise PSA Ticket Management

Tickets are the core unit of service delivery in ConnectWise PSA. Every client request, incident, and change flows through `POST /service/tickets`. This skill covers creating, searching, updating, and closing tickets with proper SLA handling.

> For complete field definitions see [FIELDS.md](./FIELDS.md). For status values, priorities, SLA tables, and note types see [REFERENCE.md](./REFERENCE.md).

## Anti-triggers

- **RMM-generated alerts** — "connectwise alert" commonly means an
  Automate monitor alert, which lives in the RMM and only becomes a PSA
  ticket once escalated; use `connectwise-automate-alerts`.
- **Project tickets** — tickets on a project board are `/project/tickets`,
  a separate entity with its own tools (`cw_search_project_tickets`); use
  `connectwise-psa-projects`.
- **Hours worked on a ticket** — the ticket is the charge target, not the
  record that holds the time; use `connectwise-psa-time-entries`.
- **Another PSA's tickets** — Autotask, HaloPSA, Atera, Syncro and
  SuperOps all call them tickets; this skill speaks only the ConnectWise
  PSA `/service/tickets` API. Use `autotask-tickets`, `halopsa-tickets`,
  `atera-tickets`, `syncro-tickets` or `superops-tickets`.

## Core API Operations

### Create a Ticket

```http
POST /service/tickets
Content-Type: application/json

{
  "summary": "Unable to access email - multiple users affected",
  "board": {"id": 1},
  "company": {"id": 12345},
  "contact": {"id": 67890},
  "priority": {"id": 2},
  "status": {"name": "New"},
  "initialDescription": "Sales team (5 users) reporting Outlook disconnected since 9am. Webmail working."
}
```

Required fields: `summary`, `board`, `company`. Use `initialDescription` for the first note with full details.

### Get / Update a Ticket

```http
GET /service/tickets/{id}
```

```http
PATCH /service/tickets/{id}
Content-Type: application/json

{"status": {"name": "In Progress"}, "owner": {"id": 123}}
```

### Add a Note

```http
POST /service/tickets/{ticketId}/notes
Content-Type: application/json

{
  "text": "Identified the issue as a DNS configuration problem.",
  "internalAnalysisFlag": true,
  "resolutionFlag": false
}
```

Set `resolutionFlag: true` for resolution notes visible to the customer on close.

### Search Tickets

```http
GET /service/tickets?conditions=company/id=12345 and status/name!="Closed"&orderBy=priority/id asc
```

## Common Query Patterns

```
# Open tickets for a company
conditions=company/id=12345 and closedFlag=false

# High priority open tickets
conditions=priority/id<=2 and closedFlag=false

# Tickets by date range
conditions=dateEntered>=[2024-01-01] and dateEntered<[2024-02-01]

# SLA-breached tickets
conditions=_info/sla_resolve_by<[2024-02-15T12:00:00Z] and closedFlag=false

# My assigned tickets
conditions=resources contains "jsmith" and closedFlag=false
```

## Workflow: Ticket Closure with Validation

Follow these checkpoints before closing any ticket:

1. **Verify resolution exists** — `GET /service/tickets/{id}` and confirm `resolution` field is populated. If empty, add a resolution note first (`resolutionFlag: true`).
2. **Check time entries** — `GET /time/entries?conditions=chargeToId={id} and chargeToType="ServiceTicket"`. Ensure all work is logged.
3. **Confirm status is Completed** — Tickets must pass through `Completed` before `Closed`. Set status to `Completed` first if still `In Progress` or waiting.
4. **Close the ticket:**
   ```http
   PATCH /service/tickets/{id}
   Content-Type: application/json

   {
     "status": {"name": "Closed"},
     "closedFlag": true,
     "resolution": "DNS records corrected; email service restored for all affected users."
   }
   ```
5. **Validate closure** — `GET /service/tickets/{id}` and confirm `closedFlag: true` and `closedDate` is populated.

> If any checkpoint fails, stop and resolve the issue before proceeding. Closing without a resolution note will leave the ticket incomplete in reports.

## Best Practices

1. **Always specify board** — determines available statuses, workflows, and SLA rules.
2. **Set accurate priority** — use impact/urgency; Priority 1 = highest (business down). See [REFERENCE.md](./REFERENCE.md) for the matrix.
3. **Search before creating** — check for duplicates with `conditions=company/id={id} and summary contains "keyword"`.
4. **Update status promptly** — keeps SLA clocks accurate and queues reliable.

## Related Skills

- [ConnectWise Companies](../companies/SKILL.md) — Company management
- [ConnectWise Contacts](../contacts/SKILL.md) — Contact management
- [ConnectWise Time Entries](../time-entries/SKILL.md) — Time tracking
- [ConnectWise API Patterns](../api-patterns/SKILL.md) — Query syntax and auth