Field Validation Examples
Field validation rules enforce data quality, consistency, and business rules at the point of data entry. Unlike workflow validators that trigger on transitions or required fields that are always mandatory, validation rules provide real-time feedback with custom error messages and conditional logic.
This guide shows six real-world validation scenarios you can adapt to your organization's needs.
Why Field Validation Matters
Problem: Traditional Jira validation is limited to "required field" checkboxes (always on/always off) or workflow validators (only on transitions). Neither approach provides real-time feedback, conditional validation, or custom error messages explaining what's wrong and why.
Solution: Field validation rules evaluate field values in real-time as users type, displaying actionable error messages when validation fails. Rules apply conditionally based on issue type, priority, status, or any other criteria.
Benefits:
Immediate feedback - Users see errors as they type, not after submission
Actionable guidance - Custom messages explain what's wrong and how to fix it
Conditional enforcement - Validation applies only when relevant to the context
No coding required - Configure complex validation through visual interface
Business rule automation - Enforce SLA deadlines, quality gates, and data consistency automatically
SLA Enforcement: Critical Ticket Deadlines
Automatically enforce SLA requirements by validating that Critical priority tickets have adequate lead time for triage and resolution.
Requirement
Business rule: Critical priority support tickets must have Due Date at least 2 hours from creation time to allow for proper triage, assignment, and initial investigation. Last-minute deadlines lead to hasty responses and quality issues.
Rule Configuration
Screen: Global Issue Create
Target Field: Due Date
Scope: Bug (or Service Request for JSM)
Condition: Priority = Critical
Validation: Date at least X days in future
Days: 0 (for day-level precision; explain 2-hour requirement in error message)
Error Message: "Critical tickets require Due Date at least 2 hours from now to allow time for proper triage and assignment. Please select a date/time at least 2 hours in the future."
[SCREENSHOT: SLA enforcement configuration - complete setup]
User Experience
Scenario 1: User creates Critical ticket
User selects Priority = Critical
User tries to set Due Date = today at 2:00 PM (current time is 1:30 PM)
Validation fails: Error message appears explaining 2-hour minimum requirement
User adjusts Due Date to 3:30 PM or later
Validation passes: Issue can be submitted
Scenario 2: User creates Low priority ticket
User selects Priority = Low
Validation rule doesn't apply (condition not met)
User can set any Due Date without SLA restriction
Flexible deadlines for routine work
Why It Works
Automated SLA compliance - No manual oversight needed; system enforces policy automatically
Clear expectations - Error message explains why the lead time is required
Context-aware - Only Critical tickets face restriction; routine tickets remain flexible
Prevents workarounds - Users can't bypass SLA by setting unrealistic deadlines
Business Impact
100% compliance with 2-hour SLA for Critical tickets
Reduced rushed responses and quality issues
Clear audit trail showing all Critical tickets had adequate lead time
Support team can plan workload knowing deadlines are realistic
Quality Gate: Story Points Validation
Enforce estimation discipline by requiring Story Points to be positive and reasonable, preventing unestimated or oversized Stories from entering sprints.
Requirement
Business rule: All Stories must have Story Points estimated before sprint planning, and estimates must be between 1-40 points. Zero-point Stories indicate missing estimation, and Stories exceeding 40 points should be split into smaller pieces.
Rule Configuration - Part 1: Minimum Validation
Screen: Global Issue Create
Target Field: Story Points
Scope: Story
Condition: (No additional conditions - applies to all Stories)
Validation: Number greater than
Threshold: 0
Error Message: "Story Points must be greater than 0. Please estimate this Story before saving. If this Story requires no effort, consider whether it should be a Story at all."
Rule Configuration - Part 2: Maximum Validation
Screen: Global Issue Create
Target Field: Story Points
Scope: Story
Condition: (No additional conditions - applies to all Stories)
Validation: Number less than
Threshold: 41
Error Message: "Story Points must be less than 41. Stories larger than 40 points should be split into smaller Stories. Please break this down into multiple Stories."
[SCREENSHOT: Story Points quality gate - error message in action]
Alternative approach: Use "Number between" validation (1-40) for single-rule simplicity. The two-rule approach shown here provides more specific error messages for each violation.
User Experience
Scenario 1: User forgets to estimate
User creates Story and leaves Story Points empty or sets to 0
Validation fails: "Story Points must be greater than 0"
User adds estimate (e.g., 5 points)
Validation passes: Issue can be saved
Scenario 2: User estimates too high
User creates Story and sets Story Points = 55
Validation fails: "Story Points must be less than 41. Stories larger than 40 points should be split..."
User realizes Story is too large and splits it into multiple smaller Stories
Each smaller Story has reasonable estimate (e.g., 20, 20, 15 points)
Scenario 3: User provides valid estimate
User creates Story and sets Story Points = 8
Both validations pass (8 > 0 AND 8 < 41)
Issue saves without errors
Why It Works
Prevents unestimated work - Zero-point Stories are caught before sprint planning
Encourages Story splitting - Large Stories are flagged automatically, prompting decomposition
Clear guidance - Error messages explain why the validation exists and what to do
Automated enforcement - No manual review needed; validation happens at creation time
Business Impact
All Stories entering sprint have valid estimates
Improved sprint planning accuracy due to properly sized Stories
Reduced mid-sprint discovery of oversized work
Team develops discipline around estimation and Story decomposition
Data Consistency: Date Sequencing Validation
Maintain data integrity by ensuring dependent dates follow logical order, preventing impossible date ranges that cause reporting errors.
Requirement
Business rule: For all Epics and Projects, End Date must be chronologically after Start Date. Impossible date ranges (end before start) create errors in roadmaps, Gantt charts, and timeline reports.
Rule Configuration
Screen: Global Issue Create
Target Field: End Date
Scope: Epic, Project (or any issue types with date ranges)
Condition: (No additional conditions - always validate)
Validation: Date after another field
Comparison Field: Start Date
Error Message: "End Date must be after Start Date. Please ensure your project timeline has End Date later than Start Date."
[SCREENSHOT: Cross-field validation setup - End Date > Start Date]
User Experience
Scenario 1: User sets invalid date range
User creates Epic with Start Date = March 15, 2026
User sets End Date = March 10, 2026 (earlier than start)
Validation fails: Error message appears explaining End Date must be after Start Date
User corrects End Date to March 30, 2026
Validation passes: Epic can be saved
Scenario 2: User sets valid date range
User creates Epic with Start Date = March 15, 2026
User sets End Date = April 30, 2026
Validation passes immediately (End Date > Start Date)
No error message appears
Scenario 3: Only Start Date filled
User fills Start Date but leaves End Date empty
Validation doesn't apply (cross-field validations require both fields to have values)
Epic can be saved with only Start Date (fail-safe behavior)
Important: Cross-field validations only apply when both fields have values. If you need both fields to be filled, add a separate "Must not be empty" validation for End Date.
Why It Works
Catches data entry errors - Impossible date ranges are flagged immediately
Prevents reporting issues - Gantt charts and roadmaps rely on valid date sequences
Clear error message - Users understand exactly what's wrong and how to fix it
Fail-safe design - Validation doesn't block users who haven't filled both dates yet
Business Impact
Zero invalid date ranges in production
Accurate timeline reporting and roadmap visualization
Reduced cleanup work from correcting impossible dates after creation
Improved data quality for portfolio planning and forecasting
Content Quality: Incident Summary Standards
Enforce minimum content standards for incident summaries, ensuring adequate detail for triage, reporting, and searchability.
Requirement
Business rule: Incident summaries must be at least 15 characters to provide meaningful descriptions for triage teams. Single-word summaries like "Bug" or "Error" lack sufficient context for proper prioritization and assignment.
Rule Configuration
Screen: Global Issue Create, JSM Portal
Target Field: Summary
Scope: Incident (or Bug for software teams)
Condition: (No additional conditions - applies to all Incidents)
Validation: Text minimum length
Length: 15
Error Message: "Incident summary must be at least 15 characters to ensure meaningful description. Please provide specific details about the incident (e.g., 'Login page returns 500 error on submit' instead of just 'Error')."
User Experience
Scenario 1: User enters vague summary
User creates Incident with Summary = "Bug"
Validation fails: Error message appears explaining 15-character minimum
User expands summary to "Login page error"
Validation passes (16 characters): Incident can be submitted
Scenario 2: User enters detailed summary
User creates Incident with Summary = "Customer unable to access billing history"
Validation passes immediately (42 characters)
No error message appears
Scenario 3: User tries whitespace workaround
User enters Summary = "Bug " (bug + spaces to reach 15 chars)
Validation still fails: Whitespace-only text is ignored
User must provide actual content
Why It Works
Forces meaningful descriptions - Users can't bypass with single words or whitespace
Improves triage efficiency - Support teams immediately understand the issue from summary
Better searchability - Detailed summaries improve search results and knowledge base
Balances quality and speed - 15 characters is low enough to not slow down reporting, high enough to ensure basic detail
Business Impact
All Incidents have meaningful summaries for triage
Reduced time spent on follow-up questions to clarify vague reports
Improved search and reporting accuracy
Better customer service through faster issue understanding
Budget Governance: Threshold Enforcement
Automatically enforce financial controls by requiring approval for high-cost features, combining validation with conditional required fields.
Requirement
Business rule: Features with estimated cost exceeding $10,000 require Finance Approval Code before development begins. This ensures expensive initiatives receive proper oversight while allowing low-cost features to proceed quickly.
Rule Configuration - Part 1: Budget Validation
Screen: Global Issue Create
Target Field: Estimated Budget
Scope: Feature
Condition: (No additional conditions - validate all Feature budgets)
Validation: Number greater than
Threshold: 0
Error Message: "Estimated Budget must be greater than 0 to ensure cost tracking. If budget is unknown, enter preliminary estimate and update later."
Rule Configuration - Part 2: Conditional Approval Requirement
Screen: Global Issue Create
Target Field: Finance Approval Code
Scope: Feature
Condition: Estimated Budget > 10000
Action: Make field required (NOT validation—use "Make Required" action)
Note: This is a traditional "Make Required" action, not a validation rule
Pattern: Combine validation rules (for data quality) with conditional required fields (for approval workflows). Validation ensures Budget is positive; conditional required ensures approval for high-cost items.
User Experience
Scenario 1: Low-cost feature
User creates Feature with Estimated Budget = $5,000
Budget validation passes (5000 > 0)
Finance Approval Code field remains optional (condition not met)
Feature can be saved without approval code
Scenario 2: High-cost feature requiring approval
User creates Feature with Estimated Budget = $15,000
Budget validation passes (15000 > 0)
Finance Approval Code becomes required (red asterisk appears)
User obtains approval code from Finance team and enters it
Feature can be saved with approval code
Scenario 3: User tries to bypass with zero budget
User creates Feature with Estimated Budget = 0 (trying to avoid validation)
Budget validation fails: "Estimated Budget must be greater than 0"
User must enter realistic budget estimate
If budget > $10k, approval code becomes required automatically
Why It Works
Automated governance - System enforces approval policy without manual oversight
Lightweight for small features - Low-cost features avoid approval bureaucracy
Prevents workarounds - Zero budget validation catches attempts to bypass approval
Clear escalation path - Error messages guide users to obtain approval when needed
Business Impact
100% compliance with $10k approval threshold
Reduced financial risk from unauthorized high-cost initiatives
Streamlined process for routine low-cost work
Clear audit trail of all high-cost feature approvals
Compliance: Separation of Duties
Enforce audit compliance by preventing users from assigning work to themselves when they reported the issue, maintaining separation of duties for critical work.
Requirement
Business rule: For audit compliance, the Assignee must not be the same person as the Reporter on Critical priority issues. This separation of duties ensures independent review and prevents conflicts of interest.
Note: "Assignee ≠ Reporter" validation is planned for Phase 3 of validation features. This example shows the intended configuration once cross-field equality validation is available.
Planned Rule Configuration
Screen: Global Issue Create, Issue Transition
Target Field: Assignee
Scope: Bug, Security Issue
Condition: Priority = Critical
Validation: Not equals field (planned feature)
Comparison Field: Reporter
Error Message: "Assignee cannot be the same as Reporter for Critical priority issues. Separation of duties is required for audit compliance. Please assign to a different team member."
Expected User Experience
Scenario 1: User tries to self-assign Critical issue
User creates Critical Bug (Reporter = current user)
User tries to set Assignee = themselves
Validation fails: Error message explains separation of duties requirement
User assigns to teammate
Validation passes: Issue can be saved
Scenario 2: User assigns to teammate
User creates Critical Bug (Reporter = current user)
User assigns to teammate (Assignee ≠ Reporter)
Validation passes immediately
No error message appears
Scenario 3: Low-priority self-assignment allowed
User creates Low priority Bug (Reporter = current user)
User sets Assignee = themselves
Validation doesn't apply (condition not met: Priority ≠ Critical)
Self-assignment is allowed for routine work
Why It Works
Automated compliance - Audit requirements enforced automatically, no manual review
Context-aware - Only Critical issues require separation; routine work remains flexible
Clear policy communication - Error message explains why the rule exists (audit compliance)
Prevents accidental violations - Catches self-assignment before issue is saved
Expected Business Impact
100% compliance with separation of duties audit requirements
Reduced audit findings related to conflict of interest
Clear documentation of independent review for Critical issues
Maintained flexibility for routine low-priority work
Validation Patterns by Industry
Different industries have common validation needs. These patterns show how to adapt validation rules to your domain.
IT Operations
Common validations:
Incident summary minimum 15 characters
Root Cause required for high-priority incidents
Resolution Date must be after Incident Date
On-Call Contact required for Critical priority
Example rule set:
Text validation: Incident summary ≥15 chars
Presence validation: Root Cause not empty (Priority = Critical)
Date validation: Resolution Date > Incident Date
Presence validation: On-Call Contact not empty (Priority = Critical)
Software Development
Common validations:
Story Points > 0 for all Stories
Story Points < 41 (enforce Story splitting)
End Date > Start Date for Epics
Release Notes minimum 20 characters for Features
Example rule set:
Number validation: Story Points > 0 (Issue Type = Story)
Number validation: Story Points < 41 (Issue Type = Story)
Date validation: End Date > Start Date (Issue Type = Epic)
Text validation: Release Notes ≥20 chars (Issue Type = Feature)
Customer Success
Common validations:
Customer feedback minimum 20 characters
Response Date within 24 hours of Request Date
Customer Satisfaction rating between 1-5
Escalation Contact required for dissatisfied customers
Example rule set:
Text validation: Feedback ≥20 chars
Date validation: Response Date ≤ Request Date + 1 day
Number validation: Customer Satisfaction between 1-5
Presence validation: Escalation Contact not empty (Satisfaction ≤2)
Financial Services
Common validations:
Transaction Amount > 0
Approval Code required for amounts > $5,000
Settlement Date ≥ Trade Date
Audit Notes required for exceptions
Example rule set:
Number validation: Transaction Amount > 0
Presence validation: Approval Code not empty (Amount > 5000)
Date validation: Settlement Date ≥ Trade Date
Text validation: Audit Notes ≥30 chars (Type = Exception)
Combining Validations with Other Rules
Validation rules work best when combined with other Dynamic Screen Rules actions for complete form control.
Pattern 1: Show + Validate + Require
Use case: Progressive disclosure with quality enforcement
Configuration:
Rule 1: Show "Root Cause" when Priority = Critical
Rule 2: Make "Root Cause" required when Priority = Critical
Rule 3: Validate "Root Cause" minimum 30 characters when Priority = Critical
Result: Field appears only when relevant, is required, and must meet quality standards.
Pattern 2: Validate + Set Value
Use case: Validation with smart defaults
Configuration:
Rule 1: Validate Story Points > 0 for Stories
Rule 2: Set Story Points = 3 (default) when Issue Type = Story
Result: Default value pre-fills, user can change, validation ensures positive value.
Pattern 3: Validate + Conditional Required
Use case: Threshold-based approval workflows
Configuration:
Rule 1: Validate Budget > 0 for Features
Rule 2: Make "Approval Code" required when Budget > 10000
Rule 3: Validate Approval Code minimum 8 characters
Result: Budget must be positive, high-cost features require valid approval code.
Pattern 4: Multi-Field Consistency
Use case: Related field validation
Configuration:
Rule 1: Validate End Date > Start Date
Rule 2: Validate Review Date > Start Date AND < End Date
Rule 3: Make all three dates required for Epics
Result: Complete timeline validation with logical sequencing.
Tips for Effective Validation Rules
Writing Clear Error Messages
Good error messages:
"Due Date must be at least 2 hours from now to allow time for triage and assignment."
"Story Points must be greater than 0. Please estimate this Story before saving."
"End Date must be after Start Date to create a valid timeline."
Bad error messages:
"Invalid value" (not specific)
"Validation failed" (no guidance)
"Error" (useless)
Best practices:
State what's wrong clearly
Explain why the validation exists (business reason)
Provide actionable guidance (what should the user do)
Keep it concise (1-2 sentences)
Choosing Validation vs. Required Fields
Use Validation Rules when:
You need threshold checks (dates, numbers, text length)
You want custom error messages
You need cross-field consistency
You want real-time feedback
Use Required Fields when:
Simple "must have value" is sufficient
Field is always required (no conditions)
Native Jira required field behavior is acceptable
Testing Validation Rules
Before deploying:
Test happy path (valid values pass)
Test each failure condition (appropriate error message appears)
Test edge cases (zero, empty, whitespace, today's date, equal values)
Test conditional logic (validation applies only when conditions met)
Test cross-field scenarios (both fields filled, one empty, both empty)
Common issues to test:
Whitespace-only text (should fail text validations)
Zero values for numbers (passes "not empty", fails "greater than 0")
Today's date (fails "after today", passes "after today + 0 days")
Equal dates (fail "after field", pass "after or equal to field")
Next Steps
Defining Field Validations - Complete reference for all 15 validation types
Supported Field Types - Check which fields support which validations
Creating Your First Rule - Step-by-step guide to creating validation rules
Last updated