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

Threshold-Based Required Fields​

Require fields when values exceed thresholds, ensuring oversight for high-impact items.

Example 2: Require Approval for High-Cost Features​

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

Rule 1: Show and Require Budget Code

  • Screen: Global Issue Create
  • Target Field: Budget Code
  • Scope: Feature
  • Condition: Estimated Cost > 10000
  • Action: Make field required

Rule 2: Show and Require Finance Approval

  • Screen: Global Issue Create
  • Target Field: Finance Approval
  • Scope: Feature
  • Condition: Estimated Cost > 10000
  • Action: Make field required

User Experience:

  • User creates Feature and enters Estimated Cost = $5,000 → No additional fields required
  • User enters Estimated Cost = $15,000 → Budget Code and Finance Approval appear and are required
  • Form cannot be submitted without these fields when cost exceeds threshold
  • Lightweight process for small features, proper governance for expensive ones

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
  • Scope: Bug, Story
  • Condition: Status = Ready for Release
  • Action: Make field required

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:
    • Priority = High OR Priority = Critical
    • User NOT in group "Managers"
  • Action: Make field required

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 Production Fixes​

Requirement: Bugs fixed in production releases must have Release Notes

Rule Configuration:

  • Screen: Global Issue Create
  • Target Field: Release Notes
  • Scope: Bug
  • Conditions:
    • Fix Versions is not empty
    • Component contains "Production"
  • Action: Make field required

User Experience:

  • User creates Bug without Fix Version → Release Notes optional
  • User sets Fix Version and Component = "Production" → Release Notes becomes required
  • Production releases are properly documented; non-production bugs aren't burdened with unnecessary fields

Practical Use Cases​

Software Development Team​

Require Acceptance Criteria for large Stories:

  • Scope: Story
  • Condition: Story Points > 5
  • Action: Require Acceptance Criteria field

Require Performance Impact for database changes:

  • Scope: Task
  • Condition: Component = Database
  • Action: Require Performance Impact field

Customer Support Team​

Require SLA Deadline for Premium customers:

  • Scope: Customer Request
  • Condition: Customer Tier = Premium OR Customer Tier = Enterprise
  • Action: Require SLA Deadline field

Require Escalation Contact for high-severity tickets:

  • Scope: Support Ticket
  • Condition: Severity = 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: Label 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: Threshold-Based Required​

Require fields when values exceed limits.

Condition: Estimated Hours > 40
Action: Require "Manager Approval"

Pattern 3: Workflow Gate Required​

Require fields before specific transitions.

Screen: Issue Transition
Condition: Status = Ready for Deployment
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 and Transition screens only)

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

Next Steps​