How do you decide between Jira Forms and custom fields for team requests?

Sam Miller

At Silver Edge Packaging, different teams can have different information they need when submitting a request. For example, a website request may need page details and priority, while a design or packaging request may need dimensions, artwork information, or other project details.

I’m trying to understand when it makes more sense to create a Jira custom field and when a Form is the better option.

For teams managing different types of requests, how do you normally decide?

• Which information should become a permanent Jira field?
• When is it better to keep information inside a Form?
• How do you avoid creating too many custom fields?
• Can Form responses be mapped to Jira fields for automation?
• How do you handle different forms for different departments while keeping reporting consistent?

I’d be interested in hearing how other teams have designed this without ending up with a large number of unnecessary custom fields.

Anwesha Pan

Hi @Sam Miller 👋🏻

First of all, welcome to community! ✨

A good rule of thumb is: Jira Custom Fields are for the engine (filtering, searching, automation, reporting), while Forms are for the payload (context, details, checklists, specifications).

Here is a practical framework to help you decide.

1. Which Information Should Become a Permanent Jira Field?

Create a Jira custom field only when the data needs to be acted upon by Jira's core platform tools.

Ask yourself these four questions. If you answer YES to any of them, create a custom field:

• Search & JQL: Do agents or managers need to query or filter issues by this value? (e.g., Priority = High, Request Category = Packaging)
• Queues & SLA Routing: Does this field determine queue assignment, routing rules, or SLA triggers? (e.g., Department, Due Date, Environment)
• High-Level Reporting & Dashboards: Does leadership need cross-project pie charts, two-dimensional filter statistics, or gadget reports on this metric?
• Global Automations: Does a Jira Automation rule need to branch or compare this exact condition across multiple request types?

Typical Candidates for Custom Fields:

• T-shirt size / Complexity
• Primary Due Date / Target Launch Date
• Request Type / Category
• Client Name / Account (if centralized)
• Asset Status / Approver

2. When is it Better to Keep Information Inside a Form?

Keep information inside a Jira Form (formerly ProForma) when it serves as contextual detail for the assignee rather than a queryable index for the entire system.

Use Forms when the data:

• Is specific to one department/request type: E.g., Box dimensions (L x W x H), Pantone color codes, Paper stock finish, or Target URL/Browser version. The website team will never care about box dimensions, and the packaging team doesn't care about browser versions.
• Is a checklist, long questionnaire, or intake brief: Questions like "What is the primary target audience?" or "Have brand guidelines been reviewed? (Yes/No)".
• Requires conditional / cascading logic: Showing question #5 only if the user selects "Yes" to question #4. Forms handle this natively without complex custom field configurations.
• Involves tables or repeating rows: Forms allow table inputs (e.g., listing 5 different SKU variations in a single form), which Jira custom fields cannot do cleanly.

3. How to Avoid Creating Too Many Custom Fields

Custom field bloat degrades Jira performance, clutters the admin console, and confuses users. Use these governance practices:

1. Standardize and Re-use Generic Custom Fields:
   • Instead of creating Packaging Due Date, Design Due Date, and Web Launch Date, use standard Jira Due date (or one generic Target Delivery Date).
   • Instead of Packaging Priority and Web Urgency, use native Priority.
2. Use the "Field Request Test": Require teams to demonstrate how they will filter or automate based on a requested field before an admin creates it. If they only need to read it during task execution, put it in a Form.
3. Limit Field Scope: If a custom field must be created, restrict its context to the specific project/issue type rather than setting it to "Global".

4. Can Form Responses be Mapped to Jira Fields for Automation?

Yes, seamlessly.

Jira Forms support Field Mapping / Linked Fields:

• Direct Field Mapping: In the Form Builder, you can link a form question directly to a Jira field (e.g., linking a form question "When do you need this live?" to the standard Jira Due date field). When the user submits the form, Jira automatically populates the underlying issue field.
• Jira Automation Integration:
  • If the form field is linked to a Jira field, standard Jira automation triggers and conditions work out of the box.
  • For unlinked form answers, Jira Automation provides smart values (e.g., {{issue.forms}} or webhook triggers on Form submission) to read form content or automatically attach specific forms based on ticket criteria.

5. How to Handle Different Forms While Keeping Reporting Consistent

To balance specialized intake for different departments with unified management reporting, use a Hub-and-Spoke / Universal Meta-Field Model:

Universal JIRA Custom Fields (The Hub) [ Department ] [ Priority ] [ Due Date ] [ Status ] | +----------------------+----------------------+ | | | Website Team Design Team Packaging Team (Specific Form) (Specific Form) (Specific Form) - Page URL - Color Palette - Box Dimensions - Browser Type - Resolution / DPI - Material / Finish - Copy / Content - Aspect Ratio - Flute Type / Die-line

The Strategy:

1. Define 4–6 Universal Fields across all teams:
   • Department / Request Type (e.g., Web, Design, Packaging)
   • Target Delivery Date
   • Priority / Impact
   • Requestor / Approver
2. Build Dedicated Request Types & Forms for Each Department:
   • Create separate portal request types in Jira Service Management: Packaging Intake, Design Asset Request, Website Update.
   • Attach a unique, tailored Form to each request type.
3. Report on the Universal Layer:
   • Management dashboards pull reports grouped by Department, Priority, and SLA Resolution Time.
   • Individual assignees open the ticket and get the rich, department-specific form payload right in the issue view.

I was able to get this comparison summary between Jira Custom Field and Jira Form Field for your points:

Quick Comparison Summary

Criteria	Jira Custom Field	Jira Form Field
Primary Purpose	Indexing, querying, filtering, global reporting	Detailed data collection, briefs, checklists
Searchable via JQL	✅ Yes ("Field" = "Value")	❌ No (Searchable by text search only)
Queues & SLAs	✅ Direct integration	⚠️ Requires mapping to a Jira field
Conditional Logic	❌ Complex / Limited	✅ Native, easy drag-and-drop
Performance Impact	⚠️ High if hundreds are created	✅ Negligible (stored as form payload)
Table / Grid Support	❌ Requires 3rd-party apps	✅ Native Form tables

I hope this answers your question. 🙂

Thanks,
Anwesha