Key Features
Formify brings sophisticated field behavior to Jira screens without requiring custom development. Here's what you can do with the app.
Rule-Based Field Behavior
Control how fields appear and behave on your Jira screens using conditional rules that execute in real-time as users interact with forms.
- Show/Hide Fields
- Required Fields
- Lock Fields
- Set Values
- Change Labels
- Limit Options
Display fields only when relevant
Show or hide fields based on context, keeping forms clean and focused.
What you can do:
- Show "Root Cause Analysis" field only for high-priority bugs
- Display "Customer Impact" section only when issue affects external users
- Hide internal fields from external contributors
- Reveal additional detail fields based on initial selections
Business value: Shorter, cleaner forms that don't overwhelm users with irrelevant fields. Users see only what they need, when they need it.
Example: A support team shows "Escalation Contact" field only when Priority is set to Critical, keeping the form simple for routine tickets while ensuring critical issues get proper attention. The rule hides the field when Priority isn't Critical: a field on the screen is visible unless a rule hides it.
Enforce validation conditionally
Make fields required only in specific situations, not universally.
What you can do:
- Require "Affected Versions" only for Bug issue types
- Make "Business Justification" mandatory when the "Cost band" select list is set to its highest band
- Enforce "Root Cause" field when closing high-priority incidents
- Require approval fields only for changes affecting production
Business value: Collect complete information when it matters without burdening users with unnecessary required fields. Validation happens at the right time, in the right context.
Smart validation: Users only see red asterisks when fields are actually needed, reducing form fatigue.
Prevent accidental edits
Make fields read-only based on status, role, or other conditions.
What you can do:
- Lock "Fix Versions" when issue status isn't "In Development"
- Make fields read-only for users outside specific groups
- Prevent editing of critical fields after approval
- Protect fields from modification during certain workflow stages
Business value: Implement guardrails that prevent common mistakes without completely blocking users. Protect data integrity while maintaining flexibility.
Locked fields stay visible but can't be edited, on Global Issue Create, Issue Transition and Issue View. On the Issue View screen, locks work in Jira Software projects, and empty read-only fields are automatically hidden by Jira.
Auto-fill field values
Pre-fill or compute field values to reduce manual work and ensure consistency.
What you can do:
- Auto-populate Labels or Priority based on issue type
- Set default Assignee based on priority or category
- Pre-fill dates, labels, or custom field values
- Copy a date or a user from another field on the form
Business value: Eliminate repetitive data entry. Users spend less time filling forms and more time on meaningful work. Consistent data across issues improves reporting accuracy.
Use Smart Values to compute dynamic values like "next business day" or "2 business days before the Due Date".
Context-aware field labeling
Provide labels and help text that adapt to the situation.
What you can do:
- Change "Description" label to "Steps to Reproduce" for Bug issues
- Update field descriptions based on issue type or status
- Provide different guidance for different user groups
- Clarify field meaning in specific contexts
Business value: Guide users with relevant instructions. The same field can serve different purposes in different contexts with appropriate labeling.
Clean up dropdown selections
Show only relevant options in select fields, preventing invalid selections.
What you can do:
- Show only P1/P2 priorities for Bug issues
- Limit issue types based on the user's group or role
- Hide deprecated options of a select list
- Filter Fix Versions or custom field options
Business value: Users can't select inappropriate values because they're not visible. Fewer mistakes mean less cleanup work and better data quality.
Prevent errors before they happen: Invalid options simply don't appear, making it impossible to select wrong values.
Multiple Condition Types
Rules trigger based on comprehensive conditions - not just field values, but also context and user identity.
Competitive advantage: Unlike competitors that focus only on field values, Formify offers field-based AND context-based AND user-based conditions, giving you complete control over when rules apply.
Examples by Condition Type
- Field-Based
- Context-Based
- User-Based
- Combined
Show "Database Schema" only when Team equals "Backend"
- Condition: Team (select list) not equals "Backend", on the "Technical Task" work type
- Action: Hide "Database Schema" field
- Use case: Technical fields appear only for backend work (an empty Team also matches "not equals", so the field stays hidden until Backend is picked)
Supported operators (depending on the field type):
- Equals, not equals
- Contains
- Is one of (select lists, radio buttons), contains any of (multi-select lists, checkboxes)
- Is empty, is not empty
Supported field types: Summary, Description, Issue type, Priority, Assignee, Reporter, Labels, and custom single-line text, URL, number, select list, radio buttons, multi-select list and checkboxes fields. See Operators by Field Type.
Require "Release Notes" in production projects
- Where: a Transition rule in the project, on the "Feature" work type
- Condition: Issue status is in status "Ready for Release" (in a transition dialog, the status the work item is leaving)
- Action: Require "Release Notes" field
- Use case: Ensure documentation before releasing customer-facing features
What you can filter on:
- Project - Rules are set up per project, so they apply only where you create them
- Issue Type - Different behavior for Bugs vs Stories vs Epics
- Status - Lock or hide fields based on workflow stage
Show financial fields to Finance team only
- Condition: User is not in group "Finance Team"
- Action: Hide "Budget Information" field
- Use case: Keep the form short for everyone who doesn't fill in budget details
Hiding a field keeps forms relevant; it isn't access control. The value stays readable elsewhere in Jira, for example in search and list views. Users who must not see the data need Jira permissions or issue security levels.
What you can filter on:
- Group membership - e.g., only for "Developers" group
- Project role - e.g., only for "Administrators" role
- Permissions - e.g., only users with "Edit Issues" permission
Complex multi-condition rules
Mix and match condition types, joined with AND or OR.
How it works:
- A rule's conditions are joined by one operator, AND by default
- Switch the rule to OR when any one condition should be enough
- The operator covers all of the rule's conditions, so one rule doesn't mix AND and OR
Example: Hide "Executive Summary" field when:
- Priority not equals Highest OR
- Current user is not in group "Managers"
Result: Only managers see the Executive Summary field, and only for the highest-priority issues.
Field Validation Rules - Data Quality at the Source
Enforce data quality, consistency, and business rules automatically with 15+ validation types that provide immediate feedback. Validate field values in real-time as users type, preventing invalid data from entering your Jira instance.
What you can validate:
- Presence - Required/empty fields based on context
- Dates - SLA deadlines, date consistency, future/past constraints
- Numbers - Thresholds, ranges, positive values, quality gates
- Text - Length requirements, content quality, format validation
- Cross-field - Field comparisons, date sequencing, consistency checks
Key capabilities:
- Smart filtering - Only see validations compatible with field type
- Custom error messages - Guide users with specific, actionable feedback
- Real-time validation - Immediate feedback as users type, not on submit
- Conditional validation - Enforce rules only when relevant based on conditions
- Validation Gate Field - Track validation status for reporting and automation
The Validation Rule form for a date field, listing only the validation types that fit dates.
Competitive advantage: Unlike Jira's basic required fields or workflow validators, Formify provides 15+ validation types with conditional logic, custom error messages, and real-time feedback—all without writing Groovy scripts or purchasing ScriptRunner.
Examples by Validation Type
- Date Validations
- Number Validations
- Text Validations
- Cross-Field Validations
- Presence Validations
Enforce SLA deadlines automatically
Control when dates can be set based on business rules and SLA requirements.
What you can do:
- Require Due Date at least 1 day after today for Critical tickets (on the Create screen)
- Ensure End Date is after Start Date
- Validate dates are within acceptable planning horizon
- Prevent past dates for future-oriented fields
- Require dates at least X days in the future
Business value: SLA compliance without manual oversight. Date consistency across linked fields. Prevent impossible date combinations before they're saved.
Example: Support team requires a Due Date at least one day after today when creating Critical tickets. Users see the validation error immediately if they pick a date too soon, ensuring adequate time for triage and assignment.
Quality gates and threshold enforcement
Validate numeric fields against thresholds, ranges, and business rules.
What you can do:
- Require Story Points > 0 for all Stories
- Ensure Budget values are positive and within range
- Validate time estimates are reasonable (e.g., 1-40 hours)
- Enforce Story Points caps to encourage splitting large Stories
- Prevent zero values where inappropriate
Business value: Prevent invalid numeric data. Enforce business thresholds automatically. Catch unrealistic estimates early.
Example: Product team prevents Stories from entering sprint without estimation by validating Story Points > 0. Combined with maximum validation (< 41), large Stories are caught and split before sprint planning.
Content quality standards
Ensure text fields meet minimum quality standards and format requirements.
What you can do:
- Minimum 15 characters for Incident summaries
- Maximum 100 characters for titles to ensure display consistency
- Require specific keywords or tags (e.g., "[Customer]" in the summary)
- Validate format patterns for consistency
- Prevent placeholder text like "TODO" or "TBD" in production
Business value: Improve data quality for better searchability and reporting. Prevent vague descriptions that slow down triage. Ensure adequate detail for meaningful work.
Example: Support team requires minimum 15-character summaries for Incidents. This prevents single-word summaries like "Bug" or "Error" and ensures meaningful descriptions for triage and reporting.
Consistency across related fields
Validate relationships between fields to maintain data integrity.
What you can do:
- End Date must be after Start Date
- Review Date must be before Release Date
- Compare numeric fields (Budget Actual vs Budget Planned)
- Ensure dependent field values align
- Validate date sequencing across milestones
Business value: Maintain referential integrity. Enforce business policies automatically. Prevent impossible field combinations that cause reporting errors.
Example: Project team validates End Date > Start Date on all Epics. Impossible date ranges are caught immediately during issue creation, preventing timeline errors in roadmaps and Gantt charts.
Context-aware required fields
Replace static required fields with intelligent, conditional validation.
What you can do:
- Require Story Points only for Story issue types
- Make Root Cause required only for high-priority bugs
- Require Business Justification when the Cost Band select list is Over 10,000
- Require Approval Code when bypassing workflow steps
- Make fields required based on status, priority, or user role
Business value: Collect critical information when it matters without burdening users with unnecessary required fields. Forms adapt to context automatically.
Better than native required fields: Native Jira required fields are always required (or never required). Validation rules apply conditionally based on issue type, priority, status, or any other condition, ensuring users only fill what's relevant.
Validation vs. Required Fields
| Feature | Validation Rules | Native Required Fields |
|---|---|---|
| Conditional logic | Yes - based on any condition | No - always required |
| Multiple checks | 15+ validation types | Only "has value" |
| Custom messages | Specific, actionable guidance | Generic "required" message |
| Real-time feedback | As user types | On submit only |
| Cross-field checks | Yes - validate against other fields | No |
| Threshold validation | Yes - dates, numbers, text length | No |
| Format validation | Yes - text contains/not contains patterns | No |
| Validation Gate tracking | Yes - track status in dashboards/workflows | No |
| No coding required | Yes - visual configuration | Yes - checkbox in screen config |
| Best for | Context-aware data quality, thresholds, consistency | Simple always-required fields |
Learn more: See Defining Field Validations for complete documentation of all 15 validation types, practical examples, and configuration guides.
Smart Values - Computed Field Values
Go beyond static values with expressions that calculate field values automatically.
Date Calculations - Set dates relative to today or other date fields
Automatically calculate dates without manual input. Perfect for SLAs and deadlines.
Examples:
- Set Due Date =
{{today().plusBusinessDays(1)}}- the next business day (on the Create screen) - Set Start Date =
{{addWeeks(startOfWeek(), 1)}}- Monday next week - Set Review Date =
{{addDays(today(), 7)}}- 7 days from today - Set Deadline =
{{subtractBusinessDays(field("duedate"), 2)}}- 2 business days before the due date
Business value: Consistent SLA handling. No manual date calculations. Dates automatically adjust based on when the issue is created.
Business day functions skip Saturdays and Sundays, ensuring realistic deadlines.
Field References - Copy values from other fields on the form
Keep related fields in sync automatically. Reduce manual data entry and copy-paste errors.
Examples:
- Set Target Date =
{{field("duedate")}}- copy the Due Date entered on the form - Set Developer =
{{field("assignee")}}- copy the Assignee into a user picker field
Business value: Ensure related fields stay in sync. Reduce errors from manual copying.
When the source field changes on the form, the rule copies the new value.
Current User - Fill in the person working on the form
Examples:
- Set Reporter =
{{currentUser()}} - Set Approved By =
{{currentUser()}}on the transition to Approved
Business value: Record who created, approved or verified work without asking users to pick themselves.
Smart Values work on date, date-time and user fields and on Labels. They have no if() or comparisons: to fill in
different values in different situations, create one Set Field Value rule per value, each with its own conditions.
Smart Values use double curly braces like Jira Automation's smart values, with Formify's own set of functions. Learn more in Using Smart Values.
Multiple Screens Support
Rules work across three key areas of Jira where users interact with fields.
Common Use Cases by Screen
- Global Issue Create
- Issue View
- Issue Transition
Perfect for guiding users during issue creation
Supported actions: Show/hide, required, lock, set value, change labels/descriptions, limit options
Best use cases:
- Progressive disclosure - Show fields only when relevant selections are made
- Pre-filling values - Auto-populate Assignee or Labels based on issue type
- Dynamic required fields - Require "Affected Versions" only for Bugs
- Cleaning dropdowns - Show only P1/P2 priorities for critical issue types
Example: When a user selects Issue Type = "Bug" and Priority = "Critical", automatically show and require the "Root Cause Analysis" field while pre-filling Due Date to next business day.
Perfect for preventing accidental edits and adapting to workflow
Supported actions: Most actions (with some API limitations for certain fields)
Best use cases:
- Locking fields based on status - Make "Fix Versions" read-only when Status = "Done"
- Role-based field visibility - Hide financial fields from everyone outside the Finance team
- Context-aware help text - Change a field's description when priority changes
- Context-aware field labels - Change "Description" to "Resolution Notes" in Done status
Example: When an issue moves to "Done" status, automatically lock Fix Versions, Components and Labels for everyone outside the release team, preventing accidental edits to closed work.
Perfect for enforcing workflow gates
Supported actions: Most actions
Best use cases:
- Transition-specific validation - Require "Test Results" before moving to "Ready for Release"
- Status-based field visibility - Hide "Deployment Notes" unless the work item is leaving "Staging" (on a transition, the Issue status condition checks the status the work item is leaving)
- Pre-filling transition fields - Auto-fill a sign-off date or the user who made the transition
- Ensuring data completeness - Require all necessary fields before status change
Example: When transitioning from "In Progress" to "Done", require "Fix Versions", "Release Notes" and "Test Results" fields, ensuring complete closure documentation.
Some field types have limited support on certain screens due to Atlassian's UI Modifications API limitations. See Field Support & Limitations for details.
Scoping and Targeting
Control exactly where rules apply for precise field behavior.
Per-Project Scoping
Each rule is configured for a specific project, giving you complete control over field behavior without affecting other projects.
What you can do:
- Configure rules that match each project's unique workflow
- Experiment in one project before rolling out
- Maintain different validation rules for different teams
- Keep project configurations independent
Project isolation: Changes in one project never break another. Each team gets exactly the form behavior they need.
Per-Issue-Type Scoping
Rules can target specific issue types (Bug, Story, Epic, custom types).
What you can do:
- Different field behavior for Bugs vs Features vs Tasks
- Issue-type-specific validation and required fields
- Tailored forms for different work types
One size doesn't fit all: Bugs need different fields than feature requests. Configure accordingly.
Combined Scoping - Maximum Precision
Combine project and issue type scoping with field, context, and user conditions for highly targeted rules.
Example rule with combined scoping:
Project: "Customer Platform"
Issue Type: Bug
Condition: Priority = Critical AND User in group "Developers"
Action: Require "Root Cause Analysis" field
Result: Only developers in the Customer Platform project will be required to fill Root Cause Analysis, and only for critical bugs. All other combinations are unaffected.
Surgical precision: Target exactly the scenarios that need special handling without affecting normal workflows.
Real-Time Execution
Rules evaluate instantly as users interact with forms, providing immediate feedback.
Screen Loads
Rules evaluate initial conditions and apply actions immediately. Fields appear, disappear, or pre-fill based on default values.
User Makes Changes
As users fill the form, rules check their conditions again whenever a field used in a condition changes: right away for most fields, when the user leaves Summary or Description, and on the Issue View once the edit is saved. A change made while the rules are still running, for example right after the form opens, is not picked up until the next change.
Actions Update Instantly
When conditions are met or no longer met, actions apply or reverse immediately - no page refresh needed.
Business value:
Smooth user experience - No page refreshes or delays. Forms respond instantly to user input.
Immediate feedback - Users know instantly if they need to fill additional fields. Context-aware forms adapt as users provide information.
Example in action: A rule hides Root Cause on Bugs when Priority not equals "Critical". User creates a Bug issue, and Root Cause isn't there. When they select Priority = "Critical", the Root Cause field appears instantly. When they change Priority to "Low", the field disappears just as quickly. No waiting, no confusion.
Next Steps
Now that you understand what Formify can do, choose your path: