Structured Intake, Every Time: Best Practices for JSM Request Templates

[#1]

Ever watched an employee submit "My laptop is broken" through your internal JSM portal, only to land on the exact same blank text box as a coworker requesting a brand new laptop? Both requests often map to the same work type behind the scenes, so both get the same generic form. The employee types out details in free text, the IT agent reads it, and then re-asks half of what was already said just to fill in the fields that actually matter. Multiply that across a busy service desk and it adds up to a lot of avoidable back and forth.

The fix isn't a better work type. It's matching the form to the request, not just the ticket type it eventually becomes.

Why work-type templates fall short in JSM

Most portals collapse many request types into a handful of work types for reporting simplicity. That's reasonable for triage, but it means template logic tied only to work type can't tell "Hardware Issue" apart from "New Equipment Request," even though employees experience them as completely different asks. The result is either one form too generic to be useful for anyone, or admins hand-rolling workarounds with conditional fields or Scriptrunner Behaviours to fake the distinction.

Building templates around request types instead

Here's the practice we've landed on after building this for JSM support directly:

1. Start from the employee's language, not your schema. List out the request types your service desk actually exposes to end users, since that's the vocabulary employees use to describe their own problem, not the work type it eventually becomes.
2. Define the template once, apply it everywhere it's needed. In Issue Templates Pro, templates are created once under Top Nav → Apps → Issue Templates, then reused across projects and request types instead of rebuilt per project.
3. Let the portal apply it automatically. As of the latest release, templates now apply directly in the JSM Portal when an employee creates a request, pre-filling the summary and description fields before anyone types a word.
4. Prioritize by volume. Start with your two or three highest-traffic request types. That's where structured fields save the most agent time, and it gives you a fast before/after to point to internally.
5. Automate the edge cases. For templates that depend on conditions (region, department, priority), apply them via Jira Automation rules or the REST API instead of hardcoding logic into the template itself.
6. Test as an employee would. Submit a request through the live portal, not just the admin preview, since portal rendering and admin preview don't always match.

What it looks like in practice

Once the template is mapped to the request type, the employee never sees a blank description field at all. Opening "Report broken hardware" in the portal surfaces a form with device type, reported issue, and urgency already written in as structured, labeled bullets, still fully editable, so the employee only has to fill in or adjust what's actually specific to their situation, like when the problem started.

How this differs from native forms, automation, and scripts

Native Jira and JSM forms can mark a field as required, but required only means the employee can't leave it blank, not that it's filled in with anything useful. The field still starts empty, and the employee still has to know what to type. Compared to native forms, templates actually fill in the fields, and leave them editable, rather than just presenting an empty box that happens to be mandatory.

There are also more technical ways to get similar results without a dedicated template app: Jira Automation rules, or scripts like Scriptrunner Behaviours. Both can work, but each comes with trade-offs worth naming honestly.

Automation rules only run after a ticket is created, so you're reacting to a ticket that already exists rather than shaping what the employee sees while they're still filling out the form. Confirming a rule behaves correctly usually means creating a test ticket, checking the result, and repeating that for every request type you want to cover.

Scripts can pre-fill fields at creation time, but changing something as small as the wording of a field means editing code, not a text box, which is a real barrier for non-technical admins who inherit the setup later. And like automation, the effect isn't visible until you actually run a ticket through it.

Both routes also carry ongoing cost at the instance level: automation rules add execution overhead as they scale across projects, and scripts become a maintenance burden for whoever has to touch them next.

With template-based pre-fill, what you configure is what the employee sees in the portal immediately, no test ticket required to confirm it worked, and no code to edit if you just want to change a word.

The payoff for agents

The advantage isn't only a smoother employee experience. IT agents stop being the ones who translate a vague sentence into the fields they need for triage, because the employee's submission already carries that shape. On high-volume portals with many overlapping request types, that's often where the real time savings show up: not in the form itself, but in everything downstream of it.

How are you currently handling templates across different request types in your JSM portal? I'd be curious to hear what's working, and what isn't.

Issue Templates Pro, including the new JSM Portal support, is available on the Atlassian Marketplace.