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 five real-world validation scenarios you can adapt to your organization's needs.

warning

Add the Validation Gate field first. Validation rules block Create and Transition only through the app's Validation Gate field. Put it on the Create and Transition screens where the rules run, or the rules on this page can't stop a submission. See The Validation Gate Field.

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 as soon as a field changes (Summary and Description when the user leaves the field), displaying actionable error messages when validation fails. Rules apply conditionally based on issue type, priority and other field values, the issue's status on a transition, or the user's group, role or permissions.

Benefits:

  • Immediate feedback - Users see errors as soon as they change a field, 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 tickets must have a Due Date of tomorrow or later to allow for proper triage, assignment, and initial investigation. Same-day deadlines lead to hasty responses and quality issues.

Rule Configuration​

  • Screen: Global Issue Create
  • Target Field: Due Date
  • Scope: Bug
  • Condition: Priority = Critical
  • Validation: Date at least X days from today
  • Days: 1
  • Error Message: "Critical tickets need a Due Date of tomorrow or later to allow time for proper triage and assignment."

The validation compares dates only: Due Date has no time of day, so a lead time in hours can't be checked. With 0 days, today passes. Like the other date validations, it lets an empty Due Date through; make Due Date required as well if every Critical ticket must have one.

Screenshot — SLA enforcement rule

The Validation tab of Due Date with the rule card: Date at least 1 day from today, scoped to Bug, with the condition Priority equals Critical.

User Experience​

Scenario 1: User creates Critical ticket

  • User selects Priority = Critical
  • User sets Due Date = today
  • Validation fails: Error message appears explaining the one-day minimum
  • User changes Due Date to tomorrow
  • 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
  • Catches same-day deadlines - A Critical ticket can't be created with a Due Date of today or earlier

Business Impact​

  • Every Critical ticket created with a Due Date has at least a day of lead time
  • Reduced rushed responses and quality issues
  • 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."

Rule Configuration - Part 3: Estimate Present​

  • Screen: Global Issue Create
  • Target Field: Story Points
  • Scope: Story
  • Condition: (No additional conditions - applies to all Stories)
  • Validation: Must not be empty
  • Error Message: "Please estimate this Story before saving."

The number validations let an empty field through, so Part 1 alone doesn't catch a missing estimate. Part 3 (or a Make field required rule) does.

Screenshot — Story Points quality gate

The Create dialog for a Story with Story Points set to 0 and the error message "Story Points must be greater than 0" shown by the validation.

info

Alternative approach: Use "Number between" validation (1-40) instead of Parts 1 and 2 for single-rule simplicity. The two-rule approach shown here provides more specific error messages for each violation. Keep Part 3 either way.

User Experience​

Scenario 1: User forgets to estimate

  • User creates Story and leaves Story Points empty → Validation fails: "Please estimate this Story before saving."
  • User sets Story Points 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
  • All validations pass (not empty, 8 > 0 AND 8 < 41)
  • Issue saves without errors

Why It Works​

  • Prevents unestimated work - Empty and 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 — Date sequencing rule

The Validation Rule form for End Date with Date after another field selected and Start Date as the field to compare with.

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 (in a Jira Software or Work Management project; Formify rules don't run in Jira Service Management projects)
  • Target Field: Summary
  • Scope: Incident (a work type in your software or business project), or Bug
  • Condition: (No additional conditions - applies to all Incidents)
  • Validation: Minimum text 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 as soon as the user leaves the Summary field (42 characters)
  • No error message appears

Spaces count toward the minimum length. Only "Must not be empty" treats text made only of spaces as empty.

Why It Works​

  • Forces meaningful descriptions - Users can't get by with a single word
  • 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: Cost Band equals "Over $10,000" (Cost Band is a required select list with the options "Up to $10,000" and "Over $10,000")
  • Action: Make field required (NOT validation—use "Make Required" action)
  • Note: This is a traditional "Make Required" action, not a validation rule

Rule Configuration - Part 3: Budget Matches Its Band​

  • Screen: Global Issue Create
  • Target Field: Estimated Budget
  • Scope: Feature
  • Condition: Cost Band equals "Up to $10,000"
  • Validation: Number less than
  • Threshold: 10001
  • Error Message: "Budgets over $10,000 need the Over $10,000 cost band and a Finance Approval Code."
info

Pattern: Combine validation rules (for data quality) with conditional required fields (for approval workflows). Validation ensures Budget is positive and fits the chosen band; conditional required ensures approval for high-cost items. A rule condition can't compare a number with a threshold (a number field offers equals, not equals, is empty and is not empty), so the threshold lives in the Cost Band select list and a validation rule checks the number against it. See Operators by Field Type. Number validations let an empty field through, so make Estimated Budget required as well.

User Experience​

Scenario 1: Low-cost feature

  • User creates Feature with Estimated Budget = $5,000 and Cost Band = Up to $10,000
  • Budget validations pass (5000 > 0, and below the band's limit)
  • 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 and Cost Band = Over $10,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 approval

  • User creates Feature with Estimated Budget = $15,000 but leaves Cost Band at Up to $10,000
  • Budget validation fails: "Budgets over $10,000 need the Over $10,000 cost band and a Finance Approval Code."
  • User switches Cost Band to Over $10,000, and Finance Approval Code becomes required automatically
  • An Estimated Budget of 0 fails too: "Estimated Budget must be greater than 0"

Why It Works​

  • Automated governance - System enforces approval policy without manual oversight
  • Lightweight for small features - Low-cost features avoid approval bureaucracy
  • Prevents workarounds - The budget is checked against the chosen band, so picking the lower band doesn't skip approval, and a zero budget is rejected
  • 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

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 after 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 after Request Date
  3. Number validation: Customer Satisfaction between 1-5
  4. Presence validation: Escalation Contact not empty (Satisfaction equals 1 OR Satisfaction equals 2)

Financial Services​

Common validations:

  • Transaction Amount > 0
  • Approval Code required for large transactions (an Amount Band select list set to Over $5,000)
  • Settlement Date after Trade Date
  • Audit Notes required for exceptions

Example rule set:

  1. Number validation: Transaction Amount > 0
  2. Presence validation: Approval Code not empty (Amount Band = Over $5,000)
  3. Date validation: Settlement Date after Trade Date (the comparison is strict, so a same-day settlement fails)
  4. Text validation: Audit Notes ≥30 chars (Type = Exception)

Combining Validations with Other Rules​

Validation rules work best when combined with other Formify actions for complete form control.

Pattern 1: Hide + Validate + Require​

Use case: Progressive disclosure with quality enforcement

Configuration:

  • Rule 1: Hide "Root Cause" when Priority not equals 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 Cost Band equals "Over $10,000"
  • 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 after Start Date
  • Rule 2: Validate Review Date after Start Date
  • Rule 3: Validate Review Date before End Date
  • Rule 4: Make all three dates required for Epics (one rule per date)

Each validation compares a date with one other field, so Review Date needs two rules.

Result: Complete timeline validation with logical sequencing.

Tips for Effective Validation Rules​

Writing Clear Error Messages​

Good error messages:

  • "Due Date must be tomorrow or later 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:

  • Text made only of spaces (fails "Must not be empty"; the spaces count toward "Minimum text length")
  • Zero values for numbers (passes "not empty", fails "greater than 0")
  • Empty number and date fields (pass the number and date validations; add "Must not be empty" to catch them)
  • Today's date (fails "Date after today", passes "Date at least X days from today" with 0 days)
  • Equal dates (fail both "Date after another field" and "Date before another field")

Next Steps​