Skip to main content

Dynamic Required Fields

Dynamic required fields adapt validation to context. Instead of making fields always required or always optional, rules enforce validation only when relevant—based on priority, cost, status, or other criteria.

This keeps forms flexible while ensuring critical data is captured when it matters.

Why Dynamic Required Fields Matter​

Problem: Static required fields create friction. Fields required for all issues become obstacles when they're only relevant to some scenarios.

Solution: Make fields required conditionally. Users encounter validation only when the field is actually needed for their specific case.

Benefits:

  • Faster issue creation - users aren't blocked by irrelevant required fields
  • Better data quality - validation appears when context makes the requirement clear
  • Flexible workflows - same form adapts to different scenarios
  • Reduced frustration - users understand why fields are required when they see them

Basic Pattern: Require Field When Condition Met​

The simplest dynamic required rule enforces validation when a specific condition is true.

Example 1: Require Root Cause for Critical Bugs​

Requirement: Root Cause must be filled for Critical priority bugs

Rule Configuration:

  • Screen: Global Issue Create
  • Target Field: Root Cause
  • Scope: Bug
  • Condition: Priority = Critical
  • Action: Make field required

User Experience:

  • User creates Bug with Priority = Low → Root Cause optional
  • User changes Priority to Critical → Root Cause becomes required (asterisk appears)
  • User cannot submit form without filling Root Cause
  • Validation appears exactly when it's needed

Range-Based Required Fields​

Require fields for items in a high-impact range, ensuring oversight where it matters.

Example 2: Require Approval for High-Cost Features​

Requirement: Features estimated over 10,000 must have Budget Code and Finance Approval

Conditions don't compare numbers against a threshold, so the estimate is captured in Cost Band (select list) with the options "Under 10,000" and "Over 10,000".

Rule 1: Require Budget Code

  • Screen: Global Issue Create
  • Target Field: Budget Code
  • Scope: Feature
  • Condition: Cost Band = Over 10,000
  • Action: Make field required

Rule 2: Require Finance Approval

  • Screen: Global Issue Create
  • Target Field: Finance Approval
  • Scope: Feature
  • Condition: Cost Band = Over 10,000
  • Action: Make field required

User Experience:

  • User creates Feature and picks Cost Band = Under 10,000 → No additional fields required
  • User picks Cost Band = Over 10,000 → Budget Code and Finance Approval become required
  • Form cannot be submitted without these fields for high-cost features
  • Lightweight process for small features, proper governance for expensive ones

Each rule has one action, so these rules only change the required marker: both fields are on the form from the start. To keep them hidden until the band is picked, add a Hide field rule on each with the condition Cost Band not equals Over 10,000 (see Progressive Disclosure).

Status-Based Required Fields​

Require fields at specific workflow stages, ensuring completeness before progression.

Example 3: Require Test Results Before Release​

Requirement: Issues cannot transition to "Ready for Release" without Test Results

Rule Configuration:

  • Screen: Issue Transition
  • Target Field: Test Results (on the "Ready for Release" transition's screen only)
  • Scope: Bug, Story
  • Condition: none
  • Action: Make field required

A Transition rule runs in every transition dialog whose screen shows the field, so keeping Test Results on the "Ready for Release" transition's screen only limits the rule to that transition. Don't add "Issue status = Ready for Release" as a condition: on a transition, the Issue status condition checks the status the work item is leaving, not the one it moves to.

User Experience:

  • User transitions Bug from "In Testing" to "Ready for Release"
  • Transition dialog shows Test Results as required field
  • Cannot complete transition without filling Test Results
  • Workflow gate ensures quality standards before release

Role-Based Required Fields​

Require fields for specific user groups, applying different validation rules to different teams.

Example 4: Require Business Justification from Non-Managers​

Requirement: Non-manager users must provide Business Justification when creating high-priority features

Rule Configuration:

  • Screen: Global Issue Create
  • Target Field: Business Justification
  • Scope: Feature
  • Conditions (joined with AND):
    • Priority not equals Medium
    • Priority not equals Low
    • User NOT in group "Managers"
  • Action: Make field required

A rule joins all its conditions with one operator, AND or OR, so "High or Critical, and not a manager" can't be written as "Priority = High OR Priority = Critical" plus the group condition. Name the priorities to leave out instead: with AND, the two "not equals" conditions leave High and Critical. If your priority scheme has more levels, such as Lowest, add a "not equals" condition for each of them.

User Experience:

  • Manager creates high-priority Feature → Business Justification optional (managers are trusted)
  • Team member creates high-priority Feature → Business Justification required
  • Different validation for different roles without separate forms

Multi-Condition Required Fields​

Combine multiple conditions to enforce validation in very specific contexts.

Example 5: Require Release Notes for Customer-Facing Production Fixes​

Requirement: Production bugs that customers notice must have Release Notes

Rule Configuration:

  • Screen: Global Issue Create
  • Target Field: Release Notes
  • Scope: Bug
  • Conditions (joined with AND):
    • Environment (select list) = Production
    • Customer-facing (radio buttons) = Yes
  • Action: Make field required

User Experience:

  • User creates Bug with Environment = Staging → Release Notes optional
  • User sets Environment = Production and Customer-facing = Yes → Release Notes becomes required
  • Customer-facing production fixes are properly documented; other bugs aren't burdened with unnecessary fields

Practical Use Cases​

Software Development Team​

Require Acceptance Criteria for large Stories:

  • Scope: Story
  • Condition: Size (select list) is one of Large, Extra Large
  • Action: Require Acceptance Criteria field

Require Performance Impact for database changes:

  • Scope: Task
  • Condition: Area (select list) = Database
  • Action: Require Performance Impact field

Customer Support Team​

Require SLA Deadline for Premium customers:

  • Scope: Customer Request
  • Condition: Customer Tier (select list) is one of Premium, Enterprise
  • Action: Require SLA Deadline field

Require Escalation Contact for high-severity tickets:

  • Scope: Support Ticket
  • Condition: Severity (select list) = Critical
  • Action: Require Escalation Contact field

Project Management​

Require Risk Assessment for Epics:

  • Scope: Epic
  • Action: Require Risk Assessment field

Require Stakeholder Approval for scope changes:

  • Scope: Story, Task
  • Condition: Labels contains "scope-change"
  • Action: Require Stakeholder Approval field

Common Patterns​

Pattern 1: Priority-Based Required​

Require additional fields for high-priority issues.

Condition: Priority = High OR Priority = Critical
Action: Require "Business Impact"

Pattern 2: Range-Based Required​

Require fields for items in a high range. Number conditions match exact values only, so put the ranges into a select list (see Operators by Field Type).

Condition: Effort (select list) = More than 40 hours
Action: Require "Manager Approval"

Pattern 3: Workflow Gate Required​

Require fields before specific transitions. Keep the field on that transition's screen only; no status condition is needed.

Screen: Issue Transition
Field: on the "Ready for Deployment" transition's screen only
Condition: none
Action: Require "Deployment Checklist"

Pattern 4: Role-Specific Required​

Apply validation to specific user groups.

Condition: User NOT in group "Administrators"
Action: Require "Reason for Change"

Progressive Disclosure: Show fields conditionally before requiring them - users see fields when relevant, required when critical

Field Locking on Transitions: Lock fields during status changes - different from required (supported on Create, Issue View and Transition screens)

Status-Based Validation: Combine with workflow to enforce completeness at transition points

Next Steps​