A Zendesk ticket is the record Zendesk keeps for one customer request. For a migration, the fields that drive the mapping are status, priority, type, requester, organization, group, assignee, tags and the audit history.
Fields and what each value means
Status. The lifecycle article lists New, Open, Pending, On-hold, Solved and Closed; the API calls them new, open, pending, hold, solved and closed. Agents set Pending, On-hold and Solved. Closed comes from automation, because “Tickets can’t manually be closed.” Priority is urgent, high, normal or low, and type is problem, incident, question or task.
Ownership. requester_id is “the user who requested this ticket”. submitter_id becomes the author of the first comment, so it differs from the requester when an agent opens a ticket for a customer. assignee_id is the agent, group_id is the team, and organization_id is the requester’s organization.
Text and time. description is the first comment, so it opens the thread. subject can be empty. Keep created_at and updated_at from the export, or every imported thread looks new.
Channel and tags. via types include mail, web_form, web_widget, web_service, mobile and rule, so there is no email value to map. The default set-tag behavior “overwrites and replaces existing tags”, so never write tags back blindly.
Events and archiving
Creating or updating a ticket generates an audit object whose events array lists the updates. A Change event carries field_name, previous_value and value. A Comment event has a public flag: true is a public comment, false is an internal note. Filter on it before anything reaches a shared channel.
GET /api/v2/tickets/{ticket_id}/audits returns audits per ticket. The list endpoints leave archived tickets out, while the per-ticket endpoint returns them without pagination. Zendesk usually archives a ticket 120 days after it moves to Closed, unless it has more than 10,000 events. An archived ticket shows the banner “This is an archived ticket.”
The ticket.status_changed webhook lists nine values: NEW, OPEN, PENDING, HOLD, SOLVED, CLOSED, DELETED, ARCHIVED and SCRUBBED. The reference describes none of the last three, so decide how you will import them.
Mapping to Slack threads
Weft turns each customer message in a shared Slack Connect channel into a thread, grouped under accounts. A Zendesk ticket can hold several customer messages, so decide the unit before you import.
| Zendesk | Target in Slack inbox | Rule |
|---|---|---|
| ticket | thread | one thread per customer message |
| organization_id | account | one account per Zendesk organization |
| requester_id | customer | match on Slack user or email |
| assignee_id | assignment | map agents first |
| group_id | label | a team is a label, not an assignee |
| new, open | open | direct |
| pending, hold | waiting status you define | a status, not a pause |
| solved | resolved | not done; see below |
| closed, archived | done | archiving follows Closed |
| comment with public false | internal note | never post in the shared channel |
Worked example: the default automation closes a Solved ticket 4 days after it is solved. A ticket solved on day 0 closes on day 4, so a customer reply on day 6 creates a follow-up request. With the closing automations off, Solved tickets close 28 days after they are solved, and the same reply reopens the ticket for the agent who solved it.
SLA policies need Professional or Enterprise on Support, or Growth, Professional, Enterprise or Enterprise Plus on Suite. Agent work time pauses on On-hold or Pending, requester wait time and pausable update pause on Pending, and total resolution time pauses only when the ticket changes to Solved. Map each pause before you copy a target, because a waiting status in Slack stops a clock only if someone stops it.
The common mistake
Teams copy statuses one to one and treat Solved as done. Solved is still reopenable within the 4 day window, so keep that window in your import rules and test it: reply in an old Solved thread and confirm it returns to the queue.
Then compare counts for one pair, such as solved and high. Count the Zendesk tickets with that pair, then count the threads with the same status and label in your inbox. Count closed tickets separately, because Zendesk’s count endpoint leaves out archived tickets. Any gap is a set of dropped tickets, so list those IDs before you go on.