Jira Issue Classification with AI: Auto-Label Work Items Using Jira Automation and Jev

Jira Cloud now calls issues work items and projects spaces; the automation documentation uses the new names, while smart values still start with issue. Teams that take requests from many people, through a service desk, an intake form, or colleagues filing tickets directly, spend time on the same first step: reading each new work item and deciding what kind of work it is. Classification automates that step with one label from a short, fixed list, for example bug, feature_request, question, or other, so a board filter, a queue, or the next rule can pick it up. Keep that category separate from a second question that often matters as much: does the text say that someone is blocked right now? Ask it as an independent yes/no question rather than as a label, and use it to add a comment or notify someone, not to change Priority until you have measured how often it is right. Start with labels because they are cheap to add and easy to remove; changing the work type, the assignee, or the status affects workflows and reports, and a wrong automatic change there is costly. If your issues live in GitHub rather than Jira, the GitHub issue labeling guide covers the same idea with GitHub Actions.

Six components. 1) Trigger: Work item created, optionally limited with JQL to the work types you want classified. 2) Action: Re-fetch work item data, so fields filled in during creation are loaded before the request is built; Jira does not refresh the {{issue}} data during a run on its own. 3) Action: Send web request to https://jevmodel.app/api/v1/systemone with method POST, a Content-Type: application/json header, an Authorization header with Bearer and a key created in JevModel Console → API keys from a verified account (tick Hidden so the value is masked after saving), and Custom data as the web request body. Tick “Delay execution of subsequent rule actions until we’ve received a response for this web request”, and also “Continue running the rule even if the request response is not successful” if you want the fallback branch to run when the API returns an error status. 4) If/else block with an advanced compare condition: {{webResponse.body.code}} equals 0. 5) In the if branch, Edit work item with the Labels field in the additional fields JSON, adding ai- plus the chosen label; a second condition on the yes/no answer can add a comment. 6) In the else branch, add the label needs-triage. Jira labels cannot contain spaces, which is one reason to keep label IDs like feature_request.

Four problems cover most failed rules. Empty response values: Atlassian’s knowledge base lists the usual causes as the wait-for-response option not being ticked, reading the response outside the if block in which the request was sent, and a response whose Content-Type is not application/json; JevModel returns JSON, so the first two are the ones to check. Broken JSON: a summary with a quote or a description with line breaks produces invalid JSON if pasted in raw, so wrap each value in asJsonString, which escapes special characters and adds the quotes. If the description can be empty, add a condition that it is not empty or send the summary alone. Request size: the whole JevModel request, state plus questions, must stay within 8,000 characters, so use abbreviate on the description (the example keeps 5,000 characters). Repeat runs: JevModel has no idempotency key, so a rule on Work item updated would send a new, billed request on every edit and could stack labels after a person has corrected one; trigger on creation only. Two governance points matter as much. Atlassian warns that anyone who can edit a rule can reconfigure a Send web request action to send data elsewhere, so limit rule editors. Hidden header values are lost when a rule or the action is duplicated, exported, or imported, so re-enter the key afterwards. Send only the summary and description, not reporter names or emails.

Jira automation also offers a Use Rovo agent action, which prompts an agent to generate a response that you then pass to an action with text output, such as a comment. The table compares the shape of each path as documented, not accuracy, and no row is a benchmark.

Rules are built in the rule builder, so the example shows each component as text with the values to paste. The request follows the documented JevModel contract: POST /api/v1/systemone with a Bearer key from a verified account, a state, and named questions, here a Choice called kind and a Noul called blocking; a successful response has code 0 and data.answers. There is no model field because the site always calls typesafe/jev-1.13 through OpenRouter; JevModel is independent of TypeSafe AI, which develops Jev. The ai- prefix makes automatic labels easy to find and remove. Jira smart values cannot easily look up a probability by a dynamic key, so this rule applies the label and leaves probability checks to your test sample; if you need a per-label cut-off, add one condition per label on {{webResponse.body.data.answers.kind.probabilities.bug}} and its siblings. 0.8 for blocking is a placeholder, not a recommendation. Use a Log action with {{webResponse.body}} while testing, and read the rule’s audit log.

