RFC-88: Public forms in Jira

[LorettaBrunette]

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Summary of Project:

We are adding a Public access option to the forms available in Jira business and software projects. Any user, including those without a Jira license, will be able to make a submission through a public form. This will enable teams to extend their work intake to all of their stakeholders.

Only users with project admin permissions will be able to create a public form and these will be available for all licence editions and both team managed and company managed projects. In addition, Jira admins will be able to disable public forms in their site.

An unlicensed user will be able to make a submission through a public form, but to view and collaborate on the work item created from their submission, they will need a Jira license.

There are no specific APIs or UI extension points currently available in Connect or Forge for forms. But we would love to hear your feedback and ideas on how we could provide value for existing or new apps in the future.

• Publish: Mar 13, 2025
• Discuss: Mar 28, 2025

Problem

Today, only users with a Jira license and access to the Jira site can make a form submission into a business or software project. This limits work intake for teams working with stakeholders in other teams, departments or external to their organisation.

Proposed Solution

We are excited to announce that we are adding Public access to the forms available in business and software projects in Jira. This new feature will make it easier for our users to intake work from all the stakeholders that they work with - from other teams within their organisation to external vendors, contractors and agencies. If a forms access is set to Public, then anyone with the form link will be able to make a submission.

Jira admins will be able to disable public forms (which will remove Public from the access dropdown on the form builder and also deactivate any existing public forms within the site) from product settings (accessed via global settings > products). There will be one setting for team managed projects and one for company managed projects.

Only users with project admin permissions are able to create and manage forms. Today, access to a form can be set to Limited (only those with access to create an issue in the project can submit a form) or Open (anyone who can log into the Jira site can submit a form). A third option, Public, will be available and this will enable any user with the form link to make a submission.

When Public is selected from the access menu, the project admin will need to select a default reporter for the work item created from a public form submission. Sensitive field types will be hidden from a public form. These include assignee, people, team, project, parent, sprint, version and label fields. Attachments will also not be supported on public forms.

As part of this release, we will also be enabling a Deactivate option from the three dot (more) menu in the form builder so project admins can deactivate and re-activate forms as needed.

Note - the designs shown below are subject to change

An unlicensed user will be required to enter their email address.

Once a form is submitted, the email of the submitter and a smart link to the form will appear as a comment on the work item created. Unlicensed submitters will need a Jira license to view and edit the work item created from the form submission.

Public forms will begin rolling out over a number of weeks from Mar 31, 2025

We have no current plans to merge with the forms capability available in Jira Service Management and there will be no changes from this project to any site which currently has these enabled for their Jira projects.

Ask

There are no specific APIs or UI extension points currently available in Connect or Forge for forms. But we would love to hear your feedback and ideas on:

• What APIs or UI extension points would help make your current apps better?
• What APIs or UI extension points would be useful for creating new app opportunities?

We welcome feedback and will consider this as we continue to refine forms in both software and business projects.

[tobias.viehweger]

Hi Loretta,

