RFC-64: Forms in Jira Software Projects

[LorettaBrunette]

Discaimer: 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 extending the forms available in Jira business projects today, to Jira software projects. This will give customers a new way to intake work from stakeholders. Only Jira and project admins (or users with project admin permissions) will be able to create, edit and delete forms. Forms will be available for all licence editions and will be accessible from a projects navigation. They will be available to toggle on/off in project settings. Forms are scoped to a single project and issue type within that project.

In addition to this project, we also have a number of other enhancements coming to forms in the coming months. These include form templates, L1+ issue type support, required fields, field descriptions and conditional logic.

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: 09 September 2024
• Discuss: 24 September 2024

Problem

We are excited to announce that we are adding forms to Software projects in Jira. This new feature will make it easier for our users to intake work from other teams or stakeholders - from ideas and feedback to requests for deliverables and specific project tasks. If a forms access is set to open, then anyone who can log into that Jira site can submit a form, meaning work intake can be extended to more stakeholders.

Forms exist in business projects today and by extending this to software projects, we will be closing the feature gap between the project types as we merge into one Jira to better serve all teams.

Proposed Solution

We will be extending the forms capability available in Jira business projects today, to software projects. Forms will be available by default in the projects navigation, but will be available to toggle on/off in project settings by an admin. Only Jira and project admins (or users with project admin permissions) will be able to create, edit, and delete forms. Forms will be available for all licence editions.

Forms include a number of key features:

• Access types: 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).
• Multiple forms: there is no limit on the number of forms that can be created for a project and a form can be created for any/all L0 issue types within the project
• Change a fields name: within a form, the name of a field can be changed to suit the context of a form. This change will apply to the form only and not to the issue configuration
• Embed forms: forms can be embedded into the ADF editor, such as on a Confluence page, for easy access by stakeholders

As we work on bringing this capability to software projects, there are a number of other enhancements we are making to forms, that will also apply in business projects. These enhancements are all in progress and are set to rollout in the coming months:

• Support L1+ issue types: currently, forms can only be configured to create any L0 issue type within the project. We will be improving this, so forms can be sed to create L1 issue types and above.
• Field descriptions: within the form builder, a form creator will have the ability to add a description to their field or question, to help submitters accurately complete the form.
• Required fields: if a field is required to create an issue in a project today, this will automatically be required on all forms in that project. We will also be adding the ability for a form creator to mark a field as required directly from the form builder. This will apply to the form only and not to issue creation from other sources within the project.
• Conditional logic: to enable specific questions to be displayed or hidden, based on the answer selected in previous questions. Conditional logic will be available for selected fields only (likely single and multi select custom fields but this is tbc).

Our plan is to roll forms out to software projects in October 2024.

We have no current plans to merge with the forms capability available in Jira Service Management and there will be no changes 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 in the future.

[tobias.viehweger]

Hi Loretta,

thanks for the heads up! I’m a bit afraid to ask, but is this not built on the ProForma forms that is being used in JSM? Because you mention that there is currently no API, but we are using this Forms REST API in our app already: https://developer.atlassian.com/cloud/forms/rest/intro

Would be interesting to understand how this relates to one another…

[LorettaBrunette]

Hi @tobias.viehweger - thanks for the question! we did look at ProForma and we explored whether to extend this to Jira business and software projects, or to invest in the forms available in business projects today. As a result of a few factors, including what Jira customers need from forms, we decided to invest in business forms. There are currently no plans to change ProForma in any way (and any customer who currently has ProForma turned on in their business and software projects will continue to have access to these)

[sunnyape]

Hello @LorettaBrunette

Where you said “forms can only be configured to create any L0 issue type within the project. We will be improving this, so forms can be used to create L1 issue types and above”. Given that Sub-tasks issue types are down are at level -1, does this mean that there is currently no intention to support the lower Sub-task level?

Can it be assumed that, like Workflows, changes made to Forms will not be logged? If so, can the Form’s logic be exported for possible importation later?

[LorettaBrunette]

Hi @sunnyape - correct, forms won’t be able to be configured to a subtask, given a subtask must have a L0 parent.
And yes, like workflows, there will be no logs of changes made to the configuration of a form. We have no current plans to enable the exporting of logic but can you explain more about your need here?

The above is based on our current plans, but we will of course monitor feedback post rollout and design improvements based on these

Thanks for your interesting questions!

[sunnyape]

Thanks for the clarification about the levels @LorettaBrunette

With regards a need for logging changes to Forms, organisations often are lax in their allocation of permissions to people at the Project Admin level to make changes to things like Forms (or Workflows). This sometimes results in the equivalent of ‘change wars’, where one person does a change that someone else with equivalent permissions can over-ride, adversely or not, without evidence of doing it.

Just like the lack of logging of Workflow or Workflow Scheme changes, in the event of something going wrong, there are no auditable records to answer the question “Who did that and when?” and then hold that person accountable or take measures to prevent the same thing happening in future. Currently, it’s just an abstract mutual trust function, and that’s never a good starting point from a security or change management perspective.

With regards the ability to export and then import Form logic, like Workflows, it does allow for the possibility of quickly returning a Form to a prior state in the event of any accidental or even maliciously adverse change that occurred .

[LorettaBrunette]

thanks for the additional context @sunnyape . These specific needs didn’t come up in our research to date, but your feedback makes sense to me. We will monitor feedback as we rollout our changes and see the volume of usage of forms in the product

[MaksimBeliaev]

hi @LorettaBrunette We’re already using forms in Jira Software (via direct URL), but one of the main issues we face is the inability to predefine multi-line text fields.

For example, when users submit a bug, we want them to follow the company policy for filling out the description. While we could create multiple fields to capture all the details, it’s less convenient at this stage compared to having a simple template with a default multi-line description.

[PaulStallworth1]

You should abandon your JWM forms and spend the time to integrate ProForma into JSW. The features already exist that you don’t have and admit are going to have to spend developer time to build from scratch. Atlassian bought ThinkTilt for a reason. Speaking of what customers need, here’s a customer asking for conditionals that didn’t exist in JWM in 2023: https://community.atlassian.com/t5/Marketplace-Apps-Integrations/Conditional-Fields-in-Jira-Work-Management-JWM/qaq-p/2423125. Atlassian also spent a lot of time talking about and building a platform level editor experience that would be similar across products and field types. Why are you not taking the same approach and standardizing your form implementation? Just my $0.10.

[NarshaBachoo]

Hi, can we query a form? Using JQL or another way to get information on the forms?

[LorettaBrunette]

interesting @NarshaBachoo . The issues created from a form can be queried with JQL but not the actual forms themselves. Can you explain more about what you would like to do here and the value it would offer? thanks!

[LorettaBrunette]

thanks for the feedback @PaulStallworth1 - extending JSM forms i.e. ProForma is definitely something we explored in detail and we landed on the decision to invest in forms in business projects for a number of reasons.