Intake Standards for Jira Service Management
Intake Standards for Jira Service Management stops thin requests before they reach your desk. A project admin writes an intake standard for each work type: the checks a request has to meet and a word minimum. On the customer portal, Atlassian-hosted AI (Forge LLMs) reads what the requester wrote against that standard, the requester sees which checks are met and which are not, and the portal holds the request until every check is met, unless the standard lets requesters skip. The app runs on Forge and requester text never leaves Atlassian.
How it works
The field. Intake Standards adds a field named Intake details to your request forms. It replaces Description on the portal: a text box with the checklist for that work type beside it. The rows stay unchecked until the model has judged the text. When the requester leaves the box or presses Check, text under the word minimum fails on the count alone; longer text is judged and each check reads Met, with a short quote from the text, or Not met, with the hint you wrote. When every check is met the field reads Ready to send.
The block. On the portal the field withholds its required value while a check is not met, so the portal's own required-field rule stops the request from being sent. Nothing blocks on agent screens: on the agent create dialog, the work item and transition screens the checklist is guidance only. A standard can carry a skip rule that lets requesters send anyway, at once or after a number of failed checks.
The settings page. Project settings, Intake standards: one page per project, open to anyone with Administer Projects there. A sidebar lists the work types and the state of each. Four tabs act on the selected work type: Checks (the enabled version and the editable draft), Versions (history, Enable, Disable, Compare, Copy to draft), Evaluate (try any version on pasted text) and Run log (every check against an enabled version, kept 30 days).
Seven templates. A new standard starts from a template that fits the work type: change request, incident report, service request, access request, data correction, bug report or production change. Each is a starting point; edit any check, the word minimum or the box wording before saving.
When the check cannot run. A model error never blocks a requester. The request goes through
flagged: the work item reads Unverified, carries the label intake-unverified and an internal note
for reviewers. A work type with no enabled standard gets a plain required box and reads Not
checked.
On creation. The app copies the text into Description when Description is empty, verifies the
stored result against its own run log, labels and notes requests that did not pass, and exposes
the status to JQL as "Intake details".Status and to the issue property intake-gate.
Where to go next
- Getting started: set up a project in seven steps.
- The seven templates: what each template asks requesters for.
- How the check judges: what the model sees and how a pass is decided.
- Letting requesters skip: the skip rule and what it does to a request.
- When the check cannot run: unverified results, limits and advisory mode.
- Your data and Security: what is stored, where, for how long, and who sees it.
- Known issues, Release notes and Support.