Dynamic Forms in JSM: A Guide to Better Support

Dynamic forms have revolutionized how teams collect information in Atlassian Jira Service Management (JSM). Rather than static questionnaires, these forms adapt to each user's input, showing only the questions that matter. The result is a smoother experience for customers and richer, more relevant data for support agents. In this guide, we dive into what dynamic forms are, why they matter for your team, and how to design them effectively in JSM.

Why Use Dynamic Forms for Your Team?

• Improved User Experience: Dynamic forms guide customers through only relevant questions, which reduces confusion and frustration. By eliminating irrelevant fields, users are less likely to abandon the form on the support portal.

• Better Data Quality: By tailoring questions to the issue at hand, you ensure that critical information is captured accurately. This minimizes back-and-forth communications to gather missing details.

• Increased Efficiency: When requests arrive with the right details, support teams can route tickets automatically and resolve issues faster. It also enables better reporting and analytics directly within Jira workflows.

• Scalability: As your processes evolve, forms can be easily updated or expanded with new fields and logic. They integrate seamlessly with Jira’s structure, so changes in form design won't disrupt your underlying data.

What Are Dynamic Forms in JSM?

Dynamic forms in Jira Service Management are interactive support request forms that adjust their content in real time based on the user's inputs. Each request type in JSM can have its own form with a tailored set of fields and conditional logic. This means the form a customer sees for reporting a bug will differ from the form for a general question or an access request. Each is customized to gather the most relevant information.

At the heart of dynamic forms is conditional logic. This logic controls when certain fields or entire sections of the form appear. For example, if a user selects a category like "Billing Issue," the form can immediately display additional billing-related fields that would remain hidden for other categories. By using conditions, JSM forms ensure customers and agents only deal with fields that apply to their situation. This reduces clutter on the portal and leads to more complete and precise information for faster resolutions.

Key Concepts for Designing Effective Forms

Designing a dynamic form involves more than just adding fields. Keep these core concepts in mind:

• Unique Forms per Request Type: In JSM, each service request type can have its own dedicated form. Tailor the fields on each form to suit that request’s needs. This specialization keeps forms concise and relevant.

• Form Fields vs. Jira Fields: Jira Service Management’s form builder allows you to create form-specific fields that exist only on that form, as well as to link fields to Jira custom fields. Linked Jira fields store data in the Jira issue itself, making it available for JQL queries, automation rules, and reporting. Use linked fields for information that agents will use frequently or need to report on, and use form-specific fields for supplemental details that don't need to live on the issue permanently.

• Plan Your Conditional Logic: Think through how you can use conditions to simplify the user’s experience. Identify which questions only apply in certain cases, and set up your form to show those questions at the right time. Good conditional logic prevents users from seeing long static forms with sections that might not apply to them. By carefully planning the structure of the form, you set the stage for a form that is both user-friendly and powerful.

Using Conditional Logic to Tailor Forms

Conditional logic is what makes a form "dynamic." It works by monitoring user inputs and responding accordingly. Here’s how you can use it in Jira Service Management forms:

• Triggering Conditions: Define conditions based on user input. For example, you can trigger a condition when a user selects a specific value from a dropdown  or checks a box. Conditions can also be based on whether a field is filled in or left blank. These triggers let the form "decide" which path to take next.

• Dynamic Actions: Once a condition is met, the form can perform actions such as showing or hiding particular fields or entire sections. You can also make certain fields required only in specific scenarios. For instance, a "URL" field might be optional normally, but if the user indicates they're facing an error on a webpage, you could make the URL field appear and require it. In some cases, conditional logic can even adjust field options. For example, filtering the choices in one dropdown based on the selection in another.

• Section Logic: Jira Service Management forms allow grouping fields into sections that can be shown or hidden together. Use sections to organize follow-up questions. For example, you might have a hidden section called "Advanced Details" that becomes visible only if the user checks "Include advanced details?" or if they select an option like "Problem Severity: High."

By leveraging these conditional logic tools, your form behaves almost like a conversation, asking the right follow-up questions at the right time. This guided approach ensures the customer provides all necessary information without feeling overwhelmed.

Field Types and Data in JSM Forms

Jira Service Management’s form builder supports a variety of field types and data connections:

• Form-Specific vs. Linked Fields: When adding fields to a form, decide if each should be a one-off form field or linked to a Jira custom field. Form-specific fields are stored within the form itself, whereas linked fields send the data directly into the Jira issue. Whenever you need to search, report on, or trigger automations from a piece of data, make it a linked field.

• Common Field Types: JSM forms offer all the standard input types you might need for support:

  • Text Fields: Single-line text for short answers (names, titles) and multi-line text areas for longer descriptions.

  • Dropdown Selects: Single-select or multi-select lists for predefined options (e.g., severity levels, categories).

  • Checkboxes and Radio Buttons: For yes/no choices or multiple-choice options presented directly on the form.

  • Date/Date-Time Pickers: For selecting dates or timestamps (for example, a requested due date or the date an issue occurred).

  • User/Group Pickers: To let customers specify a person or team (links to Jira users or groups, useful for fields like "Requested For" or "Approver").

  • Attachments: File upload fields for screenshots, logs, or other relevant files.

  • Asset Fields: If you use Jira’s Assets module (formerly Insight) or other inventory management, forms can include asset pickers to let users select a specific item (like a device or software asset related to the request).

Choose field types that make it easiest for the user to provide the info. For example, use a dropdown or checkboxes when you want to restrict answers to a set of valid options, rather than asking for free-text input.

Example: Dynamic Bug Report Form

One common use of dynamic forms is for bug reporting. When a customer reports a software bug, a well-designed form ensures the development team gets all the details needed to diagnose and fix the issue without back-and-forth clarification. Here's how you might structure a bug report form in JSM:

• Subject/Summary (Text, required): A concise title for the bug. This should briefly and clearly state the problem in one line.

• Severity (Dropdown, required): A selection for how critical the issue is (for example, Low, Medium, High, Critical). Each level should be clearly defined (e.g., "Critical" might mean a production system is down).

• Impacted Area/Module (Dropdown, required): Which part of the product or which feature is affected. The options here should map to your application's modules or functional areas, so the ticket can be routed to the right team.

• Steps to Reproduce (Multi-line text, required): A detailed, step-by-step description of how to reproduce the bug. Ideally, this is a numbered list of actions that consistently triggers the issue.

• Expected Behavior (Multi-line text, required): A description of what should happen if the software were working correctly in this scenario.

• Actual Behavior (Multi-line text, required): A description of what actually happens when the bug occurs. Include any error messages or incorrect results observed.

• Environment Details (Multi-line text, required): Important technical context such as the browser or operating system used, device type, app version, or network environment (for example, on a corporate VPN).

• Attachments (File upload, optional): Screenshots or videos demonstrating the bug, log files, or other supporting evidence. Visual proof can greatly speed up troubleshooting.

• Affected User ID or Email (Text, optional): If the bug is affecting a specific end user, it can help to have their identifier or contact info (to check logs or session data related to that user).

In addition to these fields, use conditional sections for special cases. For example, if the reporter selects "High" or "Critical" in the Severity field, the form can automatically reveal a section called "High Impact Details". In that section, you might include a Business Impact question (a required text area for the user to describe how this bug is affecting their business or customers) and a Workaround field (optional text area to note if they have found any temporary fix). These extra questions only appear for high-severity issues, ensuring that critical tickets have additional context.

Another conditional example: if the Impacted Area is "User Authentication," the form could show a dedicated section asking whether the user is locked out (a Yes/No radio button) and which authentication method was being used (a dropdown with options like Password, SSO, API Key, etc.). This way, issues related to login or identity capture specific details that are irrelevant for other types of bugs.

By tailoring the bug report form with these dynamic elements, you gather all the necessary data upfront for urgent issues and specialized scenarios, saving your developers and support engineers valuable time.

Example: General Inquiry Form

Not every customer issue is a bug or a service request. Sometimes a customer just has a question or needs guidance. For these general inquiries, you can set up a dynamic "Ask a Question" form that routes the query to the right team or resources.

