Intake Standards for Jira Service Management Documentation All pages

Getting started

A project admin sets up Intake Standards for each project and work type. Nothing is checked until you enable a standard, so you can install the app, set up one work type, try it on the Evaluate tab, and only then enable it for requesters.

Before you start

Set up one work type

  1. Add the field to the create screen. Project settings, Screens, the screen scheme the work type uses, Create screen: add Intake details.
  2. Write a draft and try it. Project settings, Intake standards, select the work type. Choose Start from template; the pop-up opens on the template that fits the work type's name, and you can take another. Review the checks, the word minimum and the label and placeholder of the requester's box, then Save draft. Try the draft on the Evaluate tab with requests you have seen before, until it judges the way your reviewers would.
  3. Put the field on the request form. Project settings, Request types, the request type, Request form: add Intake details and mark it Required. Keep the display name short and different from the box label. The shipped name, "Intake details", works. The label above the box and the placeholder inside it come from the standard, so a display name that repeats the label shows the same words twice. Add help text that names the checks and, where your policies call for it, says that the text is checked by AI and kept for 30 days. Change it whenever the enabled version changes. Until a version is enabled, the field is a plain required box.
  4. Hide Description on that request form. Description stays on the agent create screen and must remain optional in the field configuration, or the app cannot fill it on creation.
  5. Check the project's forms. No JSM Form attached to the request type may link the Description field.
  6. Prepare the review queue. Add a Labels column, or a filter on labels = intake-unverified, so requests that did not pass are easy to find.
  7. Enable v1. When the draft judges the way your reviewers would, choose Enable v1 from the footer or the Versions tab. From then on requesters on the portal meet the checks.

Keep a copy of your checks

Standards live only in the app's hosted storage. Atlassian keeps that storage 28 days after an uninstall and does not restore it automatically, so keep the enabled checks in your project's own documentation too.

What requesters see

On the portal the requester finds the box with your label and placeholder, and the checklist for the work type beside it, each row showing an empty circle (Not checked yet). Leaving the box or pressing Check or Send runs the check. If the text is under the word minimum, the requester is asked for more detail and nothing goes to the model. Otherwise the model, Atlassian-hosted AI (Forge LLMs), judges the text, and each row shows a tick (Met) with a short quote from the text or a cross (Not met) with your hint. While a check is not met the request cannot be sent, unless the standard lets requesters skip. When every check is met the field reads Ready to send.

What agents see, and how to filter for requests that did not pass, is on Reviewing requests.

Next