Request templates
Shape intake so people ask your team for work in a form you can act on, and decide what the request form opens with.
Overview
A request is how someone asks a team for work: a bug, a feature ask, or anything else. A request template gives that ask a shape — the type, priority, labels, linked Key Results, and the questions the requester has to answer — so what lands in your queue is already actionable.
Request templates are the intake half of the templates platform. Alongside them a team configures intake: which template the request form opens with, and whether a request may be opened without one at all.
A request template always creates a request. It never creates an issue, which is what keeps a published intake link honest about where the ask goes.
Read Templates first for visibility, revisions, and diagnostics, which work the same for all three targets.
Where request templates are managed
Settings → Features → Request templates for the workspace, or
Settings → Your teams → <team> → Templates for one team.
Everything on the request templates screen is scoped to one team at a time,
selected under Target team. That is not a convenience — templates and intake
are configured per team, and there is no workspace default that a team inherits.
The screen has four parts:
| Section | What it does |
|---|---|
| Target team | Chooses the team whose intake and templates you are configuring |
| Intake | The default template, and whether requests may be opened empty |
| Templates | The templates offered to this team: the workspace's, plus this team's own |
| Preview submission | What this team's default template produces right now |
Create a request template
New template.Choose Standard to pre-fill a request, or Custom Form to ask the
requester questions first.
Name the template. The name and description are what a requester reads when choosing, so describe what this template is for.
Set Visibility. A workspace template is offered to every team that accepts
requests; a team template stays private to that team's intake flow.
What a request template can set
| Field | Behaviour |
|---|---|
| Request title | Pre-fills the title. Leave empty to let the submitter write their own. |
| Short description | The request's own summary line. |
| Body | Rich text that seeds the request's main document. |
| Type | Bug, Feature, or Other. |
| Priority | Urgent, High, Medium, Low, or no priority. |
| Target team | The team asked to handle the request. Leave open to use the team the request is opened from. |
| Labels | From the target team's request label catalog. Choose a team first — labels belong to one. |
| Key results | The outcomes this request supports. |
| Customer | The customer the request came from. |
| Contact | A contact at that customer. Needs a customer first. |
The requester is never a template field. Who filed a request comes from authentication, and a template that could set it would be a way to file in somebody else's name.
An external reference is unique per workspace, so a template that sets one works for the first request and fails afterwards. Ask for it as a form question instead.
Form templates for intake
Form mode is where request templates earn their place. Someone outside your team should not have to know your labels or your priority conventions; they should answer questions and get a well-formed request.
Add questions under Form fields. The available types are the same as for issue
templates: text, long text, dropdown, checkboxes, date, file upload,
instructions, and property questions.
The questions are asked inside the request composer, beneath the review panel, so the requester answers them and can still see everything the template filled in. Answers to everything except property questions are written into the request's main document, in the order they were asked, under the label each was asked with.
Request property questions can ask for Title, Description, Type,
Priority, Team, Labels, Key results, Customer, Contact, and
External reference. A property answer overrides the value you pre-set, so a
form can carry a sensible default and still let the requester change it.
A form template still applies its default properties. It collects and pre-fills; it does not choose between them.
Configure intake
Intake is the two settings that decide what happens when someone opens the request form for your team.
| Setting | Effect |
|---|---|
| Default template | The template new requests for this team open with |
| Allow requests without a template | When off, people must pick a template before opening a request for this team |
Together they produce five states, and the intake card names the one you are in:
| State | What people see |
|---|---|
| Not configured | Requests open empty. This is where every team starts. |
| Template only | New requests open with this template, and can still be opened empty. |
| Policy only | No template is set. Requests open empty. |
| Template and policy | New requests open with this template, and cannot be opened empty. |
| Blocked | No template is set, and requests cannot be opened empty — this team cannot receive requests. |
The blocked state is worth watching for. It is what happens when a team requires a template and its default template is later deleted: deleting clears the binding rather than the rule. The intake card says so explicitly and asks you to either set a template or allow requests without one.
Reset removes the default template and the blank-request rule together, so
requests open empty again. Existing requests are unaffected.
Preview submission
Preview submission shows what the team's default template produces right now,
resolved through the same code a real submission uses. It is the way to check a
template before publishing it, rather than filing a test request.
The preview reports three things:
- Removed while resolving. Values that could not be used and were left out — a label from another team, a person who no longer exists.
- Could not be confirmed. Values kept but not verified. They are flagged rather than dropped so an outage does not look like lost data.
- Cannot be submitted yet. Required answers are missing, and the form names them.
The preview resolves the saved template. Unsaved edits in the editor are not included.
Use a request template
Open the request composer and use the Template control. If the team has a
default, the composer opens with it already applied.
A direct link copied from a template row opens the composer with that template preselected. Following one never skips the review step: a requester sees exactly what picking the same template by hand would show. If the link points at a template they cannot use for that team, the composer explains why rather than quietly dropping it.
Once a template is applied, the review panel shows what will go into the request before it is created, including what the form still needs from the requester.
Manage templates
Open the … menu on a template row: edit, duplicate, copy a direct link, and
delete. Visibility is changed by editing the template.
Deleting stops the template being offered. Requests already created from it are unchanged and still record the template and revision they came from. If the deleted template was a team's default, the binding is cleared — check the intake card afterwards so the team does not end up blocked.
Editing mints a new revision. Changing only the visibility does not.
Errors you may see
| Message | What to do |
|---|---|
| Someone else changed this first | Reload the template and reapply your changes. |
| That template is not available to this team | It is scoped elsewhere, or creates something other than a request. |
| This team requires a template for new requests | Pick a template, or turn on Allow requests without a template. |
| Some required values are missing | Fill in the required questions before submitting. |
| Intake configuration could not be loaded | The current setting is unknown, so nothing is shown rather than guessed at. Try again. |
FAQ
Next
Last updated on