Dynamic Forms in Extension app for Jira Service Management vs Atlassian's Forms
Last year, the Australian company announced that ProForma (Forms) would be integrated with Jira. It may sound like a high risk for our Extension for Jira Service Management! The key feature of Extension, Dynamic Forms, is similar to Atlassian’s Forms when it comes to functionalities. In this article, we would like to briefly describe both apps to distinguish their strengths and weaknesses and maybe help you choose the best one.
What are Forms? Main functionalities of the app
Jira Forms plugin enables using conditional logic to dynamically show or hide fields. Forms app includes all of the fields in one place so that you won’t have to ask your Jira admin to reconfigure request types or create custom fields. The app can be used in the Customer Portal to get specific information from team members and clients when they create an issue or as a ticket progresses.
How to create a form?
A user needs to be a project admin to create and edit forms. They are created in Project settings in their dedicated section. First, we have to click Create form and choose the name. Then, we’re able to select fields we wish to display on our forms and edit their details. Then, it’s possible to group fields into sections with drag and drop. The app enables us to add tables, columns, information boxes, etc. Forms app also has 300+ premade templates to help get started with the tool. To use them, instead of selecting fields, we need to click on Templates. This will open a preview of templates that we can edit or use just as they are.
Forming a request type
To make a form appear for clients in our Customer Portal, we need to use it as part of the request form for a given request type. Forms are visible underneath any configured Jira fields. Once a form is set up, it can be reopened for updates even after a request has been raised. It’s set up in the Service project settings or Project settings section. We have to turn on the toggle next to the Request form and select request types from a drop-down list.
Creating an issue
Agents can add forms to existing tickets and collect more information for clients or from other team members as the issue status changes. In order to view or edit forms, we have to scroll down to the Forms section. At this point, it’s possible to just preview a form or make the desired changes.
Automation rules and connections between the objects
Forms allow to seamlessly link form fields to Jira fields. This makes workflow intuitive and simplifies communication between the stakeholders. Automation enables us to copy and add forms to issues. It also triggers actions that result from specific activities such as, for example, submitting forms. In order to do this, we need to define the criteria in the Project Settings in the Automation section. First, we create rules, then select triggers. If we wish to set conditions, actions, or branches as part of the rule, we need to select the New component. Then we choose whether we would like to add a new branch, action, or new condition. There can be automation rules which determine the attached forms or are related to actions like copying or attaching forms. Once we create and name our rule, we should save and activate it.
Dynamic Forms for Jira Service Management – features
Dynamic Forms is one of the Extension for Jira Service Management key features. The functionality lets us turn request forms into dynamic request forms. This means that we can make fields in Jira Service Management dynamically displayed in response to user input. Dynamic Forms can be assigned to specific request types.
Creating Jira dynamic forms
To add a dynamic form, go to Project Settings and then the Customer form extension panel. After choosing the request type from the list, we’ll be able to add new fields or select all or several existing fields at once. Name your field in a Display name. It’s a good practice to add Field help and explain what information it requires. If you would like to translate a dynamic field, all you have to do is click on add Translations and select the target language.
Conditions and Validators for custom fields management
In Dynamic Forms, we can set conditions for dynamic fields to tailor request forms to individual needs. Conditions are rules that define whether a field is displayed in a request form based on user input in previous fields of that form. You can set multiple conditions for a field and group them into condition blocks. In the Customer form extension panel, find Conditions in the Options column and select or type values in the boxes.
The Dynamic Forms feature of Extension lets you validate a field in more ways than just setting it as required. By setting a validator, you specify what information a customer needs to put in a dynamic field. If that information is not provided, the customer can’t submit their request. This ensures that your Support Team only receives requests with accurate information. In order to set it up accordingly, choose Validators in the Options column. In the dialog box window, select Rule name and type your validation rules. Remember that since any change in a request type is automatically saved and visible in the Customer Portal, we recommend keeping request forms hidden from the portal while modifying them.
Copying custom fields from other forms
It’s possible to copy a non-dynamic field into the dynamic fields section and dynamic fields across dynamic forms. We do it in the Project Settings section by clicking on Copy fields with the configuration button. Then, we choose whether we wish to copy fields from this request type or from another dynamic form. To avoid duplication, remember to remove the non-dynamic one from the fields defined in the Request Type section.
Now, when we already know how the functionalities work in both tools, let’s compare them in two crucial categories: usability for Support teams and the possibilities they give on a Customer Portal.
Comparison category 1: Usability for Support agents and teams
When it comes to the usability aspect from the Support teams’ perspective, Forms are objectively easier to manage. Forms can be edited from the agent’s view, and the teams are able to add forms to previously created issues. What’s more, issues can be downloaded as a .pdf or a .xlsx file to share with the stakeholders.
On the other hand, Dynamic Forms is actively supported and developed. The team responsible for Extension for Jira Service Management at Deviniti constantly updates the app to meet the expectations of the demanding market. Unfortunately, in the case of Atlassian, it’s not always this simple. It’s challenging to handle all customers’ tickets in such a large company. This is why possible fixes usually take a long time and it’s unlikely that any new features for Forms will be released anytime soon. Additionally, Dynamic Forms provides its users with more customization possibilities thanks to its validators and conditions settings. Last but not least, Extension not only includes Dynamic Forms but also Bundled Fields and Request Details View features. All three give many more functionalities than Forms, such as displaying additional elements on the Customer Portal and grouping related fields so that the form can be transparent and comprehensible.
Comparison category 2: Customer Portal view and client-oriented use cases
At the moment, Forms allows users to configure dynamic fields and sections and present them on Customer Request Type or separate forms to create issues. However, in Dynamic Forms, a user is able to refer to singular fields, rather than to the whole sections. It expands a form configuration view with much more complex use cases. We can set up default values in the fields and generate previews in both apps. Currently, Extension and Forms on Cloud do not refer to custom fields or Insight Asset fields (although Atlassian announces that they’re going to change it soon for Jira Cloud). In Dynamic Forms as well as in Forms, one configuration of fields can be used in multiple request types.
Forms integrate with Jira fields and users can map them with each other. When a form is set up on the Customer Portal, then Jira issue fields are automatically completed and store the data necessary for JQL or automation to work correctly. Nevertheless, you can only map one custom field to one field on a specific form. If you have different scenarios in your dynamic forms use case, you cannot refer to the same field as you can in Extension. Currently, Extension better visualizes data from the UI point of view because it doesn’t add a giant separate module to the issue view. It neatly integrates with Jira fields and fills them appropriately. In Dynamic Forms, we can translate field labels and descriptions thanks to the Translations feature – which isn’t possible in Forms. It may be a strong advantage for multilingual teams.
Summary: pick your winner!
Forms and Dynamic Forms in Extension for Jira Service Management have lots of features in common. From the perspective of Jira admins, Forms and Extension’s Dynamic Forms are equally simple to configure. Both applications provide support for company-managed as well as team-managed projects in Jira Service Management. The undeniable advantage of Forms for Cloud over Dynamic Forms is pricing as it will be included in the Jira license fee. The configuration and setup of both tools are similarly intuitive. Nevertheless, the upcoming Atlassian app may not be the answer to more demanding, complex projects that require more customization. Despite the fact that Forms has some really strong points, such as data export, and simplified forms edition, it’s smart to consider the bigger picture here. Deviniti’s app strengths lie in JQL flexibility, high-level support for customers, and constant development.
The choice isn’t easy because there is probably no one right app that will suit everybody. Take a look at our comparison table above and decide which solution will be the best for your business.
Was this helpful?
Thanks!
Katarzyna Kornaga _Deviniti_
4 comments