How to Set Up Jira Forms in 2026: Build Smart Intake Forms Without an App

Why Jira Forms beats a free-text description field

Most intake breakdowns I get called in to fix come down to the same root cause: teams ask requesters to “just describe what you need” in the Jira description field. The result is a queue full of tickets that are missing the environment, the priority justification, the affected system, the cost center, or the deadline — so the first thing an agent does on every ticket is bounce it back for more information. That round-trip is where your SLA quietly dies.

Jira Forms removes the round-trip. Instead of a blank box, the requester answers structured questions, and the answers land in real Jira fields you can filter, automate, and report on. For a 12-person service desk I worked with, switching three high-volume request types from free-text to forms cut their average “waiting for customer” time roughly in half within a month — not because agents got faster, but because the tickets arrived complete. That is the business case in one sentence: complete intake means fewer touches per ticket.

Because Jira Forms is now native in Jira Cloud, there is no procurement conversation, no app security review, and no per-user surcharge to start. You are configuring something Atlassian already ships, which is the cleanest possible path to better data.

Native Forms vs. the old ProForma app: what changed

If you remember installing ProForma: Forms & Checklist for Jira from the Marketplace, that is the lineage here. Atlassian acquired ProForma and folded its form-building engine directly into the product. The practical implications for 2026:

1. Jira Cloud — Forms are enabled by default. You’ll find them under your project’s settings; there is nothing to install.
2. Jira Service Management Data Center 10.3 and later — The forms capability is included free of charge, so self-hosted service desks get it without a separate license.
3. Jira Service Management 10.2 or earlier, and any Jira Software Data Center version — You still need a valid ProForma license to use forms.

The terminology shifted too. What community posts still call “ProForma forms” Atlassian now documents simply as Forms, and in service projects the controls live under Request management rather than a standalone app configuration screen. If you’re following an older tutorial and can’t find a menu item, that rename is usually why. Atlassian’s current create or edit a form documentation reflects the native naming.

How to build your first Jira form (step by step)

Only project admins can create and edit forms, so confirm your role before you start. The walkthrough below is for Jira Cloud; Data Center is nearly identical once forms are enabled.

1. Project settings → Forms — From your project sidebar, open Project settings, then select Forms (in a service project, go to Project settings → Request management → Forms).
2. Create form — Click the Create form button and give it a clear, requester-facing name like “New Laptop Request” rather than an internal code.
3. Add a question — From the right-hand panel, drag question types onto the canvas: short text, paragraph, choice (radio, checkbox, dropdown), date, number, and attachment are the workhorses.
4. Group with a Section — Use Sections to break long forms into logical blocks (for example, “Requester details,” then “Hardware specs”). Sections are also the unit conditional logic acts on, so plan them deliberately.
5. Mark fields required — In each question’s settings, toggle Required for anything an agent genuinely cannot proceed without. Resist the urge to make everything required; over-gating drives abandonment.
6. Map to a Jira field — For each question, open the field-mapping option and connect it to an existing Jira field (covered in detail below). Unmapped answers still save on the form but won’t populate reportable fields.
7. Preview, then save — Use the preview to fill the form as a requester would, confirm the flow reads naturally, and save.

If your team is already comfortable structuring work in Jira, this will feel familiar — it’s the same discipline you apply when you design Jira Work Management for business teams, just pointed at the intake step.

Adding conditional logic so the form adapts

Conditional logic is what separates a form from a glorified questionnaire. It shows or hides sections based on earlier answers, so a single “IT Request” form can serve hardware, software, and access requests without showing every requester all 30 questions. Here’s how to wire it up:

1. Create a trigger question — Build a choice question (radio button, checkbox, or single-select dropdown). Note that multi-select dropdowns cannot currently drive conditional logic, so use single-select for the trigger.
2. Select the Section to control — Click the section you want to appear or disappear, then choose Create logic in the right panel.
3. Set Show or Hide — Under Visibility, decide whether the section should Show or Hide when the conditions are met.
4. Define the condition — Pick the Field to evaluate, choose an Operator such as is equal to, and select the Value that must match (for example, show the “Hardware specs” section when Request type is equal to “New device”).
5. Combine conditions — Use + AND to require several conditions together, or + OR to offer alternative triggers.

