Public forms are coming to Jira

[Greg D]

I was just clarifying this in another community post, so I figured I would check in here too. Any updates @Loretta Brunette

Right now there are effectively two different form systems in Jira Cloud, which is why this feels messy:

1. Advanced Forms (ProForma-style) - setup lives in the Jira space settings

• Primarily tied to Jira Service Management, where they’re the standard experience
• Support form‑only fields (no Jira field required), richer layouts/sections, and form-specific automation
• Great for complex intake, service workflows, use-cases where you need more control over conditions around answers and default responses, etc.
• Allow for a many-to-one relationship between form and Jira work item (you can add a bunch of different forms to your Jira work item/request

They do work in Jira directly in some environments, but that’s usually via exceptions / special configuration these days with new sites. The catch: to submit through these forms into Jira and not JSM, you generally need a full Jira license, so they’re not ideal for broad, open intake.

---

2. Native Jira Forms – Jira Software / Work Management - setup lives on a tab (where boards, list view, calendar, etc. live)

• Started in Jira Work Management / team‑managed projects as a basic space-admin controllable create screen without much in the way of features
• Became the standard forms builder in Jira Software around the time of merging JWM into just Jira (both form settings were available at this time with advanced being a little more hidden)
• Atlassian picked these as the long‑term direction outside of JSM
• Can:
  • Act as a modern issue collector
  • Be made public via open links (woohoo)
  • Use conditional questions now (hooray)

Constraint: every question ultimately ties back to a Jira field (boo), so they don’t yet match the flexibility of the more advanced/ProForma-style forms.

---

Net result

• You lean on the advanced forms when you need serious layout options, form‑only fields, more features on intake, and tight workflow hooks (and your licensing model can handle it)
• You lean on native Jira forms when you need lighter intake and public / low-friction access in Jira Software or Work Management

Both are useful; both are limited in different ways.

I really hope that there will be a way to open up the advanced forms, have form-only fields on the basic forms, and have a controllable permission setting available in schemes that is separate from the regular create button for both of those.

[Loretta Brunette]

Hi @Greg D - apologies for my delayed reply here. I have moved teams but I have passed on your feedback to the team responsible for forms - thanks for sharing. There is currently nothing roadmapped for these items but the team will continue to monitor feedback and provide updates once this changes. I hope for now, the existing forms capabilities are able to meet your use cases. Thanks again

[Mykenna Cepek]

I appreciate what @Greg D wrote above. And I want to temper a few parts of it with my perspective.
 

[Advanced Forms] do work in Jira directly in some environments, but that’s usually via exceptions / special configuration these days with new sites.

I was pleased to notice recently that Advanced Forms are directly available now in our Jira Cloud Enterprise via "Space settings > Work Items > Advanced Forms". No need now for a Space Shortcut to the secret URL!
 

The catch: to submit through these [Advanced] forms into Jira and not JSM, you generally need a full Jira license, so they’re not ideal for broad, open intake.

An addition to this catch: the submitters of Advanced Forms also need the "Create work items" permission. The matching Role in your Permission Scheme(s) might provide other grants as well -- would "Manage sprints" concern you?
 

[Advanced Forms] allow for a many-to-one relationship between form and Jira work item (you can add a bunch of different forms to your Jira work item/request

I noticed recently that there's another one-to-many relationship. One Advanced Form can now align to more than one Work Item Type. You can create a separate Direct Link to each Form+Type combination. Each form submission still creates just one Work Item of the selected Type.
 

[Native Jira Forms] can: Be made public via open links (woohoo)

Hey Atlassian: if you can do this for Native Forms, we know you can do it for Advanced Forms too!

And also: thanks for the recent updates to Advanced Forms. Nice to see them getting some love.

[James Woyciesjes]

@Mykenna Cepek When you say that Adv Forms is available in Jira Cloud Ent, are you referring to JSM only?

[Olha Yevdokymova_SaaSJet]

Hello everyone!

There are actually two separate forms systems in Jira Cloud right now, and they're not being merged:

Native Jira Forms (Jira Software / Work Management) — the ones this article is about. They live in the project nav alongside Boards and Backlog. They now support public access with reCAPTCHA, which is great for lightweight external intake. The constraint that comes up a lot in this thread: every question has to tie to a Jira field. You can't collect data that just lives in the form — it has to map somewhere. That's fine for simple intake, but it limits flexibility for more complex workflows.

Advanced Forms / ProForma (primarily JSM) — richer feature set, form-only fields, sections, more layout control. These are now also accessible in Jira Cloud Enterprise via Space Settings (as Mykenna noted above). The tradeoff: submitters still need a Jira account to submit into non-JSM projects, and as Loretta confirmed, public access is not coming to Advanced Forms outside of JSM.

So the question many teams hit is: native forms cover my basic case, but I need one more thing — and that one thing isn't on the roadmap.

A few recurring themes here that are worth addressing directly:

"We need attachments." — Attachment support is now rolling out for native public forms. 

"We need to embed the form on our website." —. This is one of the clearest gaps between native forms and what teams actually need for customer-facing portals, intranet pages, or partner intake. Embedding via iframe is supported in apps like Smart Forms for Jira — you can drop the form into any website, Confluence page, WordPress, or Wix, and every submission still creates a structured Jira issue.

"We need a confirmation email to go to the submitter." — Joanne raised this, and Sandy shared a clever workaround using Jira Automation. That works, but it requires setup. 

"The email requirement is a blocker for anonymous forms." —  a real pain point: native public forms require an email address from unlicensed submitters. For use cases like internal satisfaction surveys, post-mortems, or HR forms where you explicitly don't want identity tracking, that's a problem. Anonymous response mode (where submissions aren't linked to a submitter email) is something Smart Forms for Jira app fills today.

"We want to attach a form to an existing issue, not just create new ones." — Marvin Brand described this use case, and actually linked to Smart Forms as a reference for it. This is a distinct workflow: you have an open ticket, you want to send a form to the customer or an external stakeholder, and when they respond, their answers update the issue fields. It's useful for approval flows, post-support NPS, vendor data collection, and onboarding checklists. Native Jira forms don't currently support this.

"We want to reuse the same form across multiple projects." — Not explicitly raised in this thread, but a common follow-up when people start scaling forms usage. Native forms are project-specific; you can't clone or share a form template across projects. This is something marketplace apps handle.

About Smart Forms for Jira

I work at SaaSJet — we build Smart Forms for Jira, which was actually referenced organically earlier in this thread by Marvin Brand when asking about the "attach form to existing issue" use case.

It's designed to work alongside native Jira functionality, not replace it. For teams where native forms cover the need, there's no reason to add an app. But for the specific gaps above — embedding, anonymous submissions, form-to-existing-issue, cross-project reuse, custom branding, response exports, JPD integration — that's exactly the space it fills.

A few things that come up a lot with teams evaluating it:

• It works across all Jira products — Jira Software, JSM, and Jira Work Management, without the form-system confusion described above
• Forms don't need to tie to Jira fields — you can collect what you need and map selectively, or use responses purely for analysis without creating issues
• External sharing is built in — public links, embed code, Confluence integration, QR codes. No Jira license required to submit
• The "attach to existing issue" workflow — you can add a form to an open issue, share it externally, and have responses automatically update the issue's fields. Works with Jira Automation so you can trigger the share via automation rules
• Branding — background colors, fonts, images and custom submit messages with work item key and work item link.

If you're working through any of these specific scenarios and want to know whether it's the right fit, happy to answer questions here. No obligation — sometimes native forms genuinely do the job, and I'd rather help you figure that out than push a solution that isn't needed.