Thanks for the announcement! As we are using the existing API extensively already (https://developer.atlassian.com/cloud/forms/rest/intro/), that one would be the one to match for us. Our customer are using our app to submit forms from an external system, so we use the following:

• Get all fields and types of fields in the form to render it, that includes conditional rendering, external data etc.
• Submit the form

So for us, getting the form field information fully (per project) and being able to submit a form would be awesome! That would also include getting some info about the form config, like open access enabled or not and maybe some customizing like header image.

Kind regards
Tobias

[BenRomberg]

Thanks for the RFC @LorettaBrunette! Similar to @tobias.viehweger, we’re mainly interested in REST API support. As long as we can read and create forms and form templates with the new “public” access option and any related fields, like the new email address field for unlicensed users, we should be okay.

Our use case is cloning forms (and potentially form templates in the future), so we need to read the form of the issue to be cloned and create it in the cloned issue. We’re also using the Copy form REST API, which we would expect to keep the access option consistent.

[JaimeCapitelresoluti]

Hi @LorettaBrunette, and thank your for the RFC!
In our case, what would make a lot of sense for our Out of Office app is to have access to the assignee endpoint so we can allow customers to create delegation rules: when an assignee is out of office, the form is reassigned to the appointed delegate.
There might be additional use cases once customers start interacting with the forms, but this would be covering the essential functionality.

[BorisBerenberg]

Not really a question re: APIs or anything, but what does Atlassian expect here in terms of customers hacking together their own Service Desks using this instead of buying JSM?

[LorettaBrunette]

Hi @BorisBerenberg - its a fair question and I’m happy to answer as we did alot of exploration into this.
What Jira customers need is a way to intake work from all their stakeholders and to triage and prioritise this alongside their other planned with in a jira project. Using Jira with public forms as a service desk is very limited. JSM is a fully fledged service management solution for those teams needing a structured approach to full request management. JSM will continue to offer the unique features that support this: customer portal, SLA’s, knowledge base, virtual agents, queues etc and of course bi-directional communication with unlicensed help seekers.

[BorisBerenberg]

Ok then one more product question. Will this new functionality in any way replace or extend or align with the Jira Issue Collector … which does almost exactly the same thing but can also be hosted on other websites.

[LorettaBrunette]

@BorisBerenberg - another good question. We have no current plans to deprecate the issue collector. In order to do this, we would need to close the feature gap with form only fields (so form questions don’t need to be tied to an issue type field) and also enable a way for an embed code to be generated. We don’t have either roadmapped but these items are in our backlog for consideration

[anshuman]

Hi @LorettaBrunette

This is great news!

As others have pointed out, a REST API would be incredibly useful. In addition to that, I’d like to suggest two additional features:

1. A widget (similar to the one in Jira Service Management)
2. An iFrame embed option for forms

Use Case

Our product, Scroll Viewport, enables customers to create public-facing sites such as Help Centers and Documentation Portals by publishing content from Confluence. With embeddable forms, we see a valuable opportunity for customers to collect relevant information directly on their sites—seamlessly integrating Jira and Confluence within this solution.

Looking forward to your thoughts!

[LorettaBrunette]

@anshuman - thanks for the feedback and suggestions! What are the use cases you see for your product for Jira versus JSM? I have my own insights on this as per my reply above but interested in your thoughts and specific insights. And moreover, would one way intake suit these use cases? i.e. an external customer for example could submit the embedded form, but would not be able to follow on the work item created from it.

[anshuman]

We definitely see value in public forms across both Jira and JSM, but the use cases differ slightly.

Use Cases for Jira (vs. JSM)

While JSM is the go-to for structured support workflows, we see **Jira ** being used more broadly across teams—including product, marketing, and sales—who often don’t want the full JSM setup but still want simple intake options. A few examples:

• Quick feedback or survey forms embedded in documentation or release notes to collect user sentiment or feature validation
• Contact collection forms on marketing sites for campaigns or early-access programs
• Partner/vendor request forms for teams working with external collaborators on internal projects

These use cases are more about one-way intake, where tracking or replying via Jira isn’t expected from the submitter.

Regarding One-Way Intake

Yes—one-way intake works well for these scenarios. In fact, it’s often preferable. Teams want a lightweight way to collect structured input without the overhead of account creation or permission management. The key is being able to embed the form where the user already is—whether that’s on a public help site, a blog, or a microsite.

Thanks again for considering this, and happy to share more if helpful!

[rsisauri]

Hi Loretta,

First of all, thank you for sharing this RFC. This public form could be a great option for organizations. However, there is one issue that would prevent us from using this feature. When an unlicensed user submits a form to a software project, if the assignee comments or attaches files, the reporter does not receive notifications. Additionally, the reporter cannot view the comment or download the attached files.

[LorettaBrunette]

thanks for the feedback @rsisauri . Correct, these forms are solving for one way work intake use cases - helping teams get all of their work in to Jira. For notifications and the ability to collaborate on the work item created, the submitter will need a Jira license or alternatively, Jira Service Management may be a better solution.

[Piotrmiaek]

Hi, thank you for this RFC!

I have three questions:

1. Will the end user be informed in the UI that, as an unauthenticated user, they won’t be able to see any responses or updates to their submission?
2. Will the user receive any email notifications after submitting a public form? If not, what is the purpose of collecting their email address?
3. Will there be an opportunity to extend public forms via custom apps or Forge modules?