Atlassian’s conditional form fields guide documents the operators in full. My rule of thumb from years of building these: never exceed two levels of conditional depth. Past that, requesters lose track of why fields are appearing, and you’ll spend more time debugging logic than you saved on intake.

Attaching a form to a service request type

A form does nothing until customers can reach it. In Jira Service Management, you surface a form by attaching it to a request type so it appears on the customer portal.

1. Space settings → Request management — From your service space, open Space settings, then Request management, then Request types.
2. Open the request type — Select the request type that should use the form (for example, “Report a hardware issue”).
3. Attach form — At the bottom of the request form, select Attach form.
4. Choose the source — Select Create from template to build a new form, or Select existing to reuse a form already in your space.
5. Publish and test — Save, then raise a test request from the portal as a customer to confirm conditional sections behave as designed.

Once intake is structured, the downstream automation gets dramatically easier. A form that captures “Priority” and “Affected system” as real fields lets you auto-route and auto-prioritize the moment a ticket is created — exactly the kind of trigger covered in our Jira automation rules setup guide. If you’re standing up a help desk from scratch, pair this with our Jira Service Management ITSM setup guide.

Mapping questions to Jira fields for clean reporting

This is the step teams skip, and it’s the step that determines whether your forms generate insight or just tidy-looking tickets. When a form question is mapped to a Jira field, the answer populates that field on the issue — which means it shows up in JQL, dashboards, and automation conditions. When it isn’t mapped, the answer is trapped inside the form attachment, invisible to reporting.

1. Map choice questions to select fields — Connect dropdowns and radio buttons to existing single-select or multi-select custom fields so values stay consistent and filterable.
2. Map priority and category to native fields — Wherever possible, map to Jira’s built-in Priority, Components, or Labels rather than creating duplicate custom fields.
3. Reserve free text for genuinely unstructured input — Map the “describe the problem” paragraph to the Description field, but keep everything you’ll ever want to filter on as structured questions.
4. Audit unmapped questions before launch — Any question without a mapping should be a deliberate choice, not an oversight.

Once the data is clean, it flows straight into reporting. You can slice form-captured fields with advanced JQL filters and surface them on Jira dashboards and custom gadgets for live intake visibility.

Five mistakes that ruin form-based intake

1. Making every field required — Over-gating spikes abandonment. Require only what blocks work.
2. Skipping field mapping — Unmapped answers can’t be reported on. This is the single most common regret I hear after launch.
3. Triggering logic from multi-select dropdowns — They can’t drive conditional sections; use single-select choice questions for triggers.
4. Building one mega-form for everything — Conditional logic helps, but if a form needs four levels of branching, split it into separate request types instead.
5. Never testing as a customer — Always raise a real portal request before go-live. The admin preview hides portal-specific quirks.

Frequently asked questions

Do I need to install ProForma to use Jira Forms in 2026?
In Jira Cloud, no — Forms is native and enabled by default. On Jira Service Management Data Center 10.3 or later it’s included free. Only older Data Center versions and Jira Software Data Center still require a ProForma license.

Can customers see forms on the Jira Service Management portal?
Yes. Attach the form to a request type under Request management, and it appears as part of the request form customers fill out when raising a request, including any conditional sections you’ve configured.

Why isn’t my conditional logic working?
The most common cause is using a multi-select dropdown as the trigger — those can’t drive conditional logic. Switch the trigger to a single-select choice question (radio, checkbox, or single dropdown) and confirm the section’s Show/Hide condition references the right field and value.

Do form answers show up in Jira reports?
Only if the questions are mapped to Jira fields. Mapped answers populate real issue fields you can filter in JQL and chart on dashboards. Unmapped answers stay inside the form and won’t appear in reporting.

Who can create and edit Jira forms?
Project admins (or space admins in a service project). If you can’t see the Forms option, you likely lack the admin role on that project.