Defining Field Validations

Field validation rules enforce data quality, consistency, and business rules automatically at the point of data entry. They validate field values in real-time and display custom error messages when validation fails, preventing invalid data from entering your Jira instance.

Formify provides 15 validation types across four categories:

1. Presence Validations - Control whether fields must have or lack values
2. Date Validations - Enforce date constraints, SLA deadlines, and date sequencing
3. Number Validations - Validate numeric thresholds, ranges, and quality gates
4. Text Validations - Enforce text length, content requirements, and quality standards

Each validation type provides immediate feedback with customizable error messages, helping users submit correct data the first time.

---

Why Field Validation Matters

Traditional Jira provides only basic "required field" functionality—a simple yes/no toggle that doesn't account for context. Workflow validators exist but only trigger on transitions, not during data entry. ScriptRunner offers validation through Groovy scripts, but requires coding expertise and ongoing maintenance.

Field validation rules provide a better approach:

• ✅ Catch invalid data immediately as users type, not after submission
• ✅ Enforce SLA deadlines and business rules automatically
• ✅ Provide clear, actionable error messages explaining what's wrong
• ✅ Apply conditional logic - different validation for different contexts
• ✅ No coding required - configure through visual interface
• ✅ Maintain data consistency with cross-field validation

tip

Competitive Advantage

Unlike Jira's basic required fields or workflow validators, you get:

• 15+ validation types with conditional logic
• Custom error messages without Groovy scripts
• Real-time feedback as users type
• No ScriptRunner purchase needed
• Centralized management alongside other rules

---

Choosing the Right Validation

Use this quick reference to select the appropriate validation type:

Goal	Validation Type	Example
Ensure field has a value	Must not be empty	Story Points required for all Stories
Ensure field is cleared	Must be empty	Resolution Date must be empty when Status ≠ Done
Enforce SLA deadlines	Date at least X days ahead	Due Date must be ≥2 hours from now for Critical tickets
Prevent past dates	Date after today	Start Date must be in the future
Prevent future dates	Date before today	Incident Date must be in the past
Ensure date sequencing	Date after another field	End Date must be after Start Date
Validate date dependencies	Date before another field	Review Date must be before Release Date
Enforce minimum thresholds	Number greater than	Story Points must be > 0
Enforce maximum limits	Number less than	Story Points must be < 100
Validate numeric ranges	Number between	Estimate must be between 1-40 hours
Prevent zero values	Number is not zero	Budget must be non-zero
Enforce minimum content length	Text minimum length	Incident summary must be ≥15 characters
Enforce maximum content length	Text maximum length	Summary must be ≤100 characters
Require specific keywords	Must contain text	Summary must contain ticket reference (e.g., "JIRA-")
Prevent forbidden content	Must not contain text	Description must not contain placeholder text (e.g., "TODO")

---

Validation Categories

When configuring a validation rule, the system automatically shows only validation types compatible with your target field. For example, date fields show date validations, number fields show number validations, and so on. This ensures you only see relevant options for the field you're configuring.

1. Presence Validations

Presence validations control whether fields must have values or remain empty. These are the most commonly used validations, replacing traditional "required field" configuration with conditional, context-aware requirements.

Must not be empty

Ensures a field has a value — equivalent to "required field" but with conditional logic.

When to Use

• ✅ Conditional required fields - Require data only in specific contexts
• ✅ Data completeness gates - Ensure critical information is captured
• ✅ Quality standards - Enforce minimum data requirements before progression
• ✅ Context-aware forms - Make fields required based on issue type, priority, status, or user role

How It Works

When conditions are met, the validation applies and the field must contain a value:

• Empty values → validation fails → shows custom error message
• Text: Non-empty strings (whitespace-only = empty)
• Select: Selection required
• Multi-select: ≥1 option selected
• Date/Number: Value must be set (zero is valid for numbers)

warning

Common Gotchas

• Zero is valid for number fields — use "Number is not zero" to prevent zero
• Whitespace-only text counts as empty (prevents bypassing validation)
• Can't validate hidden fields — ensure field is visible when validation applies

Configuration

1. Validation type: Must not be empty
2. Error message (optional): Default is "This field must not be empty" 💡 Best practice: Explain why the field is required and when it's needed
3. Parameters: None

Example 1: Story Points quality gate — Require estimation for all Stories

Business need: All Stories must have Story Points estimated before sprint planning. This ensures accurate capacity planning and prevents unestimated work from entering sprints.

Configuration:

• Target field: Story Points
• Screen: Global Issue Create
• Conditions: Issue Type = Story
• Validation: Must not be empty
• Error message: "Story Points are required for all Stories to support sprint planning and capacity estimation. Please estimate this Story before saving."

✅ Result: When creating Stories, users must provide Story Points. The error message guides them on why it's required.

