Classy documentation

1. Set up and try a classifier

1. Once Classy is installed on your Jira site, open Apps → Classy. A Jira administrator manages the installation and its license. No public purchase link is available on this site yet.
2. Create a classifier or choose a recipe. Set its name, question/instructions, category labels and matching criteria, and confidence threshold. Category order does not establish precedence.
3. Save the classifier. Drafts and manual history are private to your Atlassian account in this installation.
4. Select Jira issues or use Test samples for supplied text. Run the batch and inspect the category, confidence, probability distribution and saved revision. Use a review workflow rather than treating confidence as proof.

Jira selection rows are previews. Classy reads each issue's current summary and description when classification begins, using your Jira permissions. Comments and attachments are not read by the issue classifier. Supplied text is your input, even if it contains an issue key.

Save conflicts preserve the other tab's saved definition and your local edits. Use Review current definition, then deliberately choose Use saved definition or Reapply my draft. Reapplying keeps your draft for review; click Save changes to save it.

2. Publish an immutable revision

1. Save or discard local edits, then choose Publish revision in Published revisions.
2. Select that published revision in a Jira Automation action. Published snapshots are available across the Jira site; the private draft remains owner-managed.
3. To change a running rule, save your changes, publish another revision and explicitly select it in the rule. Editing the draft does not update existing bindings.

Every action pins a specific published version. Unpublishing a revision, deleting its classifier or erasing its owner makes bound actions fail; Classy never silently selects a replacement. Update or disable affected rules first.

Use Previous published revisions and Next published revisions to browse further pages. Search in native configuration filters the current page only. A saved off-page binding remains selected when you reload the rule.

3. Configure either native action

In Jira Automation, choose a trigger, add a Classy action, connect your Atlassian account and select a published classifier. The connection authorizes Jira access, not an OpenRouter account. You can instead choose Create classifier, complete its definition and use Save and use to save a private draft and select a newly published snapshot.

Classy: Classify issue

This action reads the current issue's summary and description as the connected user. Keep Issue key as {{issue.key}} in an issue-context rule, or provide another issue key that user can read.

Before returning successful outputs, Classy reads the issue again and checks current access, project and classified summary/description. A change or revoked access fails the action, even if the provider already processed it. This check does not lock Jira against later edits.

Classy: Classify text

This action classifies the text you supply, including resolved smart values. It needs no issue or project context itself. Use {{issue.description}} in an issue-context rule, or {{comment.body}} with the Work item commented trigger. A description or comment may resolve to empty text; empty input is rejected.

Use Jira's native Smart Values helper ({}) to find values available to the trigger or branch. Smart values belong in Issue key or Text to classify, not saved classifier definitions. Expand the text input for multiline content.

Both actions recheck that the selected revision is still published after inference. They return metadata, not the source text or full probability distribution, and do not add personal workbench history. Jira owns scheduling, rule audit logs and downstream writes; the Classy workbench need not remain open.

4. Understand the decision outputs

Find the Classy action under Components in Jira's native helper. Both actions expose their latest decision through createdClassyDecision:

{{createdClassyDecision.status}}

classified or review. Below-threshold results and the system Unclear category are always review.

{{createdClassyDecision.categoryId}}

The stable identifier of the saved category, or unclear. It is not the category label or a status. Replacing a category creates a different identity.

{{createdClassyDecision.category}}

The human-readable label from the selected published revision. Compare its exact, case-sensitive spelling if routing by label.

{{createdClassyDecision.confidence}}

A model estimate from 0 to 1, not a correctness guarantee.

{{createdClassyDecision.resultId}}

A unique decision reference.

{{createdClassyDecision.classifierRevision}}

The saved classifier revision timestamp.

{{createdClassyDecision.sourceHash}}

A SHA-256 fingerprint of the classified text. Hashes can be linkable; this is not anonymous source data.

5. Branch on status before category

A category match alone does not enforce the confidence threshold: a decision may have category Bug and status review. Use this pattern immediately after either Classy action:

1. Add a native If/else block (Jira calls it IF or ELSE: Add condition options).
2. For the accepted IF branch, add a {{smart values}} condition: {{createdClassyDecision.status}} equals classified.
3. Inside that accepted branch, compare {{createdClassyDecision.categoryId}} with the intended saved category ID when you have that ID from the selected classifier's outputs. Alternatively, compare {{createdClassyDecision.category}} with its exact label, such as Bug. Do not substitute a category label for an ID.
4. Place category-specific edits, labels or assignments only after those accepted-status and category conditions.
5. On the same outer If/else block, choose Add else and add a condition where {{createdClassyDecision.status}} equals review. Use that Else-if branch for human triage, not the protected category-specific write.

Do not put an ordinary status = classified condition before the If/else block: a false ordinary condition stops following actions and prevents Review from reaching its branch. Do not compare status to Bug or another category name.

Both actions share the latest createdClassyDecision context. Route immediately after the intended action, or copy status and category/categoryId together into native Automation variables before another Classy action replaces them.

An action error is not a Review decision. Inspect Jira's audit log; do not fabricate a category or reuse an earlier decision as an error fallback. Classy does not insert these guards into customer-authored rules. For update triggers, watch input fields rather than fields your rule writes, to avoid loops.

See Atlassian's Jira Automation condition documentation.

6. Runs, stopping and uncertain completion

A manual batch uses the saved definition revision it started with. If that revision changes, remaining items stop rather than silently switching classifiers. Reload to review the saved definition before a new run. An already-running item may finish with its starting snapshot, subject to source and history checks.

Stop run prevents the next item from starting. It does not cancel an in-flight provider request, undo processing or remove a completed result. Manual batches belong to the open workspace, not a background queue. Leaving may stop unstarted items; reopening History does not resume the old batch.

Unknown means completion is uncertain, not a confirmed failed decision. Check for result reads only that execution's retained outcome and never starts provider work. A missing result remains Unknown and does not prove no processing occurred. Starting a new intentional run may cause another provider request.

Classy does not automatically retry provider work. Native actions have no private retained outcome to recover. Jira may retry transiently failed flows independently, so native delivery is not guaranteed exactly once. Check rule audits and actual Jira effects before deliberately repeating an action. See Atlassian's retry documentation.

7. Private manual history

History returns up to 50 recent manual results younger than seven rolling 24-hour UTC periods. It stores titles, a source preview of up to 240 characters, relevant issue metadata, category/probability snapshots, model, usage and timestamps, not a separate complete source-text field. Jira-backed history is filtered by your current issue access.

Expired results disappear from History immediately; storage cleanup runs daily and can lag by roughly one day or longer after a failure. An empty History view is not proof of erasure.

Use Clear history for the saved classifier, even when no rows are visible. It also removes retained results hidden by current Jira permissions, while keeping the definition and published revisions. If cleanup is interrupted, use Resume cleanup. See the deletion procedures and their limits.

8. License denial and reduced access

An active Classy license or trial is required for manual classification and both native actions. If license context is missing or inactive, the request is refused before being sent to OpenRouter. Ask your Jira administrator to activate or renew Classy.

Configuration, publication management, existing authorized history and erasure remain available without inference access. Read-only Check for result does not initiate inference. Losing a license does not itself erase stored data.

A Jira administrator can also disable new inference in Jira settings → Apps → Classy administration. Already admitted work may still finish; disabling does not cancel processing or erase results. Re-enabling does not resume stopped runs.

9. Product and traffic limits

• Up to 20 saved classifiers per account and 12 custom categories per classifier, plus system Unclear.
• Sources longer than 12,000 characters are rejected rather than silently truncated.
• A manual batch contains up to 20 sources, processed sequentially; each native action classifies one source.
• Manual and native inference share two concurrent reservations and at most 30 new starts per rolling 60 seconds per Forge installation. Another account, tab or rule does not add capacity.
• Capacity/rate refusals occur before provider work and supply retry guidance. Classy does not queue or automatically retry them. Provider and Jira Automation limits also apply.

There is no customer API-key setup or separate monthly Classy inference allowance. The credentials indicator reports configuration presence only, not provider availability or credits. For access, credit-limit or persistent provider failures, contact Classy support.