> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thena.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Status management

> Understanding and managing ticket statuses in the Thena platform

Ticket statuses in the Thena Platform provide a structured way to track the progress and state of work items. The platform offers a flexible status system with parent-child hierarchy and customization options while maintaining essential system requirements.

## System overview

<Note>
  When an organization signs up, four default parent statuses are automatically created: Open, In progress, On hold, and Closed. These serve as the foundation for your status workflow.
</Note>

### System requirements

<CardGroup cols={2}>
  <Card title="Default status" icon="flag">
    • Minimum 1 system default status required <br />
    • "Open" status created by default <br />
    • Used for new ticket creation <br />
    • Can be changed if needed
  </Card>

  <Card title="Closed status" icon="flag-checkered">
    • Minimum 1 closed status required <br />
    • "Closed" status created by default <br />
    • Represents final state <br />
    • Can be changed if needed
  </Card>
</CardGroup>

## Status hierarchy

### Parent statuses

<AccordionGroup>
  <Accordion title="Default parents" icon="layer-group">
    System creates four initial parent statuses:

    * Open (system default)
    * In progress
    * On hold
    * Closed (system closed)
  </Accordion>

  <Accordion title="Parent capabilities" icon="gear">
    Each parent status:

    * Can have multiple sub-statuses
    * Has one default sub-status
    * Supports custom configuration
    * Maintains system requirements
  </Accordion>
</AccordionGroup>

### Sub-statuses

<CardGroup cols={2}>
  <Card title="Configuration" icon="sliders">
    • Can be added to any parent <br />
    • Inherits parent properties <br />
    • Supports custom settings <br />
    • Maintains parent requirements
  </Card>

  <Card title="First sub-status" icon="flag">
    • Optional ticket migration <br />
    • Config flag available <br />
    • Moves parent tickets <br />
    • One-time operation
  </Card>
</CardGroup>

### Platform configuration

```mermaid theme={null}
flowchart TD
    %% Styling
    classDef default fill:#f9f9f9,stroke:#333,stroke-width:2px
    classDef status fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef substatus fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    classDef requirement fill:#fff3e0,stroke:#e65100,stroke-width:2px

    A[Organization Signup] --> B[Create 4 Default Parent Statuses]
    B --> C[Open]:::status
    B --> D[In Progress]:::status
    B --> E[On Hold]:::status
    B --> F[Closed]:::status
    
    B --> G[System Requirements]:::requirement
    G --> H[Min 1 Default Status]:::requirement
    G --> I[Min 1 Closed Status]:::requirement
```

## Deletion rules

### Parent status deletion

<AccordionGroup>
  <Accordion title="System status protection" icon="shield">
    Cannot delete:

    * System default status (Open)
    * System closed status
    * Status with active tickets
  </Accordion>

  <Accordion title="Requirements" icon="list-check">
    System maintains:

    * Minimum one default status
    * Minimum one closed status
  </Accordion>
</AccordionGroup>

### Sub-status deletion

<CardGroup cols={2}>
  <Card title="Non-last sub-status" icon="arrow-right">
    When deleting: <br />
    • Moves tickets to parent's default sub-status <br />
    • Validates ticket migration <br />
    • Allows deletion after migration <br />
    • Maintains data integrity
  </Card>

  <Card title="Last sub-status" icon="arrow-up">
    When deleting: <br />
    • Moves tickets back to parent status <br />
    • Ensures data preservation <br />
    • Allows deletion after migration <br />
    • Updates parent status
  </Card>
</CardGroup>

### Delete scenarios

```mermaid theme={null}
flowchart TD
    %% Styling
    classDef default fill:#f9f9f9,stroke:#333,stroke-width:2px
    classDef warning fill:#fff3e0,stroke:#e65100,stroke-width:2px
    classDef success fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    classDef info fill:#e3f2fd,stroke:#1976d2,stroke-width:2px

    A[Delete Parent Status] --> B{Check if System Default}
    B -->|Yes| C[ Deletion not allowed]:::warning
    B -->|No| D{Check Active Tickets}
    D -->|Has Tickets| E[Deletion not allowed]:::warning
    D -->|No Tickets| F[Allow Deletion]:::success

    G[Delete Sub-status] --> H{Last Sub-status?}
    H -->|Yes| I[Move Tickets to Parent Status]:::info
    H -->|No| J[Move to Default Sub-status]:::info
    I --> K[Allow Deletion]:::success
    J --> K
```

## Status configuration

### Core properties

<AccordionGroup>
  <Accordion title="Basic attributes" icon="circle-info">
    * Status name
    * Description
    * Color coding
    * Icon selection
  </Accordion>

  <Accordion title="Behavior settings" icon="gear">
    * Default assignment
    * Automation rules
    * Transition permissions (coming soon)
    * Notification triggers (coming soon)
  </Accordion>
</AccordionGroup>

## API endpoints

### Create status

```json theme={null}
{
  "displayName": "In Review",
  "description": "Ticket is being reviewed by the team",
  "isDefault": false,
  "name": "in_review",
  "teamId": "team_123",
  "parentStatusId": "status_456",
  "moveParentTickets": true
}
```

<Note>
  Creating a new status requires appropriate permissions. The status will be available for use immediately after creation.
</Note>

### Available operations

<Accordion title="Status management" icon="gear">
  ```bash theme={null}
  # Get all ticket statuses
  GET /v1/tickets/status

  # Create a new ticket status
  POST /v1/tickets/status
  Content-Type: application/json

  # Get a ticket status by its ID
  GET /v1/tickets/status/{id}

  # Update a ticket status
  PATCH /v1/tickets/status/{id}
  Content-Type: application/json

  # Delete a custom ticket status
  DELETE /v1/tickets/status/{id}
  ```

  <Note>
    All endpoints require authentication and appropriate permissions. System default statuses cannot be deleted.
  </Note>

  For detailed API specifications, see <a href="/api-reference/platform/tickets/status" target="_blank">Status Management</a>
</Accordion>

## Best practices

### Status management

1. **Plan your hierarchy**
   * Define clear parent categories
   * Plan sub-status needs
   * Consider workflow requirements
   * Document status purposes

2. **Configure thoughtfully**
   * Use clear naming conventions
   * Set appropriate defaults
   * Configure transitions
   * Test workflow paths

3. **Maintain efficiently**
   * Regular status review
   * Update as needed
   * Monitor usage patterns
   * Optimize workflow

## Related resources

<CardGroup cols={2}>
  <Card title="Lifecycle management" icon="circle-nodes" href="/platform/core-concepts/tickets/lifecycle">
    Understanding the ticket journey
  </Card>

  <Card title="Workflow automation" icon="robot" href="/platform/core-concepts/tickets/automation">
    Status-based automation
  </Card>

  <Card title="Team processes" icon="users-gear" href="/platform/core-concepts/teams/workflows">
    Team workflow configuration
  </Card>

  <Card title="Best practices" icon="book" href="/platform/core-concepts/tickets/best-practices">
    Status management guidelines
  </Card>
</CardGroup>