This document outlines fundamental guidelines for teams regarding the effective design, development, and maintenance of dynamic forms within Atlassian Jira Service Management (JSM). The primary objective is to utilize JSM's built-in functionalities to optimize information collection, improve data quality, and streamline support processes.

Well-designed dynamic forms greatly enhance the customer experience by tailoring questions to address individual needs. This method not only facilitates quicker resolutions and increases satisfaction but also provides support teams with high-quality data to utilize in their operations.

Introduction to Dynamic Forms in Atlassian JSM

Dynamic forms in JSM are interactive forms that adapt their content based on user input, predefined conditions, or linked Jira field values. This adaptability ensures that customers and agents only see relevant fields, reducing clutter, improving completion rates on the customer portal, and gathering more precise information for faster resolution.

Why Dynamic Forms in JSM?

Improved User Experience: Customers are guided through relevant fields, reducing frustration and abandonment on the portal.
Better Data Quality: Ensures the collection of critical and accurate data, minimizing the need for follow-up communications.
Increased Efficiency: Streamlines ticket creation, allows for automated routing, and powers better reporting directly within Jira workflows.
Scalability: Forms can be easily adapted as processes evolve, integrating seamlessly with Jira's underlying structure.

Core Concepts of Dynamic Form Design in JSM

Understanding these concepts is crucial if you're using JSM's native forms.

Each Request Type can have a unique form with a tailored set of fields and conditional logic.

Conditional Logic in JSM

This is the core of dynamic behavior. Conditional logic dictates when and how certain fields or sections appear or behave based on user input.

Achieved primarily by adding "sections" to your forms and configuring their visibility based on other fields. The conditions are typically simpler (IF [Field] IS [Value] THEN SHOW [Section/Field]). This works well for single-select, multi-select, and checkbox fields.

Common Conditions:

Field Value: Based on a selected option (dropdown, radio button), a checkbox being checked, or specific text input.
Field Presence: Whether a specific field has been filled out.

Common Actions:

Show/Hide Field/Section: Making a field or an entire section visible or invisible.
Make Field Required/Optional: Changing validation rules dynamically.
Change Field Options: Modifying the choices available in a dropdown based on another selection (usually handled by linking to Jira fields).

Fields and Data Types in JSM

Forms in JSM can use two types of fields:

Form-specific fields: These fields are created directly within the form builder and do not automatically become Jira custom fields. They are ideal for collecting supplementary information specific to the form's context.
Linked Jira fields: You can link form fields directly to existing Jira custom fields. This is crucial for ensuring data is stored in Jira, can be used in JQL queries, automation rules, and reporting.

Common Field Types in JSM Forms:

Text Fields (Short/Long Answer): For titles, summaries, descriptions, URLs, and emails.
Dropdown/Select List (Single/Multi-select): For predefined options in single or multiple selections.
Checkboxes/Radio Buttons: For multiple or single selections.
Date Picker/Date Time Picker: For capturing specific dates or times.
User Picker/Group Picker/Project Picker: To select Jira users, groups.
Others: For additional types, such as attachments, and specifically focusing on Asset fields.

Deep Dive into Specific Form Types in JSM

Let's explore the setup, essential data, and conditional logic for each of these use case form types.

Bug Form: Detailed Setup and Data Collection

The Bug form is critical for efficient issue resolution. Its primary goal is to gather all necessary information for developers to reproduce, diagnose, and fix the defect.

Essential Fields & Data to Gather:

Field	Type	Accuracy
Subject / Summary	Text Input (Required)	Concise, descriptive, and unique. Should clearly state the problem.
Severity	Dropdown (Required)	Standardized options with clear definitions (e.g., Critical = production down).
Impacted Area/Module	Dropdown (Required)	Options should map directly to your product's architecture or functional areas.
Steps to Reproduce	Text Area (Required)	Numbered, precise, and repeatable steps. Most critical information for resolving bugs.
Expected Behavior	Text Area (Required)	Clear statement of what should happen.
Actual Behavior	Text Area (Required)	Detailed description of what happened, including errors or unexpected results.
Environment Details	Text Area (Required)	Browser, OS, device type, URLs, and network details (e.g., VPN or corporate network).
Screenshots / Attachments	File Upload (Optional)	High-quality images/videos showing the bug.
Affected User ID/Email	Text Input (Optional)	Exact user identifier to help locate logs or session data.

Conditional Logic Examples for "Bug" Form:

Condition A: Critical/High Severity Impact Details
- IF Severity is one of Critical, High
- THEN
  - SHOW a section/field: Business Impact Description (Text Area, Required)
  - SHOW a field: Workaround (if any) (Text Area, Optional)
- Create a section called "High Impact Details." In its conditional logic, set Severity is one of Critical, High. Place the two fields inside this section.
Condition B: Specific Authentication Issues
- IF Impacted Area/Module is one of User Authentication
- THEN
  - SHOW a field: Is User Locked Out? (Radio Buttons: Yes/No, Required)
  - SHOW a field: Authentication Method Used (Dropdown: Password, SSO, OAuth, API Key, Required)
- Create a section "Authentication Specifics" with the condition Impacted Area/Module is one of User Authentication.

Question Form: Detailed Setup and Data Collection

The Question form is for general inquiries that don't fit into a bug or specific request. The goal is to route the question to the right team or knowledge base article quickly.

