Skip to main content
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

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.

System requirements

Default status

• Minimum 1 system default status required
• “Open” status created by default
• Used for new ticket creation
• Can be changed if needed

Closed status

• Minimum 1 closed status required
• “Closed” status created by default
• Represents final state
• Can be changed if needed

Status hierarchy

Parent statuses

System creates four initial parent statuses:
  • Open (system default)
  • In progress
  • On hold
  • Closed (system closed)
Each parent status:
  • Can have multiple sub-statuses
  • Has one default sub-status
  • Supports custom configuration
  • Maintains system requirements

Sub-statuses

Configuration

• Can be added to any parent
• Inherits parent properties
• Supports custom settings
• Maintains parent requirements

First sub-status

• Optional ticket migration
• Config flag available
• Moves parent tickets
• One-time operation

Platform configuration

Deletion rules

Parent status deletion

Cannot delete:
  • System default status (Open)
  • System closed status
  • Status with active tickets
System maintains:
  • Minimum one default status
  • Minimum one closed status

Sub-status deletion

Non-last sub-status

When deleting:
• Moves tickets to parent’s default sub-status
• Validates ticket migration
• Allows deletion after migration
• Maintains data integrity

Last sub-status

When deleting:
• Moves tickets back to parent status
• Ensures data preservation
• Allows deletion after migration
• Updates parent status

Delete scenarios

Status configuration

Core properties

  • Status name
  • Description
  • Color coding
  • Icon selection
  • Default assignment
  • Automation rules
  • Transition permissions (coming soon)
  • Notification triggers (coming soon)

API endpoints

Create status

{
  "displayName": "In Review",
  "description": "Ticket is being reviewed by the team",
  "isDefault": false,
  "name": "in_review",
  "teamId": "team_123",
  "parentStatusId": "status_456",
  "moveParentTickets": true
}
Creating a new status requires appropriate permissions. The status will be available for use immediately after creation.

Available operations

# 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}
All endpoints require authentication and appropriate permissions. System default statuses cannot be deleted.
For detailed API specifications, see Status Management

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