Request templates in Jira Service Management: the same good start for every request

A request that arrives with the right details can be worked on straight away. Here is how to give customers and agents in Jira Service Management Cloud the same starting point every time, with what Atlassian provides, four request types to copy, and where an app fits.

By Rolf Eriksen Published 22 October 2026 15 min read

Checked against Atlassian’s pages on 21 October 2026 · We make an app for this (disclosure)

In Jira Service Management the request type is the template. What it asks, and how, is set up in a few places:

• A request type template gives an admin a ready-made request type to start from, with its fields already on the form.
• The request form sets each field’s name, help text and whether it is required. A field can also be filled in and hidden from the customer.
• A form attached to the request type adds sections that appear only when they apply, headings, tables and layout.
• Portal groups and article suggestions help customers pick the right request type, or find the answer before they raise one.
• Automation gives agents the same internal sub-tasks on every new request of a type, after it is created.

All of this is built in, and for most service desks it is enough. What the Atlassian pages we read do not describe is a way for a customer to reuse a request they have already filled in. That is where our app comes in, and the section on it says where it stops. This page is part of our guide to Jira issue templates in Jira Cloud, which covers the Jira side.

A note on words: Atlassian’s newer pages say spaces and work items for projects and issues, and some menus have moved with the new navigation. The paths below are the ones on Atlassian’s pages on 21 October 2026.

Customers pick a request type on the portal, or through email or chat, and fill in its request form (What are request types?). A service space made from a template comes with some request types already. You can add more in three ways: a blank request type, a request type template, or, for Jira admins on Premium or Enterprise using AI, a suggestion from AI.

Request type templates

Atlassian keeps a library of request type templates (request type templates):

1. Go to Space settings → Request management → Request types.
2. In a company-managed space, select Create request type, then Create from template. In a team-managed space, select + Add request type at the bottom of the list, then Create from template.
3. Search the library or browse its categories: analytics, business, customer service, design, facilities, finance, HR, IT, legal, marketing and sales. Each preview shows the fields customers will fill in on the portal.
4. Review the name, description, icon, portal group and work type, then save (Create request types).

In company-managed spaces, Atlassian’s page on creating request types marks Create from template as for Jira admins only. A space admin can still create a blank request type. Whichever way it starts, you edit it afterwards like any other.

Name it the way customers ask

Atlassian’s own advice is to use plain language and skip specialist terms (its example is Get access rather than Deploy SSH key), and to keep request types specific without making so many that people cannot find theirs. In a team-managed space each request type also has a portal description, shown under its name in the list, and portal instructions, shown above the form fields (Manage request types in team-managed projects). Use the instructions to say when to use this request type and when to use another.

Copying a request type you already have

A space admin can duplicate a request type within the space: from the list, ••• → Duplicate, then a new name, description, icon and portal group (Duplicate a request type). The copy has the same configuration, with two exceptions on Atlassian’s page: it does not copy any forms attached to the original, and JQL that names the request type needs updating.

Each request type has two layouts: the request form customers fill in, and the work item view agents work from. A service space admin sets both under Space settings → Request management → Request types, by choosing the request type and then Request form or Work item view (Set up request forms and work item views). Drag fields in from the panel on the right, drag them out to remove them, and drag to reorder. On the request form, each field also has:

• Display name. What the customer sees as the label, so Summary can read What do you need?.
• Display description. The help text under the field. This is where a good request type earns its keep: say what a good answer looks like, with an example.
• Required. The customer cannot send the request without it. Some fields are required already.
• Use preset value and hide from portal. The field is filled in for every request of this type and the customer does not see it. Use it for things the request type already tells you, such as a category or a label.

What Atlassian says to keep in mind

• Adding a field to a screen puts it in the work item view of every request type that shares the work type. Remove it by hand where it is not needed.
• A change to a screen affects every work type that uses that screen.
• Mandatory system fields such as Summary cannot be removed or hidden, but you can change their display name.
• A custom field on the request form needs a value before customers can see it on their requests in the portal.

Default values that customers see

A preset value is hidden. For a value the customer sees on the form, a custom field can have a default value in its context, under ••• → Contexts and default value in the custom fields list. Atlassian’s knowledge base article uses exactly that for request forms.

The exception is the system Description field. Its default cannot be changed: the request for that, JRACLOUD-4812, is unresolved. The same article’s workaround is a Paragraph custom field, for example Issue Description, with a default value, added to the request form in place of Description. It comes with two warnings worth reading before you start:

• Automation rules, SLA conditions, filters and integrations that use Description then need to use the new field.
• Do not remove Description from request types used for email requests. The mail handler needs it.

Our default description guide covers the same problem on the Jira side.

Request type fields are a flat list. A form adds structure: sections, headings, tables, columns, field validation, and sections that appear only when they apply (What are forms?). Form fields can exist on the form alone, without a Jira admin making new custom fields, and can be linked to Jira fields when rules or reports need the value. Atlassian’s page says there are over 200 form templates to start from.

Build one

1. Go to Space settings → Request management → Forms. You need admin or space admin permissions (Create or edit a form).
2. Pick a template, or Blank form.
3. Edit labels, descriptions and options, drag in extra fields, and group fields with Section.
4. To make a section conditional, select it and choose Create logic. Under Visibility, choose Show or Hide, then a field, an operator such as is equal to, and a value. + AND and + OR add more conditions.
5. Use Preview to test the logic, then Save changes.

Attach it to a request type

On the request type’s request form, select Attach form, then Create from template or Select existing. Or, in the form’s Settings, turn on Attach to request types and choose them (Add a form to a request type). Customers see one form: the request type’s Jira fields and the attached form together. Form fields that are not linked to Jira fields appear underneath the Jira fields.

Limits

• Which fields can drive a condition. Radio buttons, checkboxes and dropdowns. Atlassian’s knowledge base says multi-select dropdowns cannot, and points to JSDCLOUD-10780 for more kinds of condition.
• Required Jira fields in a conditional section. The same article advises against linking a form field to a required Jira field: the customer is not told, and if the field sits in a conditional section the request cannot be created without it (JSDCLOUD-11995).
• Edits are not retroactive. Changing a form does not change it where it is already in use, or in spaces it was copied to.
• Layout. Atlassian warns that sections added to a table or layout may break the form’s structure.

Forms also work after the request exists. Agents can add a form to a work item, internal or for the customer, and a submitted form can be reopened for edits by people with permission.

A good request type does not help if customers pick the wrong one. Two built-in features help them choose.

Portal groups

Portal groups sort request types on the portal. In a company-managed space a project administrator sets them under Space settings → Channels & self service → Portal → Portal Groups (Organize request types into portal groups). A request type can be in more than one group. Groups show on the portal only when there are at least two. A request type in no group is hidden from the portal’s list, but Atlassian notes it still shows up in search. Team-managed spaces set portal groups from the portal itself: Raise a request, then your avatar, then Portal groups.

Article suggestions

If the space has a knowledge base, the request form can suggest articles while the customer types the Summary (Set up article suggestions). Turn it on per request form under Space settings → Knowledge base → Control article suggestions, and optionally limit it to articles with a label. Atlassian notes that suggestions do not show on the portal if the knowledge base is linked to spaces on a different Confluence site.

The request form shapes what customers send. Agents often need the same internal steps on every request of a type: create the account, order the laptop, book the induction. Jira Service Management does that with Automation, after the request is created.

A rule that adds sub-tasks to new requests

1. Trigger: Work item created. Atlassian’s triggers page names adding sub-tasks as one of its uses.
2. Condition: a JQL condition that picks out the request type, for example "Request Type" = "Set up a new starter". The JQL fields page documents the "Request Type" field for service spaces.
3. Action: Create sub-tasks, one summary per task. That action sets only the summary. Add fields turns it into Create work item with the sub-task type, where you can set more (actions page).

Space admins can build rules for their own space, and people with the Administer Jira permission can build rules across Jira (permissions). We have not run this exact rule on our development site, so test it on a few requests first.

What to know about it

• Sub-tasks are internal. Atlassian’s knowledge base says sub-tasks are not visible on the portal, cannot have a request type, and customers get no notifications about them. That is usually what you want for agent checklists. If the customer needs to follow a piece of the work, use a standard work type instead.
• Every run counts. Each trigger, condition and action that runs is an Automation step, and a trigger counts even when the rest of the rule does not go on (usage). A rule on Work item created runs for every new request in its scope. Our step billing guide has the arithmetic.
• Other actions for service spaces. Create work item with a request type creates a request with the request type set, and Attach forms adds forms to a work item. Edit request type changes it, as long as the request type belongs to the work item’s work type.

Cloning a request

Cloning copies a work item within the space: summary, description and more, with sub-tasks, links, attachments and comments as options. It needs the Create work items permission, and the copy’s summary starts with Clone (Clone a work item). A clone made by Automation does not get the same or a default request type (JSDCLOUD-14350, Gathering Interest). Its workaround is an Edit request type action on the new work item. For a request that agents raise often, a request type or a form is a better starting point than a request kept for cloning.

Starting points, not rules. Each has a name in the customer’s words, a portal description, the fields with their help text, and the sections a form could show only when they apply. Fields marked (form) work best as form fields; the rest can be Jira fields on the request form. Change the options to match your organisation, and leave out what your team never uses.

Access request

Request type:  Get access to a system
Portal group:  Accounts and access
Description:   A new login, more rights, or a shared folder or mailbox.

Summary        Display name: What do you need access to?
               Help: One line, for example "Finance shared drive, read only".
System         Dropdown, required.
               Help: Not listed? Choose Other and name it below.
Access level   Radio (form): Read / Edit / Admin, required.
               Help: Choose the lowest level that lets you do the job.
For whom       Person.
               Help: Leave blank if it is for you.
Why            Paragraph, required.
               Help: What will you use it for? Your manager may be asked.
Needed by      Date.

Section shown when Access level = Admin:
  How long      Dropdown: One day / One week / Until removed.
  Line manager  Person, required.

Preset and hidden: Label = access

Laptop or equipment request

Request type:  Ask for a laptop or other equipment
Portal group:  Equipment
Description:   New, replacement or extra equipment for work.

Summary        Display name: What do you need?
               Help: For example "Replacement laptop" or "Second monitor".
Item           Dropdown (form): Laptop / Monitor / Keyboard and mouse /
               Headset / Phone / Other, required.
Reason         Radio (form): New starter / Broken / Old or slow / Extra,
               required.
Deliver to     Short text, required.
               Help: Office and floor, or a home address for remote staff.
Needed by      Date.
               Help: Ordered items can take time to arrive.

Section shown when Reason = Broken or Old or slow:
  Asset tag     Short text.
                Help: The sticker on the old item, if it has one.
  Fault         Paragraph.

Preset and hidden: Label = hardware

Something is broken

Request type:  Report something that is not working
Portal group:  Get help
Description:   An error, an outage, or something that worked before and
               does not now.

Summary        Display name: What is not working?
               Help: One line, for example "Cannot log in to payroll".
What happened  Paragraph, required.
               Help: What were you doing, and what happened instead?
               Copy any error message exactly.
Since when     Date and time.
               Help: Roughly is fine.
Affected       Radio (form): Just me / My team / Everyone I know of,
               required.
               Display name: Who is affected?
Workaround     Radio (form): Yes / No.
               Help: Can you carry on another way for now?
Attachment     Help: A screenshot of the error helps most.

Section shown when Affected = Everyone I know of:
  Note          Text only: "If this is urgent, also call the service
                desk on [number]."

New starter

Request type:  Set up a new starter
Portal group:  People and onboarding
Description:   Accounts, equipment and access for someone joining.
               Please send it at least [ten working days] ahead.

Summary        Display name: Name of the new starter, required.
Start date     Date, required.
Job title      Short text, required.
Team           Dropdown, required.
Line manager   Person, required.
               Help: Who should the starter go to on day one?
Works from     Radio (form): Office / Remote / Both, required.
Equipment      Checkboxes (form): Laptop / Monitor / Phone / Headset.
Systems        Checkboxes (form): the systems most starters need.
               Help: Anything else can be asked for later with
               "Get access to a system".

Section shown when Works from = Remote or Both:
  Home address  Paragraph.
                Help: For delivering equipment only.

Agent sub-tasks (Automation, on Work item created):
  Create accounts / Prepare equipment / Book the first-day induction

Two habits make any of these better. Keep help text to one or two lines with an example, because a long one is not read. And ask only what the agent needs to start: anything that comes later can be a form added to the request once it is open.

We make Recurring Requests & Templates for Jira Service Management. That is why this page exists. This section describes the app as its documentation stands on 21 October 2026.

What it adds

Everything above sets up the request type: the blank form every customer starts from. The app works one level down, with requests a customer has already raised. In the portal, a customer opens one and chooses Request again, and the details are copied in to edit before sending. From there:

• Raise it now creates the request straight away, as the customer, like one they filled in themselves.
• Repeat on a schedule raises it daily, weekly, monthly or quarterly, at the customer’s own time and time zone. Scheduling is off until an admin turns it on for the project and sets its limits.
• Save as template keeps the details so the customer can raise the same request again later in one click. Nothing is created until they click Raise it now, which is why templates are on by default.

An attached form comes across with its answers, tables and choices included. Customers find their schedules and templates under My recurring requests in the portal.

Where the app stops

• Its templates belong to the customer who saved them. Its documentation describes templates customers save for themselves. It does not describe templates an admin publishes for everyone; for that, the request type is the template.
• Not everything is copied. Files, participants and organisation sharing, answers on any form after the first, and fields that pick a record, such as Affected services (what is not copied).
• It adds nothing for agents. Internal sub-tasks and checklists are the Automation rule above.

Our other app, Issue Templates & Create Defaults for Jira, is for Jira software and business projects: it adds no templates to the Jira Service Management portal or to request types, and we have not tested it in service projects.

Prices are on the app’s Marketplace listing.

Our plain advice: spend the time on the request type first. Clear names, portal groups and one line of help text per field do more for consistency than anything else here, and they cost nothing. Add a form when the questions depend on earlier answers, and an Automation rule when agents repeat the same internal steps. Consider an app when your customers send the same request again and again.

Does Jira Service Management have request templates?

For admins, yes: a library of request type templates, and form templates for the forms you attach to request types. Both are starting points that you edit afterwards. For customers, the request type is the template: its request form decides what they are asked, in what order and with what help text.

Can a field on a request type have a default value?

A custom field can have a default value in its context, which customers see on the request form. A field can also be given a preset value and hidden from the portal, so it is filled in without the customer seeing it. The system Description field cannot have a default; Atlassian’s workaround replaces it with a custom Paragraph field that has one.

Can a request form show or hide questions depending on the answers?

Yes, with a form attached to the request type. A form section can be shown or hidden depending on a radio button, checkbox or dropdown earlier in the form. Atlassian’s knowledge base says multi-select dropdowns cannot trigger conditions.

Can every new request get the same internal tasks for agents?

Yes, with an Automation rule on Work item created that creates sub-tasks. Sub-tasks are internal: they have no request type, customers do not see them on the portal and are not notified about them. Every run counts towards your Automation usage.

Can customers save a request and raise it again later?

The Atlassian pages we read describe no way to do that. Our app, Recurring Requests & Templates for Jira Service Management, adds it to the portal: a customer opens a request they raised before and raises it again, puts it on a schedule, or saves it as a template. Files, participants and fields that pick a record are not copied.

• Jira issue templates in Jira Cloud: the hub. Default descriptions, block templates, Automation, cloning and request types, and where each stops.
• Jira default description: a description template for each work type, and the Description field’s missing default.
• Jira templates with sub-tasks: the same children under every epic or work item.
• Request templates in Jira Service Management: this page.

Also useful:

• Recurring tickets in Jira Service Management after Automation step billing: what Automation steps cost, and when another way is better.
• Recurring Requests documentation: Request again, schedules, templates, closed days and what is not copied.
• Jira incident template: free text for an incident’s description.

Every statement about Jira Service Management on this page comes from the Atlassian pages below, read on 21 October 2026. Where Atlassian’s pages did not say something, we left it out. The four request types are our own suggestions, not Atlassian’s templates.

• What are request types? (checked 21 Oct 2026)
• The benefits of using request type templates (checked 21 Oct 2026)
• Create request types in company-managed spaces (checked 21 Oct 2026)
• Manage request types in team-managed projects (checked 21 Oct 2026)
• Duplicate a request type (checked 21 Oct 2026)
• Set up request forms and work item views for request types (checked 21 Oct 2026)
• Set default value for the Description field in JSM request forms (KB) (checked 21 Oct 2026, last changed 26 Aug 2026)
• JRACLOUD-4812: Default values of system fields (checked 21 Oct 2026)
• What are forms? (checked 21 Oct 2026)
• Create or edit a form (checked 21 Oct 2026)
• Add a form to a request type (checked 21 Oct 2026)
• Use Forms to set Conditional fields in service projects (KB) (checked 21 Oct 2026, last changed 30 Jan 2026)
• Organize your request types into portal groups (checked 21 Oct 2026)
• Set up article suggestions in request forms (checked 21 Oct 2026)
• Jira automation triggers (checked 21 Oct 2026)
• Jira automation actions (checked 21 Oct 2026)
• JQL fields (Request type) (checked 21 Oct 2026)
• Permissions required to manage automation flows (checked 21 Oct 2026)
• How is your automation usage calculated (checked 21 Oct 2026)
• Resolve Sub-task Email Notification Issues in JSM Cloud (KB) (checked 21 Oct 2026, last changed 26 Sep 2025)
• Clone a work item (checked 21 Oct 2026)
• JSDCLOUD-14350: Cloning with Automation does not set the Request Type (Gathering Interest) (checked 21 Oct 2026)

Changelog

• 22 October 2026. First version.

Corrections

None yet. If something here is wrong, email [email protected]. We will fix it and say so here.