Intake Standards for Jira Service Management Documentation All pages

Templates

Intake Standards ships seven templates. A template is a starting point for the intake standard of one work type: a word minimum, the box wording and five or six checks. This page lists each one in full, so you can pick a template before you open the settings page.

Starting from a template

Open Project settings, then Intake standards, and pick the work type. When it has no standard yet, the Checks tab offers Start from template and Start empty. Start from template opens the Select a template pop-up, which shows the check count and word minimum of the template you select. Start empty gives you a blank draft with the neutral box wording, "Describe your request".

The pop-up opens on the template whose name fits the work type. It looks for each template's words in the work type's name, and the longest match wins. Incident opens on Incident report, Bug on Bug report, Request Access Prod on Access request and Emergency change on Production change. Change, New Feature and Epic open on Change request, the default, which also takes any name no other template fits. You can choose any other template from the list.

Before you save, you can edit the checks, the word minimum and the box wording. The box label takes 3 to 60 characters and the placeholder up to 140. Saving gives you an ordinary draft, which you enable when it is ready, and the version records the template it came from. A template is never a stored version: when a built-in template is revised, only drafts started from it afterwards carry the new wording, and the versions you have saved keep theirs. Templates carry no skip rule; you add one yourself if you want it.

The model, Atlassian-hosted AI (Forge LLMs), judges each check from the requester's text alone, so every check in a template says what counts and what does not, and accepts a short factual answer. Where a negative is information in itself, such as no workaround, no deadline, cause unknown or approval pending, saying so meets the check. Every check has to be met for a pass, so a template holds the checks a reviewer cannot do without, not everything they might like. Each hint is one sentence under 140 characters that tells the requester what to add.

Change request

The default template, for the requester's side of a change: what they need and why. The pop-up suggests it for work types whose name holds change, feature, new feature, story, improvement, enhancement, idea or suggestion. A name with a longer match, such as Emergency change or Data change, goes to Production change or Data correction instead.

Check What it asks for Hint shown when not met
Business need Why the request matters: the problem it solves or the opportunity it opens Say what problem this solves or what it enables, and why it matters.
Desired outcome What done looks like, shown with an example or an acceptance statement Describe what ‘done’ looks like, ideally with one example.
Affected area The application and the exact part that changes: workbench, screen, report, interface or data object Name the system and the exact workbench, screen or report.
Who and how often Who is affected and how often, or the volume; a short factual answer will do Say who uses this and how often the situation occurs.
Current workaround How the need is met today and at what cost; saying there is none counts Explain how you handle this today and what it costs you.
Timing driver A date it is needed by and the reason, or a plain statement that there is no deadline Give a needed-by date and why, or say there is no deadline.

Incident report

For something that is broken. Its checks ask up front the questions an agent would otherwise have to send back. The pop-up suggests it for work types whose name holds incident, outage, problem or disruption.

Check What it asks for Hint shown when not met
What is wrong What happens against what should, such as a quoted error or a wrong value; a bare plea for help is not enough Say exactly what you see and what you expected instead, quoting any error message.
Where it happens The application and the place the problem shows, such as a screen, report, job or file; the environment if known Name the application and the screen or job, and PROD or TEST if you know it.
Records affected A reference or user name the team can look up, or a statement that no record is involved Add a trade, order, invoice or job reference the problem shows on, or say none applies.
Business impact The user, team or process hit and what is held up; saying nothing is held up yet counts Say who is affected and what is blocked or delayed because of it.
Since when and how often The first sighting, and whether it recurs every time, now and then, or happened once Say when you first saw it and whether it happens every time or only sometimes.
What you have tried Steps already taken, such as a retry or a restart, and their result, or that none were taken List what you already tried and what happened, or say you have not tried anything yet.

Service request

For a routine request to have something done: a set-up, a reference-data entry, a routine action. The pop-up suggests it for work types whose name holds service request, service, task, support, help, question, how to, data request or extract.