# Illustrative only. Jira Cloud automation rule, written out component by component.
# Trigger:  Work item created            (optional JQL: type in (Bug, Task, Story))
# Action:   Re-fetch work item data
# Action:   Send web request
#   Web request URL:  https://jevmodel.app/api/v1/systemone
#   HTTP method:      POST
#   Headers:          Content-Type = application/json
#                     Authorization = Bearer <your JevModel key>   [x] Hidden
#   Web request body: Custom data
#   [x] Delay execution of subsequent rule actions until we've received a response
#   [x] Continue running the rule even if the request response is not successful
{
  "state": {
    "summary": {{issue.summary.asJsonString}},
    "description": {{issue.description.abbreviate(5000).asJsonString}}
  },
  "questions": {
    "kind": {
      "type": "choice",
      "instructions": "Which kind of work item is this, based on its summary and description?",
      "criteria": {
        "bug": "Something that used to work is broken, slow, or shows an error.",
        "feature_request": "Asks for new behavior the product does not have yet.",
        "question": "Asks how to do something; nothing is broken.",
        "other": "Anything that fits none of the labels above."
      }
    },
    "blocking": {
      "type": "noul",
      "instructions": "Does the text say that users, customers, or a release are blocked right now?",
      "criteria": {
        "true": "Someone cannot continue their work until this is resolved.",
        "false": "Work can continue while this waits in the backlog."
      }
    }
  }
}
# If:  Advanced compare  {{webResponse.body.code}}  equals  0
#   Action: Edit work item → More options → Additional fields:
{ "update": { "labels": [ { "add": "ai-{{webResponse.body.data.answers.kind.choice}}" } ] } }
#   If:  Advanced compare  {{webResponse.body.data.answers.blocking.noul}}  greater than  0.8   (placeholder)
#     Action: Comment on work item: "Automatic check: this may be blocking someone. Please confirm."
# Else:
#   Action: Edit work item → Additional fields:
{ "update": { "labels": [ { "add": "needs-triage" } ] } }

Your resolved work items are a ready-made labeled set: their work type, components, or existing labels were set by people. Export a few hundred with a JQL filter such as resolved work items of the last quarter, keep the summary, description, and the human category, and run the text through JevModel Console → Batch with the same Choice question. Batch returns row-level answers; it does not compute accuracy, so join them with the human column in a spreadsheet. Check agreement per label, which pairs get confused (bug and question are often mixed when reporters describe a usage mistake as a bug), and how often blocking is true on work items that were not urgent. Rewrite vague definitions and rerun the same sample. Then turn the rule on for one space, read the audit log for a week, and count how often people remove an ai- label. Remember that old categories were set under time pressure; read some disagreements before blaming the model. Add assignee or priority changes only after this, and keep them reversible.

Pick Send web request plus Jev when you want labels from a list you control that filters, boards, and later rules can rely on, and you can maintain one rule with a JSON body. Pick a Rovo agent action when the goal is a generated summary or suggestion that a person reads in a comment. Pick a CSV export and Console → Batch to test definitions or to label a one-off backlog without changing Jira at all. If requests reach you as support tickets in Zendesk, as Slack messages, or as GitHub issues, the dedicated guides cover those sources. Checklist for any of them: 1) write label definitions with an explicit other; 2) ask urgency as a separate yes/no question; 3) trigger on creation only, because JevModel has no idempotency key; 4) send summary and description only, abbreviated below the 8,000-character limit; 5) restrict who can edit the rule and keep the key in a Hidden header; 6) start with ai- labels and a needs-triage fallback, and widen the rule only after measuring agreement on resolved work items. JevModel is text-only and is not open source; screenshots, attachments, and logs attached to a work item are not classified by this rule.