RFC-88: Public forms in Jira

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.

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

4 Likes

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.

3 Likes

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.

2 Likes

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?

3 Likes

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.

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.

@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