Skip to main content

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]

info

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)
warning

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
info

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.

warning

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:

  1. Text validation: Incident summary ≥15 chars
  2. Presence validation: Root Cause not empty (Priority = Critical)
  3. Date validation: Resolution Date > Incident Date
  4. 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:

  1. Number validation: Story Points > 0 (Issue Type = Story)
  2. Number validation: Story Points < 41 (Issue Type = Story)
  3. Date validation: End Date > Start Date (Issue Type = Epic)
  4. 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:

  1. Text validation: Feedback ≥20 chars
  2. Date validation: Response Date ≤ Request Date + 1 day
  3. Number validation: Customer Satisfaction between 1-5
  4. 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:

  1. Number validation: Transaction Amount > 0
  2. Presence validation: Approval Code not empty (Amount > 5000)
  3. Date validation: Settlement Date ≥ Trade Date
  4. 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:

  1. State what's wrong clearly
  2. Explain why the validation exists (business reason)
  3. Provide actionable guidance (what should the user do)
  4. 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:

  1. Test happy path (valid values pass)
  2. Test each failure condition (appropriate error message appears)
  3. Test edge cases (zero, empty, whitespace, today's date, equal values)
  4. Test conditional logic (validation applies only when conditions met)
  5. 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​