Creating and editing tickets
A ticket is one unit of work: a bug, a task, a story. This article covers creating one, the fields that matter, and what lives on the ticket page.
Creating a ticket
You can create a ticket from most places — My Work, the board, the List view's Create issue, or by opening a blank ticket page. At minimum, give it a project, a title and an issue type. The ticket gets a key from its project — KDV-123 — which never changes and is the way people will refer to it.
💡 If your company has Ticket Standards set up, write the title in that format — or write anything and press Fix title to standard afterwards. The standard exists so a board full of tickets reads as one system, not twelve personal styles.
The description — and its AI help
The description is where the actual brief lives. KAMI Tasks has AI actions built into the editor so a thin description doesn't stay thin:
- Generate from title — drafts a description from nothing but the title
- Improve existing description — tightens what is already written
- Rewrite from comments — folds a long comment thread back into the description, so the ticket's story lives in one place
- Add acceptance criteria — appends a concrete done-when list
- Fix description to standard / Fix title to standard — rewrites to your company's ticket standards with one click
The AI never invents facts that aren't in the ticket — it restructures what is there.
The fields, and what they are for
| Field | What it does |
|---|---|
| Assignee | Who is doing the work. One owner — accountability doesn't split well |
| Reporter | Who raised it |
| Issue type | Epic, Story, Task, Bug, Improvement or Subtask |
| Priority | Trivial → Minor → Major → Critical → Blocker |
| Status | Where it is in the workflow — see Statuses, priorities and ticket types |
| Sprint | Which sprint the work is planned into |
| Epic | The larger initiative it belongs to |
| Story points | Size estimate for velocity |
| Original estimate | Time estimate — with Calculate Start Date to work dates backwards |
| Start / due dates | When the work runs |
Also on the ticket page
- Comments — the discussion, with reactions. Mention someone with @ to pull them in
- Attachments — drop files onto the ticket
- Subtasks and linked tickets — see Epics, subtasks and linked tickets
- Work log — time logged against the ticket, see Estimates and logging time
- Watchers — get notified about a ticket without being its assignee, via Watch options / Add watchers
- History — every change, who and when
- Merge Requests — if GitLab is connected, the branches, MRs and pipeline status for this ticket appear here automatically
- Share and copy link — hand the ticket to someone in one click
Rules and things to watch
- The ticket key is permanent. Moving a ticket between sprints, epics or statuses never changes its key.
- "You don't have access to this issue" means the ticket sits in a project your groups can't see. Ask a project admin for access — see Projects and access.
- Keep the description current. When the plan changes in the comments, use Rewrite from comments — the next person reads the description, not forty comments.