Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
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 effectivelytwo 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 toJira Service Management, where they’re the standard experience
Supportform‑only fields(no Jira field required), richer layouts/sections, andform-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
Theydowork in Jira directly in some environments, but that’s usually viaexceptions / special configuration these days with new sites. The catch: to submit through these forms into Jira and not JSM, you generally need afull 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 inJira Work Management / team‑managedprojects as a basic space-admin controllable create screen without much in the way of features
Became thestandard forms builderin 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 directionoutside of JSM
Can:
Act as a modernissue collector
Be madepublicvia open links (woohoo)
Useconditional questions now (hooray)
Constraint: every question ultimately ties back to aJira field(boo), so they don’t yet match the flexibility of the more advanced/ProForma-style forms.
Net result
You lean on theadvanced formswhen 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 onnative Jira formswhen you need lighter intake andpublic / low-friction accessin 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.
Atlassian Team members are employees working across the company in a wide variety of roles.
March 15, 2026 edited
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
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
I appreciate what @Greg D wrote above. And I want to temper a few parts of it with my perspective.
[Advanced Forms] dowork in Jira directly in some environments, but that’s usually viaexceptions / 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 afull 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 madepublicvia 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.
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.
> [Advanced Forms] dowork in Jira directly in some environments, but that’s usually viaexceptions / 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!
So... in JSM, Advanced Forms are just called Forms in the menus.
Advanced Forms specifically refers to the old ProForma forms when they are enabled in Jira Software, Work Management and Business Projects. Yes indeed, we could get these forms on non-JSM projects.
Mykenna refers to "a Space Shortcut to the secret URL".
So way back in December 2024 @Loretta Brunette (Oh hi again!) wrote:
We have no current plans to remove Advanced Forms for those who have it enabled, nor to block the direct URL access.
(Emphasis mine.)
So Loretta, can we assume "plans" are no longer "current", and people who never requested that Advanced Forms be enabled (and I'm never accessed the direct/secret URL and/or created Advanced Forms) can no longer get the feature?
[I imagine if one is paying Enterprise price$, you can request it? What if you are one of the impoverished unfortunates on Premium, or god forbid Standard plans?]
And for those of us who were lucky to get Advanced Forms enabled before the cutoff (and can you divulge when that happened?), we're uh, good, right?
I asked Atlassian Support enable the Forms menu option in our Jira Software site, and it is now accessible as a menu option under Project Settings. Atlassian also confirmed that enabling this "hidden" feature has no adverse impact and does not invalidate our support/warranty cover.
I feel like a lot of sites would break if existing Advanced Forms functionality were deprecated for Jira Software, Jira Work Management, and Jira Business Projects.
I realize that Atlassian probably doesn't want to support "hidden" features, but JWMCLOUD-786 and all of its comments are very public, so it's not that hidden.
I know that we and other customers (Premium and who knows what other tiers) are actively depending on Advanced Forms, and so losing that functionality would be very painful.
At the same time, as a Community Champions and Rising Stars, we want to talk about solutions that everyone can get access to. And it feels kind of rotten that there's this EXCELLENT feature that is just out of reach for newer customers simply because they signed up for Atlassian just a little too late.
Reading @Olha Yevdokymova_SaaSJet 's pitch for Smart Forms, it does make me wonder if we would've been better off if you had never acquired ProForma back in 2021, and they could have maintained their support for all Jira projects, JSM as well as Software and beyond.
:-/
I understand business strategies shift. Priorities change.
There is definitely a lot of "yes, but" in this situation. Advanced forms were never really a feature—more like a workaround. It looks like someone just forgot to remove a few branches of code, perhaps with future hopes. 😁 But as Loretta mentioned, there were never any actual plans to develop that functionality.
Frankly, I don't think Atlassian is interested in fostering internal competition between Jira Software and JSM. Once you have advanced forms, you can easily figure out how to bypass JSM entirely, especially with the bunch of SLA tracking apps available.
Even us a vendor has a Solution with SLA Time and Report and Smart Forms for Jira, to reduce customer cost for CMS needs, reproduce customer portal functionality in software project, with all these different request forms, with the possibility to select request types, placed somewhere for example on confluence and creating task in dedicated project with SLA tracking without JSM at all
And for some people it works, so I guess Atlassian is not interested in giving it for free for those who already subscribed to Jira and need something more like JSM. And Proforma itself was a paid app, so as we, maybe bought with the same reason to stop it's development that creates JSM competition.
While some might dislike marketplace vendors promoting their apps, feature gaps represent possibilities for both of us. For vendors, it's a market; for you, it's a way to get those gaps filled—especially since the Jira feature request board is permanently overflowing.
A smaller vendor team usually means better support and the flexibility to get features developed specifically for your company, as smaller teams can easily shift priorities.
For example, by the end of the month, we plan to release real-time calculated fields in forms, a permission scheme allowing multiple people to edit the same submitted form instance, an API for form responses, and tables inside forms. These were all direct customer feature requests. A giant like Atlassian could take years to implement those, if they even bother at all. Your point that "clarity is so so so important" cuts both ways. Customers need it, but vendors building on the platform depend on it too. Feature limbo like this creates real planning headaches for everyone, not just end-users. At the end of the day, it's just business—for Atlassian, for us, and likely for you too. :)
So, if you need the flexibility to use forms everywhere (JSM, JPD, Jira Software) and a lot of other features, you know what you can try! 😁
82 comments