In a General Inquiry form, you would typically start with a Summary of the Question (a required short text field) and a Detailed Question Description (a required paragraph field where the customer can explain their situation and what they've tried already). The key dynamic element here is a Topic Area dropdown. This field might include categories like "Billing", "Technical Support", "Account Management", etc., which represent the broad area of the question.

When the customer picks a topic from the dropdown, the form can show additional fields relevant to that topic. For example, if the user chooses "Billing", the form might display optional fields for an "Invoice Number" and a "Billing Period" date range (details that would help the finance or billing support team). These fields stay hidden unless "Billing" is selected, keeping the form shorter for everyone else. On the other hand, if the customer selects "Technical Support", the form could reveal fields to capture the "Product/Feature Name" they're asking about, any "Error Message" they've seen, and "Troubleshooting Steps Taken" so far. This way, the support team receives technical context upfront for a smoother resolution.

You might also include an Urgency dropdown as an optional field so the customer can indicate how time-sensitive their question is. And, as always, an Attachments field allows screenshots or documents to be included (for instance, the customer could attach a screenshot of an error or a billing statement).

With this dynamic inquiry form, even open-ended questions are handled efficiently. The question reaches the right people with all the necessary background, which improves the chances of a quick and accurate answer.

Example: Service Request Form

Service requests involve asking for a specific action or change: for instance, onboarding a new employee with accounts and equipment, requesting a new software feature, or changing a user’s access rights. These requests often require precise details for fulfillment and approvals. A dynamic form can simplify a wide variety of request types by showing only the fields relevant to the selected request.

Imagine a single Service Request form that starts by asking the user to choose a Request Type from a dropdown. Once the user picks the type of request, the form adapts to gather the information needed for that particular scenario.

For instance, if "New User Account" is selected as the request type, the form can display a section for new account details: fields for the new user's full name, email address, department, any required software or tools, and the person's start date. These fields ensure that when a new hire is being onboarded, IT and HR get all the info they need to create accounts and provision access in one go.

Alternatively, if "Feature Enhancement" is chosen, the form would dynamically present a different set of fields. It might prompt for a proposed feature name and a detailed description of the problem the feature would solve. The form can also ask for the expected benefits of the feature. Additionally, you might include a multi-select field to specify which user roles would be impacted by this change. These details help the product or development team evaluate the request and understand its importance.

Each option in the Request Type dropdown can trigger a tailored section like these examples. The dynamic form approach means one form can serve many different needs without overwhelming the user with every possible field. They only see what's relevant to their specific request.

Just as with the other forms, remember to link critical fields to Jira custom fields when needed. Also provide clear instructions for any fields that might be unclear, such as explaining exactly what to include in a "Justification" text box or when an "Approval Document" attachment is required.

Best Practices for Dynamic Forms

Designing and maintaining dynamic forms requires some planning. Here are a few best practices to ensure your forms stay effective and user-friendly:

• Put User Experience First: Build your forms with the end-customer in mind. Arrange questions in a logical order and group related fields into sections so the form feels organized. Provide brief help text or examples for fields that might need extra clarification (Jira allows adding descriptions to form fields). Avoid overwhelming users: thanks to conditional logic, you should only show a field when it's relevant. If a form grows too long or covers very different scenarios, consider splitting it into multiple request types for simplicity.

• Maintain Consistency and Clean Data: Use consistent naming for fields and options across all your forms. For example, if multiple forms ask for a "Department", use the same dropdown choices everywhere to avoid confusion and make reporting easier. Mapping important form data to Jira fields is also key: data like Severity or Urgency should be in Jira so you can leverage JQL filters, automation rules, and reports. Consistency also means avoiding duplicate questions. If the information is already captured by Jira (like the reporter’s name or a timestamp), you might not need to ask for it on the form.

• Test and Refine Regularly: Before rolling out a form to customers, test it thoroughly. Test individual conditional rules (unit testing) to ensure the right fields appear when they should. Test how different conditions interact with each other (integration testing). For example, if a user changes an earlier answer, check that the form correctly hides or reveals fields accordingly. Also do regression testing whenever you update a form, to make sure new changes don’t break existing logic or linked fields. Whenever possible, conduct User Acceptance Testing (UAT) by letting a few team members or internal users try the form in a staging environment. Their feedback can highlight confusing steps or missing options. Lastly, think of edge cases: what if a user fills something out and then changes their mind? What if they leave an optional conditional section blank, or enter invalid data? The form should handle these gracefully (for instance, hiding a section should also clear its fields or not require them once hidden).

By following these best practices, your team’s dynamic forms will remain reliable, clear, and aligned with your support processes as they evolve.

Wrapping Up

Dynamic forms in Jira Service Management empowers and support teams to gather precise, relevant information from customers without hassle. By intelligently adapting to each user's needs, these forms lead to quicker resolutions and a better overall support experience. With a thoughtful design approach (leveraging JSM’s native form capabilities and adding marketplace apps for advanced needs when necessary), your  team can create an efficient, scalable system for handling requests.