What's the difference between "request types" and "forms"?

[Rach O'Neill]

Hello! I've been building a service desk for our team to share with the rest of our organisation, we help with their digital enquiries. I built all of my forms to show on the portal, these were built through request types as "forms" didn't exist when I was building it! So now I'm just a bit confused, what's the benefit of the new forms section? Is it any different to the request types?

Thanks!

[Mark Segall · Accepted solution]

Hi @Rach O'Neill and welcome to the community!  The enhanced forms feature provides more flexibility to streamline the portal experience.  Here are a couple use cases:

• General flow of the form - Maybe you want to have certain fields grouped together in a 2 or 3 column layout vs the standard 1-column you get with out-of-the-box
• Visibility based upon dependency - Let's say you only want to show a field if some other condition is met on the form (e.g. user selects a specific checkbox)

There are other benefits, but those are off the top of my head.

Note - At this time, I personally see forms as a complimentary feature to the native JSM form.  There are still a few areas that cannot replace the native request form experience (e.g. Summary, Attachments, Insight Fields, etc.).  

[Rach O'Neill]

Hey @Mark Segall - thank you so much for getting back to me! 

Ahh okay - so it is perhaps more for appearance? I've set up all my requests as individuals. Whereas I suppose in a form setting you could set it up in one form with conditions to create the ticket?

This is really useful thank you! I was very concerned everything I had built was completely irrelevant now! Thank you so much :) 

[Johanna Malchow]

Hi Rach, I have also wondered about this, let me know if since your question you have figured out any other benefits of forms over request types :)

[Mark Segall]

Hi @Johanna Malchow - Another major benefit is for collecting additional information after initial request submission... For example, let's say you have an application process.  You collect certain information to initiate and then after an approval, you want to collect more information.  In this case, you can set up an automation that attaches a separate form to collect the additional information and then once they've submitted the completed form, another automation triggers to move the issue to the next step.

Forms are a very impactful add to the JSM experience, but there are a few caveats you have to consider in your deployment strategy:

• Summary field - The portal form needs it.  Technically, you can hide it and set a default value, but summary is still a critical field for delineating issues from each other so it's worthwhile to keep that exposed on the portal form and then have the form do the rest of the work.
• Unsupported components:
  • Attachments - Atlassian is close on this one (I've seen a demo and it's good stuff coming). However, until then attachments are not supported by forms just yet so you need the portal form to present them.  This also raises a UI challenge.  The form always loads below the portal form so your attachments section will appear above any form data - not really the best flow for a form as most call for it at the end.
  • Insight Fields - Another one that Atlassian is well aware of... You cannot present insight fields on a form.
• Maintenance Overhead
  • The way the form links to select fields is a one-time copy.  So, each time the field gets updated, you need to go back to the form and resync the form to the Jira field.  Best practice is that most select fields are updated infrequently, but still something worth considering.
  • Forms cannot be centralized.  If you want to have multiple projects share a form, you're out of luck. The form has to be copied to each one.  Because of this, there's no ability to create a multi-project scope automation rule.  Depending upon the number of projects, this can create a bunch of overhead.