Check What it asks for Hint shown when not met
What you need done The precise action to take, with the names and values it involves Say exactly what should be created, changed or run, with the names and values.
Where it applies Which application, and which part of it or which environment, the action is for Name the application and the screen or list, and PROD or TEST if you know it.
Why it is needed What the result makes possible, or the task or deadline that rests on it Say what this enables or which task depends on it.
Who it is for The person, desk or team that will use the result, or the requester themselves Say who will use the result, or that it is for you.
Needed by A date it is needed by and the reason, or a plain statement that there is no deadline Give a needed-by date and why, or say there is no deadline.

Access request

For granting, changing or removing access. Your workflow's approval step decides who approves, so the template does not ask. The pop-up suggests it for work types whose name holds access, access change, user access, permission, permissions, account, password, onboarding, offboarding, joiner, leaver or new starter.

Check What it asks for Hint shown when not met
Whose access Each person by full name or user id, with team or role, or that the access is the requester's own Give the full name and team of each person, or say the access is your own.
Application and environment The application, and PROD, TEST, UAT or all of them Name the application and say whether PROD, TEST or both.
Access wanted Grant, change or remove, and the role or level, or a colleague whose access to copy Say whether to grant, change or remove access, and which role or level, or whose access to copy.
Reason for access The job, task, project or team that calls for the access, or for its removal Say what the person will do with the access, or why it is no longer needed.
From and until when A start, and whether the access is permanent; an end date for temporary access or a removal Say when the access should start, and whether it is permanent or when it should end.

Data correction

For a controlled change to production data, with the records, both values and an authoriser on record from the start. The pop-up suggests it for work types whose name holds data fix, data correction, data change, amendment or correction. Data request and Data extract go to Service request.

Check What it asks for Hint shown when not met
Records to correct Unique references or a precise selection, plus the system that holds the records List each record by reference, or give the exact selection when many are affected, and name the system.
Current and correct values The wrong and the right value for each field to change For each field give the value it holds now and the value it should hold.
How the error arose What caused the wrong value, or that the cause is unknown Say how the wrong value got there, or that the cause is unknown.
Impact and deadline What the error touches, such as an invoice or a report, and a deadline with its reason, or none Say what the wrong value affects and by when it must be fixed, or that there is no deadline.
Authorised by The approver, such as a data owner, or that approval is under way Name the person who approved the correction, or say approval is still pending.

Bug report

For a software defect, as distinct from an operational incident: what a developer needs to reproduce it without going back to the reporter. The pop-up suggests it for work types whose name holds bug or defect.

Check What it asks for Hint shown when not met
Steps to reproduce An ordered path from a known screen or state that another person can follow List the steps in order, starting from a known screen or state, so someone else can repeat them.
Expected result The value, screen or behaviour the last step should have produced Say what should have happened at the last step.
Actual result The outcome seen, with the error text or wrong value quoted Say what happened instead, quoting the error message or wrong value.
Where and which version Application, environment and version or build, or that the version is unknown; the browser or device for a screen fault Name the application, environment and version or build if you know it, and the browser or device if relevant.
How often How reliably the steps reproduce it, and the first sighting Say whether it happens every time or only sometimes, and when you first saw it.
Impact and workaround The people held up, the work they cannot do, and any workaround Say who is affected, what they cannot do, and whether there is a workaround.

Production change

For the implementer's side of a change to a live system, as a change board reads it. The pop-up suggests it for work types whose name holds release, deployment, deploy, hotfix, maintenance or RFC, or a production, standard, normal or emergency change.

Check What it asks for Hint shown when not met
What changes The system, the component and the kind of change; a release name alone is not enough Name the system and component and say what kind of change it is.
Reason for the change The incident, defect, request or risk behind it, with its reference if there is one Say what the change fixes or delivers, with the ticket or requirement it comes from.
Impact and risk Users and interfaces hit during and after, expected downtime and the risks; a reasoned claim of no impact counts Say who is affected during and after the change, any downtime, and what could go wrong.
Testing done The test environment, scope and outcome, or the reason there was no testing Say where and how the change was tested and what the outcome was, or why it is untested.
Rollback plan How to reverse it and who would, or the fallback when it cannot be reversed Describe how to undo the change and who would do it, or say why it cannot be undone and what the fallback is.
Planned window When it will run and why then, or that it uses the regular release slot Give the planned date and time window and why that slot, or that it is the regular slot.