Ticket Types (AI Prompting)

Concise guide to instruct Leera AI to create or modify ticket type definitions safely.

Core Concepts

Ticket Type: Named schema describing a class of tickets.
Field: Data element (system or custom).
System Fields: id, status, createdAt, updatedAt (immutable).
Custom Fields: User-defined, versioned.
Lifecycle: Optional stage flow (e.g. Draft → Active → Deprecated).

Supported Field Kinds

text, textarea, enum, number (int|float), boolean, date, datetime, user, relation (one-to-many / many-to-one), tags.

Create Prompt: Required Parts

Intent: "Create ticket type"
Name (+ plural if needed)
Description (purpose + value)
Fields (name, type, required?, description, constraints, default)
Validation rules (patterns, min/max, maxLength)
Lifecycle (optional)
Visibility / permissions (optional)
Output format (JSON contract)

Update Prompt: Required Parts

Intent: "Update ticket type"
Target identifier (exact name or id)
Change set:
- ADD field
- MODIFY field (describe old vs new)
- DEPRECATE field (with migration)
Data migration / backfill rules
Version bump rationale
Explicit "No other changes"
Output format (JSON diff)

JSON Output Shape (Example)

{
  "action": "create",
  "ticketType": {
    "identifier": "incident",
    "name": "Incident",
    "version": 1,
    "description": "Operational disruption requiring investigation.",
    "lifecycle": ["Draft","Active","Resolved","Closed"],
    "fields": [
      {
        "name": "severity",
        "type": "enum",
        "required": true,
        "options": [
          {"label":"Critical","value":"critical"},
          {"label":"High","value":"high"},
          {"label":"Medium","value":"medium"},
          {"label":"Low","value":"low"}
        ],
        "default": "medium",
        "description": "Impact level."
      }
    ],
    "deprecations": []
  }
}

Good Create Prompt (Example)

Create ticket type:
Name: Incident
Plural: Incidents
Description: Tracks unplanned service disruptions requiring investigation & resolution.
Fields:
- severity (enum: critical, high, medium, low) required default=medium; impact level.
- service (text) required; affected subsystem name.
- detected_at (datetime) required; first detection timestamp.
- customer_impact (boolean) default=false; whether customers are affected.
- summary (text) required maxLength=120; short title.
- details (textarea) optional; longer description.
Lifecycle: Draft -> Active -> Resolved -> Closed
Return ONLY JSON per spec. If name exists, switch to update and bump version.

Poor Create Prompt (Anti-Pattern)

Make something for incidents with usual fields.

Issues: vague intent, no schema, no constraints, no output format.

Good Update Prompt (Example)

Update ticket type: Incident
Objective: Introduce root_cause; deprecate details.
Changes:
- ADD root_cause (textarea) optional; final cause summary.
- DEPRECATE details (migration: copy existing details into root_cause when status=Resolved)
No other changes.
Return ONLY JSON diff with version incremented.

Validation Prompt (Self-Check)

Validate ticket type Incident v3:
Rules:
- All required fields define type.
- No duplicate field names.
- Enums have >=2 options.
Return JSON: { "valid": true|false, "issues": [ ... ] }

Prompt Style Guidelines

Single clear intent (create or update).
Explicit field list; one line per field.
Use snake_case for field identifiers.
Mark required vs optional.
Provide numeric constraints (maxLength, min, max).
For enum: list options (label + value) and optional default.
For deprecation: give migration strategy (mapping, copy, derived default).
Demand structured JSON: "Return ONLY JSON".

Common Mistakes & Fixes

Missing action keyword -> Add "Create" or "Update".
Update without target -> Provide exact name/id.
Enum without options -> List options array.
Silent removal -> Use deprecations with reason + migration.
Ambiguous type (e.g. "long text") -> Specify textarea.

Reusable Snippets

Field template:

- {field_name} ({type}) {required|optional}{; constraints}; {short description}.

Deprecation template:

DEPRECATE {old_field} (reason: {reason}; migration: {strategy})

Migration mapping example:

priority -> severity: P1=critical, P2=high, P3=medium, P4=low

Safety Practices

Require confirmation step for destructive changes.
Reject prompt if change set omits migration for deprecation.
Auto-validate JSON against schema before applying.
Log version history.

Tip: Short, explicit, enumerated prompts reduce hallucination. Warning: Do not allow implicit field deletions; always deprecate with migration.

Checklist (Copy/Paste)

Intent:
Target (if update):
Name & plural:
Description:
Fields:
Lifecycle:
Deprecations (with migration):
Non-changes stated:
Output format specified:
Validation requested (optional):

Proceed to workflow automation prompting after stabilizing ticket type

Ticket Types