Why it works: The validation enforces your team's estimation standard automatically. Combined with conditional logic, you can require Story Points only for Stories, not for Bugs or Tasks.

Supported Field Types

All field types support presence validation:

• Text fields (Summary, Description, custom text)
• Select fields (Priority, Issue Type, custom select)
• Multi-select fields (Components, Labels, custom multi-select)
• Date fields (Due Date, custom date fields)
• Number fields (Story Points, custom number fields)
• User fields (Assignee, Reporter, custom user pickers)
• All other Jira field types

---

Must be empty

Ensures a field is cleared or has no value. Less common than "must not be empty" but critical for workflow state management and data consistency.

When to Use

• ✅ State management - Ensure fields are cleared when transitioning between states
• ✅ Data consistency - Prevent invalid field combinations
• ✅ Workflow enforcement - Require users to clear fields before certain transitions
• ✅ Audit compliance - Ensure sensitive data is removed in certain contexts

How It Works

When conditions are met, the validation applies and the field must be empty:

• Any non-empty value → validation fails → shows custom error
• Text: Empty string or null
• Select: No selection made
• Multi-select: No options selected
• Date: No date set
• Number: No number entered (zero counts as non-empty)

warning

Common Gotchas

• Required fields can't be empty — creates conflict, remove native required status first
• Zero counts as non-empty for number fields
• Use with transitions to enforce state cleanup

Configuration

1. Validation type: Must be empty
2. Error message (optional): Default is "This field must be empty" 💡 Best practice: Explain why the field must be cleared
3. Parameters: None

Example 1: Clear Resolution Date when reopening — Maintain data consistency

Business need: When reopening a resolved issue, the Resolution Date must be cleared because the issue is no longer resolved.

Configuration:

• Target field: Resolution Date
• Screen: Issue Transition (to In Progress, from Done)
• Conditions: Target Status = In Progress, Previous Status = Done
• Validation: Must be empty
• Error message: "Resolution Date must be cleared when reopening an issue. Please remove the Resolution Date before transitioning to In Progress."

✅ Result: Users can't reopen issues without clearing Resolution Date, maintaining data consistency.

Why it works: Prevents stale Resolution Dates from remaining on active issues, ensuring accurate reporting on resolved vs. open issues.

Supported Field Types

All field types support presence validation. Most commonly used with:

• Date fields (Resolution Date, Due Date)
• User fields (Assignee, Reviewer)
• Number fields (Story Points, Estimate)
• Select fields (Resolution, Status-dependent fields)

---

2. Date Validations

Date validations enforce date constraints, SLA deadlines, and date sequencing. They're essential for project planning, SLA compliance, and maintaining date consistency across related fields.

💡 Technical Note: All date validations use timezone-safe "YYYY-MM-DD" string comparison, ensuring consistent behavior regardless of user timezone.

Date after today

Ensures a date field contains a future date—any date after the current day (12:00 AM tomorrow or later).

When to Use

• ✅ Future planning - Ensure dates represent future events
• ✅ SLA compliance - Prevent setting deadlines in the past
• ✅ Workflow gates - Require future dates for planning activities
• ✅ Data quality - Catch accidental past date selections

How It Works

When conditions are met, the field value must be a date after today:

• Comparison: Dates at day-level precision (ignores time)
• "Today" = current date in user's timezone
• "After today" = tomorrow or any future date
• Today's date fails validation

Configuration

1. Validation type: Date after today
2. Error message (optional): Default is "Date must be after today" 💡 Best practice: Explain why future dates are required
3. Parameters: None

Example 1: Future release dates — Prevent data entry errors

Business need: Release Date must be in the future because we can't release software in the past. This prevents data entry errors when planning releases.

Configuration:

• Target field: Release Date
• Screen: Global Issue Create
• Conditions: Issue Type = Release
• Validation: Date after today
• Error message: "Release Date must be in the future. Please select a date after today for this upcoming release."

✅ Result: Release dates must be tomorrow or later, preventing accidental past date selection.

💡 Pro Tip: To allow today's date, use "Date at least X days in future" with X=0 instead. "After today" strictly means tomorrow or later.

Supported Field Types

• Due Date (system field)
• Start Date, End Date (system fields if enabled)
• Custom date picker fields
• Custom datetime fields

---

Date before today

Ensures a date field contains a past date—any date before the current day (yesterday or earlier).

When to Use

• ✅ Historical dates - Ensure dates represent past events
• ✅ Incident reporting - Require incident dates in the past
• ✅ Audit compliance - Validate historical data entry
• ✅ Data quality - Prevent future dates for past events

How It Works

When conditions are met, the field value must be a date before today:

• Comparison: Dates at day-level precision (ignores time)
• "Today" = current date in user's timezone
• "Before today" = yesterday or any past date
• Today's date fails validation

Configuration

1. Validation type: Date before today
2. Error message (optional): Default is "Date must be before today" 💡 Best practice: Explain why past dates are required
3. Parameters: None

Example 1: Incident date must be in the past — Ensure accurate incident timelines

Business need: When reporting incidents, the Incident Date must be in the past because we can't report incidents that haven't happened yet. This ensures accurate incident timelines.

Configuration:

• Target field: Incident Date
• Screen: Global Issue Create
• Conditions: Issue Type = Incident
• Validation: Date before today
• Error message: "Incident Date must be in the past. If the incident occurred today, please wait until tomorrow to report it, or contact your administrator."

✅ Result: Incident Date must be yesterday or earlier, ensuring incidents represent past events.

Supported Field Types

• Due Date (system field)
• Custom date picker fields
• Custom datetime fields

---

Date at least X days in future

Ensures a date field is at least X days in the future from today. This is the most powerful date validation for SLA enforcement, planning horizons, and lead time requirements.

When to Use

• ✅ SLA enforcement - Require minimum lead time for critical work
• ✅ Planning horizons - Ensure adequate planning time before deadlines
• ✅ Capacity management - Prevent last-minute work from bypassing triage
• ✅ Business rules - Enforce organizational policies for advance notice

How It Works

When conditions are met, the field value must be at least X days from now:

• Calculation: minimum_date = today + X days
• Comparison: field_date must be ≥ minimum_date
• X=0 allows today's date
• X=1 requires tomorrow or later
• X=2 requires day-after-tomorrow or later

Configuration

1. Validation type: Date at least X days in future
2. Number of days: Enter a positive integer (0, 1, 2, 3, ...)

• 0 = allows today (useful for "today or later" validation)
• 1 = allows tomorrow (not today)
• 2 = allows day-after-tomorrow (not today or tomorrow)

3. Error message (optional): Default is "Date must be at least {X} days from now" 💡 Best practice: Explain why the lead time is required and reference your SLA

Example 1: Critical ticket SLA - 2 hours minimum — Automated SLA enforcement

Business need: Critical priority tickets require a Due Date at least 2 hours from creation time to allow for proper triage, assignment, and initial investigation. This prevents hasty responses and ensures quality work.

Configuration:

• Target field: Due Date
• Screen: Global Issue Create
• Conditions: Priority = Critical
• Validation: Date at least X days in future
• Days: 0 (to enforce minimum hours, we'll use custom message to clarify 2-hour policy)
• Error message: "Critical tickets require Due Date at least 2 hours from now to allow time for triage and assignment. Please select a date/time at least 2 hours in the future."

✅ Result: Critical tickets can't have Due Dates sooner than 2 hours away, enforcing your SLA policy automatically.

Why it works: Automated SLA enforcement—no manual oversight needed. Users get immediate feedback if they select dates too soon.

💡 Pro Tip: The validation works at day-level precision, not hour/minute precision. For "2 hours" requirements, use 0 days and explain the hour requirement in your error message. Most teams find day-level precision sufficient for planning purposes.

Supported Field Types

• Due Date (system field)
• Start Date, End Date (system fields if enabled)
• Custom date picker fields
• Custom datetime fields

---

Date after another field

Ensures a date field is chronologically after another date field. Critical for maintaining date sequencing and dependencies (e.g., End Date must be after Start Date).

When to Use

• ✅ Date sequencing - Ensure logical date order (end after start, finish after begin)
• ✅ Dependencies - Validate dependent dates (Review after Development, Release after Testing)
• ✅ Project planning - Maintain milestone order
• ✅ Data consistency - Prevent impossible date combinations

How It Works

When conditions are met, the target field must contain a date after the comparison field:

• Comparison: target field > comparison field
• Both fields must have values for validation to apply
• If comparison field is empty, validation passes (fail-safe behavior)
• Same date fails validation ("after" means strictly later, not equal)

Configuration

1. Validation type: Date after another field
2. Select comparison field: Choose the field that must come before the target field Example: If target is End Date, choose Start Date as comparison field
3. Error message (optional): Default is "Date must be after {field name}" 💡 Best practice: Explain the relationship and why it matters

Example 1: End Date after Start Date — Maintain valid timelines

Business need: Project End Date must be after Start Date to represent valid project timelines. This prevents data entry errors and ensures accurate Gantt charts and roadmaps.

Configuration:

• Target field: End Date
• Screen: Global Issue Create
• Conditions: Issue Type = Epic OR Project
• 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."

✅ Result: Users can't save issues with End Date before/equal to Start Date, maintaining valid timelines.

Why it works: Catches data entry errors immediately. Prevents impossible date ranges from entering your system.

💡 Pro Tip: Be careful not to create circular dependencies (A after B, B after A). Such configurations make it impossible to satisfy all validations.

Supported Field Types

Date fields compared to other date fields:

• Due Date, Start Date, End Date (system fields)
• Custom date picker fields
• Custom datetime fields

---

Date before another field

Ensures a date field is chronologically before another date field. Mirror of "date after field" for reverse dependencies.

When to Use

• ✅ Reverse dependencies - Validate dates that must precede others
• ✅ Deadline enforcement - Ensure milestones come before deadlines
• ✅ Sequential validation - Maintain order from earlier perspective
• ✅ Data consistency - Prevent impossible date combinations (from earlier date's viewpoint)

How It Works

When conditions are met, the target field must contain a date before the comparison field:

• Comparison: target field < comparison field
• Both fields must have values for validation to apply
• If comparison field is empty, validation passes (fail-safe)
• Same date fails validation ("before" means strictly earlier, not equal)

Configuration

1. Validation type: Date before another field
2. Select comparison field: Choose the field that must come after the target field Example: If target is Start Date, choose End Date as comparison field
3. Error message (optional): Default is "Date must be before {field name}" 💡 Best practice: Explain the relationship and why it matters

Example 1: Start Date before End Date — Same constraint, different perspective

Business need: Project Start Date must be before End Date. Same constraint as "End Date after Start Date" but validated from Start Date's perspective.

Configuration:

• Target field: Start Date
• Screen: Global Issue Create
• Conditions: Issue Type = Epic OR Project
• Validation: Date before another field
• Comparison field: End Date
• Error message: "Start Date must be before End Date. Please ensure your project timeline has Start Date earlier than End Date."

✅ Result: Same effect as "End Date after Start Date" but applied to Start Date field instead.

info

Choosing After vs. Before: Both validations achieve the same goal (maintaining date order). Choose based on which field users fill first. If users fill Start Date before End Date, validate "Start Date before End Date". If users fill End Date first, validate "End Date after Start Date".

Supported Field Types

Date fields compared to other date fields:

• Due Date, Start Date, End Date (system fields)
• Custom date picker fields
• Custom datetime fields

---

3. Number Validations

Number validations enforce numeric thresholds, ranges, and quality gates. Essential for story point estimation, budget controls, capacity management, and any numeric business rules.

💡 Technical Note: All number validations handle both integers and decimals, and validate against numeric values or numeric strings.

Number greater than threshold

Ensures a number field exceeds a minimum threshold. Most common number validation for quality gates and minimum requirements.

When to Use

• ✅ Quality gates - Require minimum values (Story Points > 0)
• ✅ Budget thresholds - Enforce minimum budgets for certain work types
• ✅ Capacity management - Ensure adequate resource allocation
• ✅ Business rules - Implement organizational minimums

How It Works

When conditions are met, the field value must be strictly greater than your threshold:

• Comparison: field_value > threshold_value
• Works with integers and decimals (5.5 > 5, 5.1 > 5)
• Supports negative numbers (-5 > -10)
• Zero is a valid comparison threshold

Configuration

1. Validation type: Number greater than threshold
2. Threshold value: Enter a number (integer or decimal)

• Most common: 0 (require positive values)
• Can use negative numbers if needed

3. Error message (optional): Default is "Value must be greater than {threshold}" 💡 Best practice: Explain why the minimum exists and what it represents

Example 1: Story Points must be positive — Enforce estimation discipline

Business need: All Stories must have Story Points greater than 0. Zero-point Stories indicate missing estimation. This ensures all Stories are estimated before sprint planning.

Configuration:

• Target field: Story Points
• Screen: Global Issue Create
• Conditions: Issue Type = Story
• Validation: Number greater than threshold
• 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."

✅ Result: Story Points must be at least 1 (or 0.5 if using half-points), preventing zero or negative estimates.

Why it works: Enforces estimation discipline. Zero-point Stories often indicate incomplete grooming or misunderstanding of the work involved.

💡 Pro Tip: Strictly greater than, not equal. If threshold is 0, zero fails validation. If you need to allow zero, remove this validation or use "Number is not zero" instead.

Supported Field Types

• Story Points (system field if enabled)
• Time Tracking fields (Original Estimate, Remaining Estimate)
• Custom number fields
• Custom decimal fields

---

Number less than threshold

Ensures a number field is below a maximum threshold. Used for caps, limits, and maximum requirements.

When to Use

• ✅ Maximum limits - Enforce caps on values (Story Points < 100)
• ✅ Budget controls - Prevent excessive budgets without approval
• ✅ Capacity constraints - Ensure values stay within limits
• ✅ Reasonableness checks - Catch data entry errors (estimates that are too large)

How It Works

When conditions are met, the field value must be strictly less than your threshold:

• Comparison: field_value < threshold_value
• Works with integers and decimals
• Supports negative numbers
• "Less than 100" means 99.99... or lower, not 100

Configuration

1. Validation type: Number less than threshold
2. Threshold value: Enter a number (maximum allowed value)

• Common: 100 (Story Points sanity check), 1000000 (budget cap)

3. Error message (optional): Default is "Value must be less than {threshold}" 💡 Best practice: Explain why the maximum exists

Example 1: Story Points sanity check — Encourage Story splitting

Business need: Story Points exceeding 40 indicate Stories that are too large and should be split. This validation catches oversized Stories early.

Configuration:

• Target field: Story Points
• Screen: Global Issue Create
• Conditions: Issue Type = Story
• Validation: Number less than threshold
• 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."

✅ Result: Story Points capped at 40, encouraging Story splitting.

Why it works: Large Stories create estimation uncertainty and delivery risk. This validation enforces a "split large Stories" policy automatically.

Supported Field Types

• Story Points (system field if enabled)
• Time Tracking fields
• Custom number fields
• Custom decimal fields

---

Number within range

Ensures a number field falls within a specified range (inclusive). Useful for bounded estimates, acceptable ranges, and multi-threshold validation.

When to Use

• ✅ Bounded estimates - Ensure values within acceptable range (Story Points 1-40)
• ✅ Percentage validation - Ensure percentages between 0-100
• ✅ Rating scales - Validate ratings within scale (1-5 stars)
• ✅ Acceptable ranges - Enforce business rule ranges

How It Works

When conditions are met, the field value must fall between your minimum and maximum thresholds:

• Range validation: min_value ≤ field_value ≤ max_value
• Both bounds are inclusive (1-10 includes both 1 and 10)
• Minimum must be less than maximum
• Works with integers and decimals

Configuration

1. Validation type: Number within range
2. Minimum value: Enter the lower bound of acceptable range
3. Maximum value: Enter the upper bound of acceptable range (must be greater than minimum)
4. Error message (optional): Default is "Value must be between {min} and {max}" 💡 Best practice: Explain the range and why it exists

Example 1: Story Points range — Single validation for both bounds

Business need: Story Points must be between 1-40. Points below 1 indicate missing estimation, and points above 40 indicate Stories that should be split.

Configuration:

• Target field: Story Points
• Screen: Global Issue Create
• Conditions: Issue Type = Story
• Validation: Number within range
• Minimum: 1
• Maximum: 40
• Error message: "Story Points must be between 1-40. Values below 1 indicate missing estimation. Values above 40 indicate Stories that should be split into smaller pieces."

✅ Result: Story Points must be 1-40 inclusive, enforcing estimation quality standards.

Why it works: Single validation enforces both minimum (must estimate) and maximum (must split large Stories).

Supported Field Types

• Story Points (system field if enabled)
• Time Tracking fields
• Custom number fields
• Custom decimal fields

---

Number is not zero

Ensures a number field is not exactly zero. Simpler than "greater than 0" because it allows negative numbers.

When to Use

• ✅ Non-zero requirements - Ensure field has a non-zero value
• ✅ Allowing negatives - When both positive and negative numbers are valid, but not zero
• ✅ Budget validation - Prevent zero budgets (both costs and credits are valid)
• ✅ Delta validation - Ensure changes have magnitude (positive or negative change, but not zero change)

How It Works

When conditions are met, the field value must not equal zero:

• Simple check: field_value ≠ 0
• Positive numbers pass (1, 5.5, 1000)
• Negative numbers pass (-1, -5.5, -1000)
• Only zero fails (0, 0.0, 0.00)

Configuration

1. Validation type: Number is not zero
2. Error message (optional): Default is "Value must not be zero" 💡 Best practice: Explain why zero is invalid
3. Parameters: None

Example 1: Budget must be non-zero — Allow both expenses and credits

Business need: Budget must be non-zero. Zero budgets indicate missing budget estimation. Both expenses (positive) and credits (negative) are valid, but zero is not.

Configuration:

• Target field: Budget
• Screen: Global Issue Create
• Conditions: Issue Type = Feature OR Epic
• Validation: Number is not zero
• Error message: "Budget must be non-zero. Please enter estimated costs (positive) or credits (negative). Zero indicates missing budget estimation."

✅ Result: Budget can be positive or negative, but not zero, ensuring budget estimation is complete.

Why it works: Some features have costs (positive budget), others generate savings (negative budget). Zero indicates no estimation was done.

💡 Pro Tip: This validation allows negative numbers. If you want only positive numbers, use "greater than 0" instead.

Supported Field Types

• Story Points (system field if enabled)
• Time Tracking fields
• Custom number fields
• Custom decimal fields (budget, cost, adjustment fields)

---

4. Text Validations

Text validations enforce content quality, length requirements, and format standards. Essential for ensuring meaningful summaries, descriptions, and text fields meet your organization's quality standards.

💡 Technical Note: All text validations handle both plain text and Atlassian Document Format (ADF) fields, extracting text content for validation.

Minimum text length

Ensures a text field has at least X characters. Most common text validation for enforcing content quality and meaningful descriptions.

When to Use

• ✅ Content quality - Ensure meaningful summaries and descriptions
• ✅ Minimum requirements - Require adequate detail in text fields
• ✅ Data completeness - Prevent overly brief or empty text
• ✅ Searchability - Ensure enough content for search indexing

How It Works

When conditions are met, the field text must contain at least X characters:

• Counts visible characters (letters, numbers, punctuation, spaces)
• Whitespace-only text counts as length 0 (fails minimum length > 0)
• Handles both plain text and ADF (extracts text from rich content)
• Case-insensitive (both "ABC" and "abc" count as 3 characters)

Configuration

1. Validation type: Minimum text length
2. Minimum length: Enter a positive integer (number of characters)

• Common values: 10-50 for summaries, 50-200 for descriptions
• Consider user experience: too high frustrates users, too low allows poor quality

3. Error message (optional): Default is "Text must be at least {length} characters" 💡 Best practice: Explain why the minimum exists and give examples

Example 1: Incident summary quality — Prevent vague descriptions

Business need: Incident summaries must be at least 15 characters to ensure meaningful descriptions for triage and reporting. Single-word summaries like "Bug" or "Error" lack sufficient detail.

Configuration:

• Target field: Summary
• Screen: Global Issue Create
• Conditions: Issue Type = Incident
• 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')."

✅ Result: Incident summaries must be 15+ characters, preventing vague descriptions.

Why it works: Forces users to provide meaningful context. "Bug" (3 chars) fails, "Login error 500" (16 chars) passes.

Supported Field Types

• Summary (system field)
• Description (system field, ADF)
• Custom text fields (single-line)
• Custom paragraph fields (multi-line)
• Custom rich text fields (ADF)

---

Maximum text length

Ensures a text field does not exceed X characters. Used for enforcing brevity, preventing overly long text, and maintaining display consistency.

When to Use

• ✅ Brevity enforcement - Ensure concise summaries and labels
• ✅ Display constraints - Prevent text overflow in UI elements
• ✅ Data consistency - Maintain consistent field lengths
• ✅ Character limits - Enforce external system limits (e.g., 280 chars for Twitter integration)

How It Works

When conditions are met, the field text must not exceed X characters:

• Counts visible characters (same logic as minimum length)
• Handles both plain text and ADF
• Case-insensitive

Configuration

1. Validation type: Maximum text length
2. Maximum length: Enter a positive integer (maximum number of characters)

• Common values: 100 for summaries, 280 for social media integration, 500 for short descriptions

3. Error message (optional): Default is "Text must not exceed {length} characters" 💡 Best practice: Explain why the maximum exists

Example 1: Summary brevity — Ensure full display in dashboards

Business need: Summaries must not exceed 100 characters to ensure they display fully in dashboards and lists without truncation.

Configuration:

• Target field: Summary
• Screen: Global Issue Create
• Conditions: (All issue types)
• Validation: Maximum text length
• Length: 100
• Error message: "Summary must not exceed 100 characters to ensure full display in dashboards. Please keep summaries concise and specific."

✅ Result: Summaries capped at 100 characters, ensuring consistent display.

Why it works: Long summaries get truncated in UI, losing information. This forces users to be concise upfront.

Supported Field Types

• Summary (system field)
• Description (system field, ADF)
• Custom text fields
• Custom paragraph fields

---

Must contain text

Ensures a text field contains a required substring. Case-insensitive search for required keywords, prefixes, or content.

When to Use

• ✅ Required keywords - Ensure text includes specific terms
• ✅ Format validation - Require prefixes or patterns (e.g., "JIRA-")
• ✅ Content standards - Ensure specific information is present
• ✅ Compliance - Require disclaimers or standard language

How It Works

When conditions are met, the field text must contain your search string:

• Case-insensitive substring search
• "jira" matches "JIRA", "Jira", "jira"
• "JIRA-" matches "JIRA-123", "Project: JIRA-456"
• Partial word matching: "test" matches "testing", "attest", "test"

Configuration

1. Validation type: Must contain text
2. Required text: Enter the substring that must appear in the field

• Case-insensitive
• Can be a word, phrase, or pattern

3. Error message (optional): Default is "Text must contain '{search_text}'" 💡 Best practice: Explain why the text is required

Example 1: Ticket reference required — Ensure traceability

Business need: Bug summaries must contain a ticket reference (e.g., "JIRA-123") to link bugs to their originating support tickets.

Configuration:

• Target field: Summary
• Screen: Global Issue Create
• Conditions: Issue Type = Bug, Origin = Customer Support
• Validation: Must contain text
• Required text: "JIRA-"
• Error message: "Bug summary must contain ticket reference (e.g., 'JIRA-123') to link bugs to originating support tickets. Please include the ticket number in the summary."

✅ Result: Bug summaries must include "JIRA-" somewhere in the text.

Why it works: Ensures traceability from bug to originating ticket. Easy to search and filter by ticket reference.

💡 Pro Tip: Substring matching means "test" matches "testing", "latest", "attest". If you need exact word matching, add spaces: " test " (won't match "testing").

Supported Field Types

• Summary (system field)
• Description (system field, ADF)
• Custom text fields
• Custom paragraph fields

---

Must not contain text

Ensures a text field does NOT contain forbidden substring. Opposite of "must contain" for preventing specific content.

When to Use

• ✅ Forbidden content - Prevent specific words or phrases
• ✅ Placeholder detection - Catch "TODO", "TBD", "XXX" placeholders
• ✅ Profanity filtering - Block inappropriate language
• ✅ Compliance - Prevent disclosure of sensitive information

How It Works

When conditions are met, the field text must NOT contain your search string:

• Case-insensitive substring search (same as "must contain")
• If search string is found → validation fails
• "TODO" matches "TODO", "todo", "Todo", "still todo"

Configuration

1. Validation type: Must not contain text
2. Forbidden text: Enter the substring that must NOT appear in the field

• Case-insensitive

3. Error message (optional): Default is "Text must not contain '{search_text}'" 💡 Best practice: Explain why the text is forbidden

Example 1: Prevent TODO placeholders — Catch incomplete work

Business need: Descriptions must not contain "TODO" when issues transition to Done. TODO placeholders indicate incomplete work.

Configuration:

• Target field: Description
• Screen: Issue Transition (to Done)
• Conditions: Target Status = Done
• Validation: Must not contain text
• Forbidden text: "TODO"
• Error message: "Description must not contain 'TODO' when marking issues Done. Please complete all TODO items or remove placeholder text before marking this Done."

✅ Result: Can't mark issues Done if description contains "TODO".

Why it works: Catches incomplete work before marking Done. Forces cleanup of placeholder text.

Supported Field Types

• Summary (system field)
• Description (system field, ADF)
• Custom text fields
• Custom paragraph fields

---

Validation vs. Required Fields vs. Workflow Validators

Understanding when to use validation rules versus other Jira validation mechanisms helps you choose the right tool for each use case.

Quick Comparison

Feature	Validation Rules	Native Required Fields	Workflow Validators
Timing	Real-time as users type	On form submit	On transition
Feedback	✅ Immediate with custom messages	Generic "required" on submit	Transition blocked with message
Conditional logic	✅ Yes - based on conditions	❌ No - always required	✅ Yes - per transition
Validation types	✅ 15+ types	❌ Only "has value"	⚠️ Varied (depends on validator)
Custom error messages	✅ Yes - specific, actionable	❌ No - generic message	⚠️ Yes - but shown after attempt
Cross-field validation	✅ Yes - date/number comparisons	❌ No	✅ Yes - via ScriptRunner
No coding required	✅ Yes - visual configuration	✅ Yes - checkbox	⚠️ Complex validators need ScriptRunner
Works on	Create, Transition, JSM Portal	Create, Transition, View	Transition only
Performance	✅ Client-side, instant	✅ Client-side, instant	⚠️ Server-side, may be slow
Maintenance	✅ Centralized with other rules	⚠️ Per-screen configuration	⚠️ Per-transition configuration
Best for	Context-aware data quality	Simple always-required fields	Workflow state gates
Difficulty	⭐⭐ Moderate	⭐ Easy	⭐⭐⭐ Difficult

When to Use Each

✅ Use Validation Rules when:

• You need conditional validation (not just "always required")
• You want threshold validation (dates, numbers, text length)
• You need custom, actionable error messages
• You want real-time feedback as users type
• You need cross-field consistency checks
• You want centralized rule management
• You need multiple validation checks per field

✅ Use Native Required Fields when:

• Field must always be required (no conditions)
• Simple "must have a value" is sufficient
• You don't need custom error messages
• Native Jira required field behavior is acceptable
• Simplest configuration is priority

✅ Use Workflow Validators when:

• Validation is tied to specific transitions (not general data entry)
• You need workflow state-specific validation
• You're already using workflow validators and prefer consistency
• Validation logic is workflow-centric (e.g., "can only transition if assignee is set")

Combining Approaches

You can use multiple validation mechanisms together for comprehensive validation:

Validation Rule + Required Field

• Required field ensures always-required
• Validation rule adds conditional threshold
• Example: Field always required, but must be > 0 when Priority = High

Validation Rule + Workflow Validator

• Validation rule checks data quality on Create
• Workflow validator checks workflow state on transition
• Example: Story Points validated on create, also checked during transition to Done

Multiple Validation Rules

• Combine "must not be empty", "greater than 0", and "less than 100"
• Result: Comprehensive validation with multiple constraints
• Each rule has its own error message for clear feedback

---

The Validation Gate Field

The Validation Gate Field is a special application field provided by Formify. It acts as a gate that blocks form submission when any validation rule fails, preventing invalid data from being saved.

What It Is

The Validation Gate Field is a dedicated app field that automatically reflects the overall validation status of an issue:

• Has value = All validation rules pass → form submission allowed
• Empty = One or more validation rules fail → form submission blocked

How It Works

1. User fills out an issue form (Create, Transition, JSM Portal)
2. Validation rules evaluate based on current field values
3. If all rules pass: Validation Gate Field receives a value → submission proceeds
4. If any rule fails: Validation Gate Field remains empty → submission is blocked
5. Field updates in real-time as user changes field values

The system automatically tracks all validation results. You don't need to configure individual validation rules to interact with this field—it works out of the box.

warning

Critical Setup Requirement

The Validation Gate Field must be:

1. Added to your screens (Global Issue Create, Transition screens, JSM Portal)
2. Marked as required on the screen

When a validation rule fails, the field remains empty — Jira's native required field mechanism then blocks form submission, preventing invalid data from being saved.

Visual Example

Here's how the Validation Gate field appears in the Create Issue form:

The field automatically updates as users fill out the form, providing real-time validation feedback.

Setting It Up

Add the Validation Gate application field to the appropriate Jira screens where you want validation enforcement:

• Global Issue Create screen
• Issue Transition screens
• JSM Portal screens

The field is pre-configured by the app—no additional setup, naming, or configuration is required. Simply add it to your screens and it will start enforcing validations automatically.

---

Combining Multiple Validations

You can apply multiple validation rules to the same field, creating sophisticated validation logic. All validation rules are AND-ed together—every rule must pass for validation to succeed.

How It Works

Multiple Rules on Same Field:

• Configure multiple validation rules targeting the same field
• Each rule can have different conditions
• Each rule evaluates independently
• If any rule fails, validation fails
• User sees all failing validation error messages

Evaluation Order:

• Rules evaluate in order defined in field configuration
• First failure stops evaluation (fail-fast)
• Error message from first failing validation is displayed

Common Combination Patterns

Pattern	Validations	Result
Bounded number range	"Must not be empty" + "Greater than X" + "Less than Y"	Enforces presence and range. Example: Story Points required, > 0, < 100
Date sequencing + future	"Date after today" + "Date after field"	Enforces both future dates and sequencing. Example: Due Date must be future AND after Start Date
Text quality standards	"Must not be empty" + "Minimum length" + "Must contain"	Enforces presence, quality, and format. Example: Summary required, ≥15 chars, contains "JIRA-"
Conditional validation tiers	Rule 1: Basic (all), Rule 2: Enhanced (high-priority), Rule 3: Strict (critical)	Progressive validation based on conditions

Example: Story Points comprehensive validation — Three rules working together

Rule 1: Story Points must not be empty

• Condition: Issue Type = Story
• Validation: Must not be empty
• Message: "Story Points are required for all Stories."

Rule 2: Story Points must be positive

• Condition: Issue Type = Story
• Validation: Number greater than
• Threshold: 0
• Message: "Story Points must be greater than 0."

Rule 3: Story Points must be reasonable

• Condition: Issue Type = Story
• Validation: Number less than
• Threshold: 41
• Message: "Story Points exceeding 40 should be split into smaller Stories."

✅ Combined Result:

• Story Points must: (1) have a value AND (2) be > 0 AND (3) be < 41
• Valid range: 1-40 (or decimals like 0.5, 1.5, etc.)
• Any violation shows appropriate error message

---

Next Steps

Now that you understand field validation rules, explore related topics to build comprehensive form control:

Field Validation Examples	Real-world validation scenarios with full configurations for common use cases	field-validation-examples.md
Defining Actions	Combine validation with Show/Hide, Required, and other actions for complete form control	defining-actions.md
Defining Rule Conditions	Master conditions to control when validations apply and build sophisticated rules	defining-rule-conditions.md

tip

Ready to get started? Create your first validation rule by navigating to Project Settings → Formify → Select a field → Validation tab → Add Rule. Start with simple presence or threshold validations, then expand to more sophisticated cross-field and conditional validations as you get comfortable.