# Ticket statuses

> The ten ticket statuses, what each one means, and exactly what staff and customers can do in each of them.

Source: https://joely.io/documentation/tickets/statuses
Last updated: 2026-10-20

Every ticket has exactly one status. Statuses describe where the conversation stands and control what customers can do. Staff capabilities are governed by [permissions](https://joely.io/documentation/team/roles-permissions.md), not by status.

## The ten statuses

| Status | Meaning |
|--------|---------|
| **Open** | Newly created, awaiting staff attention |
| **In progress** | Staff is actively working on it |
| **Awaiting customer** | Staff replied and is waiting for the customer |
| **Required test** | A fix was deployed and needs customer testing |
| **Required action** | The customer needs to take a specific action |
| **Awaiting release** | A fix was merged and is waiting to ship in a release |
| **Resolved** | Marked resolved by staff |
| **Closed** | Definitively closed |
| **Pending closure** | The customer requested closure |
| **Closure scheduled** | Staff scheduled a future automatic closure |

## What staff can do, per status

Staff capabilities depend on permissions, not on the ticket status:

| Status | See | Message | Change status | Assign |
|--------|-----|---------|---------------|--------|
| Open | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| In progress | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Awaiting customer | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Required test | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Required action | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Awaiting release | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Resolved | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Pending closure | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Closure scheduled | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Closed | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |

A few important nuances:

- **Visibility is permission-based.** Staff members without the View all tickets permission only see tickets they are assigned to, regardless of status.
- **Staff can always message.** There is no status that blocks staff replies; staff can post on a closed ticket, which is useful for follow-ups and audit notes.
- **One closure schedule at a time.** Staff can move a closure-scheduled ticket to any status, but scheduling another closure on it is rejected.

## What customers can do, per status

| Status | See | Reply / edit own messages | Request closure | Invite links work |
|--------|-----|---------------------------|-----------------|-------------------|
| Open | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| In progress | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Awaiting customer | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Required test | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Required action | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Awaiting release | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} |
| Resolved | [✓]{.doc-yes} | [✓]{.doc-yes} | [✓]{.doc-yes} | [✗]{.doc-no} |
| Pending closure | [✓]{.doc-yes} | [✓]{.doc-yes} | [✗]{.doc-no} | [✓]{.doc-yes} |
| Closure scheduled | [✓]{.doc-yes} | [✓]{.doc-yes} | [✗]{.doc-no} | [✓]{.doc-yes} |
| Closed | [✓]{.doc-yes} | [✗]{.doc-no} | [✗]{.doc-no} | [✗]{.doc-no} |

The customer-side rules in one sentence each:

- **Seeing a ticket**: the ticket creator and active participants can see the ticket in any status, including closed.
- **Replying and editing**: blocked only on **Closed**. On every other status, including **Resolved**, customers can still reply and edit their own messages.
- **Requesting closure**: possible on any status except **Closed**, **Pending closure**, and **Closure scheduled**.
- **Invite links**: stop working as soon as the ticket is **Resolved** or **Closed**. On a closure-scheduled ticket they still work until the closure actually happens.

## Automatic transitions

Some status changes happen without anyone clicking a status selector:

- **Scheduled closure fires**: when a ticket is **Closure scheduled** and the scheduled time passes, it is automatically closed and a system message is added.
- **Scheduling a deletion closes the ticket**: when staff schedules a ticket for deletion, the ticket is closed immediately (if not already closed); the deletion itself happens later at the scheduled time.
- **Customer requests closure**: the ticket moves to **Pending closure** immediately, and a satisfaction survey is created right away.
- **Customer closes a scheduled ticket early**: when a ticket is **Closure scheduled**, the customer can close it immediately instead of waiting.
- **CSAT surveys follow the status**: entering **Resolved**, **Closed**, **Pending closure**, or **Closure scheduled** creates a satisfaction survey; moving back out of these statuses deletes the survey if it has not been submitted yet. See [CSAT surveys](https://joely.io/documentation/csat.md). Note that **Awaiting release** does **not** create a survey; the survey fires later, when the release moves the ticket to **Resolved**.
- **GitHub events can move tickets**: when GitHub auto-transition is enabled for the project, closing a linked issue as completed moves its tickets to **Awaiting release**, and publishing a release moves the repository's **Awaiting release** tickets to **Resolved**. Tickets already **Resolved** or **Closed** are never moved back. See [GitHub integration](https://joely.io/documentation/integrations/github.md).
- **Automation workflows can move tickets**: the [**Set status**](https://joely.io/documentation/automations/actions.md#set-status) and [**Schedule closure**](https://joely.io/documentation/automations/actions.md#schedule-closure) actions change the status like a staff member would, with the same system message and the same survey rules.
- **Favorites are cleared**: entering **Resolved** or **Closed** removes the ticket from all customers' favorites.

A customer reply does **not** change the status, with one exception: when an automation scheduled the closure with **Cancel if the customer replies** checked, a reply from the customer cancels that closure and moves the ticket back to **Open**, with the system message "Scheduled closure cancelled: the customer replied". A closure scheduled by a staff member, or by a workflow without that option, is never cancelled by a reply. Otherwise, moving a ticket out of **Awaiting customer** after the customer answers is a manual staff action (or a workflow's).