Recommended Request Type: "General Inquiry" or "Ask a Question"

Essential Fields & Data to Gather

Field	Type	Accuracy
Subject / Question Summary	Text Input (Required)	A clear, concise statement of the question.
Detailed Question	Text Area (Required)	Context, what the requester has tried, and any relevant background.
Topic Area	Dropdown (Required)	Tailor to your service areas (e.g., Billing, Technical Support). Essential for routing.
Urgency	Dropdown (Optional)	Helps agents prioritize. Standard values like Low, Medium, High.
Attachments	File Upload (Optional)	Any relevant screenshots, documents, or supporting materials.

Conditional Logic Examples for "Question" Form:

Condition A: Billing Questions
- IF Topic Area is one of Billing
- THEN
  - SHOW a field: Invoice Number (if applicable) (Text Input, Optional)
  - SHOW a field: Billing Period (Date Range Picker, Optional)
- Create a section "Billing Details" with the condition Topic Area is one of Billing.
Condition B: Technical Support Questions
- IF Topic Area is one of Technical Support
- THEN
  - SHOW a field: Product/Feature Name (Text Input, Optional)
  - SHOW a field: Error Message (if any) (Text Area, Optional)
  - SHOW a field: Troubleshooting Steps Taken (Text Area, Optional)
- Create a section "Technical Details" with the condition Topic Area is one of Technical Support.

Request Form: Detailed Setup and Data Collection

Request forms are for specific actions or changes. They often require precise details to fulfill the request efficiently and ensure compliance.

Recommended Request Type: Varies greatly (e.g., "New User Account," "Feature Request," "Data Export," "Access Change")

Essential Fields & Data to Gather (Example: "New User Account Request"):

Field	Type	Accuracy
Request Title / Summary	Text Input (Required)	Clear and specific (e.g., “New User Account for John Doe”).
Request Type	Dropdown (Required)	Primary driver for conditional logic. Options tailored to your service catalog.
Justification / Business Need	Text Area (Required)	Clearly explains the business context and why the request is necessary.
Requested By	User Picker (Required)	The person submitting the request.
Attachments	File Upload (Optional)	Supporting documentation (e.g., signed approvals, specifications).

Conditional Logic Examples for "Request" Form (using "New User Account Request"):

Condition A: New User Account Details
- IF Request Type is one of New User Account
- THEN
  - SHOW a field: New User's Full Name (Text Input, Required)
  - SHOW a field: New User's Email (Email Input, Required)
  - SHOW a field: Department (Dropdown, Required) - Options: Sales, Marketing, Engineering, CS, etc.
  - SHOW a field: Required Software/Tools (Checkboxes, Optional) - Options: MS Office, Slack, Zoom, etc.
  - SHOW a field: Start Date (Date Picker, Required)
- Create a section "New User Account Details" with the condition Request Type is one of New User Account.
Condition B: Feature Enhancement Details
- IF Request Type is one of Feature Enhancement
- THEN
  - SHOW a field: Proposed Feature Name (Text Input, Required)
  - SHOW a field: Problem This Solves (Text Area, Required) - Focus on the user problem, not just the solution.
  - SHOW a field: Expected Benefits (Text Area, Optional)
  - SHOW a field: Impacted User Roles (Multi-select Dropdown, Optional)
- Create a section "Feature Enhancement Details" with the condition Request Type is one of Feature Enhancement.

General Best Practices for Dynamic Forms in Atlassian

User Experience (UX) First in JSM

Logical Flow: Ensure the form flows naturally for customers on the JSM portal. Group related fields into logical sections.
Clear Instructions: Provide concise help text for complex fields. Use JSM's built-in descriptions and hints.
Minimizing Cognitive Load: Only show fields that are immediately relevant. Avoid overwhelming the user with a long, static form.
Progress Indicators: JSM forms often implicitly guide users through sections; for very long forms, a clear layout is key. Consider breaking very complex forms into multiple request types if logical.

Maintainability and Scalability

Standardized Naming Conventions: Use consistent naming for form fields and, crucially, for linked Jira custom fields. This aids reporting and automation.
Modular Design: Consider creating reusable form components or templates if your chosen tool allows.
Data Consistency: Ensure that dropdown options are consistent with other Jira fields and processes. Avoid redundant data collection.
Jira Field Mapping: Always aim to map critical form data to Jira fields to enable JQL, automation, and reporting.

Testing Strategy

Unit Testing: Test individual conditional rules directly in the form builder.
Integration Testing: Test how different conditions interact with each other, especially with cascading logic.
Regression Testing: Ensure new changes don't break existing form logic or Jira integrations.
User Acceptance Testing (UAT): Have your internal team and representative end users test the forms on the customer portal to ensure intuitiveness and comprehensive data capture. Gather feedback on clarity and ease of use.
Edge Cases: Test scenarios like selecting an option then changing it, leaving optional conditional fields blank, or entering invalid data.

Conclusion

Building dynamic forms in Atlassian Jira Service Management is a powerful way to enhance your team's efficiency and your customers' experience. By understanding the capabilities of JSM's native forms and strategically leveraging Marketplace apps for advanced needs, your team can design intelligent and effective data collection tools.

Building a Confluence Knowledge Base for Jira Service Management

Building a Confluence Knowledge Base for Jira Service Management