Supported Field Types
Formify works with system fields and custom fields through Atlassian's UI Modifications API. This page lists all supported field types and explains what each field is used for.
Understanding which field types are supported helps you plan rule configurations and know what's possible with Formify.
Jira lets apps change some fields on some screens only. Where a field below lists fewer actions or screens than the rule editor offers, the list below is what Jira applies: a rule outside it saves, but has no effect.
System Fields
System fields are built-in Jira fields available in all projects. Formify supports all major system fields.
Text and Description Fields
| Field Name | Field ID | Description | Common Uses |
|---|---|---|---|
| Summary | summary | Issue title/summary | Pre-fill issue titles, change label, lock |
| Description | description | Issue description (rich text) | Show/hide, require for specific types, change label |
Supported Actions: Show/Hide, Required, Lock, Set Value, Change Label, Change Description
Screens: Jira always requires Summary, so Required doesn't apply to it. On the Issue View, Summary can only be locked, and Change Description doesn't work on Description.
Example Use Case: Require Description for high-priority bugs, hide for simple tasks
Select and Priority Fields
| Field Name | Field ID | Description | Common Uses |
|---|---|---|---|
| Priority | priority | Issue priority level | Limit to P1/P2 for bugs, require for incidents |
| Issue Type | issuetype | Type of issue (Bug, Story, etc.) | Limit available types, pre-select based on project |
| Resolution | resolution | How issue was resolved | Add help text on the Done transition |
| Status | status | Current workflow status | Use in the Issue status condition (can't modify) |
Supported Actions:
- Priority: Show/Hide, Required, Lock, Set Value, Change Label, Change Description, Limit Options (on the Issue View, Change Description doesn't work on Priority)
- Issue Type: Set Value and Limit Options only, on Create and Issue Transition. Jira doesn't let apps hide, require, lock or relabel Issue Type, or change it on the Issue View.
- Resolution: Show/Hide, Lock, Change Label, Change Description, on Issue Transition only. Resolution appears only in transition dialogs, and Jira doesn't let apps make it required.
- Status: no actions; use it in the Issue status condition
Example Use Case: Show only "P1" and "P2" priorities for bugs
User Assignment Fields
| Field Name | Field ID | Description | Common Uses |
|---|---|---|---|
| Assignee | assignee | User assigned to issue | Auto-assign based on priority, require for critical issues |
| Reporter | reporter | User who created issue | Pre-fill with current user, lock to prevent changes |
Supported Actions: Show/Hide, Required, Lock, Set Value, Change Label, Change Description
Example Use Case: Auto-assign critical issues to the team lead, or set Reporter to the person filling in the form with the {{currentUser()}} Smart Value
Multi-Value Fields
| Field Name | Field ID | Description | Common Uses |
|---|---|---|---|
| Labels | labels | Freeform tags | Auto-add labels based on type, require for specific workflows |
| Components | components | Project components | Require component selection, lock after triage |
| Fix Versions | fixVersions | Versions where issue will be fixed | Limit to unreleased versions on a transition, lock after deployment |
| Affects Versions | versions | Versions affected by issue | Require for bugs, hide for other work types |
Supported Actions: Show/Hide, Required, Lock, Set Value (Labels only), Change Label, Change Description
Screens: Components works on Create and the Issue View only; Jira doesn't let apps change it in a transition dialog.
Limit Options Support: Fix Versions supports option limiting on Issue Transition only; Affects Versions, Labels and Components do not
Example Use Case: Limit Fix Versions to unreleased versions in the Done transition dialog
Hierarchy Fields
| Field Name | Field ID | Description | Common Uses |
|---|---|---|---|
| Parent | parent | Parent issue (for subtasks/child issues) | Require parent for subtasks |
Supported Actions: Show/Hide, Required, Lock, Change Label, Change Description
Example Use Case: Require parent issue for all subtasks
Date and Time Fields
| Field Name | Field ID | Description | Common Uses |
|---|---|---|---|
| Due Date | duedate | Issue due date | Set to next business day, require for high-priority |
Supported Actions (Create screen only): Show/Hide, Required, Lock, Set Value (with Smart Values), Change Label, Change Description
Jira doesn't let apps change Due Date in a transition dialog or on the Issue View: rules on Due Date there have no effect, although the editor lets you create them. The one exception is a Must not be empty validation on Due Date in a transition dialog: Jira doesn't give apps the Due Date value there, so the validation always fails and blocks the transition, even when Due Date is filled. Don't add one to a transition.
Example Use Case: Auto-set due date to 3 business days from today using {{today().plusBusinessDays(3)}}
Time Tracking Fields
| Field Name | Field ID | Description | Common Uses |
|---|---|---|---|
| Original Estimate | timeoriginalestimate | Estimated time to complete (seconds) | Require in a transition dialog, hide for simple tasks |
Supported Actions: Show/Hide, Required, Lock, Change Label, Change Description
Screens: Issue View and Issue Transition only: Jira doesn't let apps change Original Estimate in the Create dialog. Required works in transition dialogs only.
Note: Time values are stored in seconds (e.g., 3600 = 1 hour)
Custom Field Types
Custom fields are created by Jira administrators. Formify supports all standard custom field types.
Text Entry Fields
| Field Type | Jira Type ID | Description | Common Uses |
|---|---|---|---|
| Text Field (single line) | textfield | Short text input | Show/hide, require, pre-fill with static text |
| Paragraph (multi-line) | textarea | Long text input | Require for detailed explanations, change label contextually |
| URL Field | url | URL input with validation | Hide for internal bugs, require documentation link |
Supported Actions: Show/Hide, Required, Lock, Set Value (single line and URL fields), Change Label, Change Description
Example Use Case: Require "External Link" URL field when "External Bug" (checkboxes) contains Yes
Select Fields (with Options)
| Field Type | Jira Type ID | Description | Common Uses |
|---|---|---|---|
| Select List (dropdown) | select | Single-choice dropdown | Limit options by context, require selection |
| Radio Buttons | radiobuttons | Single-choice radio buttons | Limit options, require selection |
| Multi-Select | multiselect | Multiple-choice dropdown | Limit available choices, require at least one |
| Checkboxes | multicheckboxes | Multiple-choice checkboxes | Limit options, pre-select common choices |
Supported Actions: Show/Hide, Required, Lock, Set Value (Multi-Select and Checkboxes), Change Label, Change Description, Limit Options
Use in conditions: All four can trigger rules in a Field value condition.
- Select List and Radio Buttons: equals, not equals, is one of, is empty, is not empty
- Multi-Select and Checkboxes: contains, contains any of, is empty, is not empty
- You pick the options from a list. The rule keeps the option itself, not its name, so renaming an option in Jira doesn't break it.
- On Transition and Issue View, a condition can also check one of these fields when it isn't on the screen; it then reads the value saved on the work item. See Fields Not on the Screen.
Example Use Cases: Limit "Environment" select field to show only "Production" and "Staging" for critical bugs. Hide "Please Explain" when "Satisfaction" (select list) not equals Dissatisfied: an empty Satisfaction also matches, so the field stays hidden until Dissatisfied is picked.
User Picker Fields
| Field Type | Jira Type ID | Description | Common Uses |
|---|---|---|---|
| User Picker (single) | userpicker | Select single user | Auto-assign, require approval from specific user |
| Multi User Picker | multiuserpicker | Select multiple users | Require reviewers, pre-fill with team members |
| People (group) | people | Select user with group context | Team assignment, role-based selection |
Supported Actions: Show/Hide, Required, Lock, Set Value (User Picker and Multi User Picker, also with the {{currentUser()}} and {{field("fieldId")}} Smart Values), Change Label, Change Description
Screens: People works on Create and the Issue View only; Jira doesn't let apps change it in a transition dialog.
Example Use Case: Pre-fill "Reviewer" field with current user using the {{currentUser()}} Smart Value
Date and Time Fields
| Field Type | Jira Type ID | Description | Common Uses |
|---|---|---|---|
| Date Picker | datepicker | Date selection (no time) | Set review dates, require completion dates |
| Date Time | datetime | Date and time selection | Schedule deployments, track timestamps |
| Target Start | jpo-custom-field-baseline-start | Advanced Roadmaps start date | Project planning, roadmap dates |
| Target End | jpo-custom-field-baseline-end | Advanced Roadmaps end date | Project planning, roadmap dates |
Supported Actions: Show/Hide, Required, Lock, Set Value (Date Picker and Date Time, also with Smart Values), Change Label, Change Description
Screens: Target Start and Target End work on the Create screen only; Jira doesn't let apps change them in a transition dialog or on the Issue View.
Smart Values Support: Date Picker and Date Time fields take Smart Values like today(), addDays(), plusBusinessDays() and field(). See Using Smart Values.
Example Use Case: Auto-set "Review Date" to 5 business days from today using {{today().plusBusinessDays(5)}}
Number Fields
| Field Type | Jira Type ID | Description | Common Uses |
|---|---|---|---|
| Number Field | float | Numeric input (decimal) | Budgets, cost tracking, scoring |
Supported Actions: Show/Hide, Required, Lock, Set Value, Change Label, Change Description
Story Points: a Story Points field of the Number type works like any number field: in Field value conditions, with Set value and with the number validations. Jira's Story point estimate field isn't a field type Jira lets apps change on these screens, so it doesn't appear in Formify's field list.
Example Use Case: Require "Estimated Cost" when issue type is Feature
Advanced Fields
| Field Type | Jira Type ID | Description | Supported? |
|---|---|---|---|
| Cascading Select | cascadingselect | Two-level dropdown | Supported as a rule's target field; can't be used in conditions |
| Project Picker | project | Select related project | Supported as a rule's target field; can't be used in conditions |
Supported Actions: Show/Hide, Required, Lock, Set Value (Cascading Select), Change Label, Change Description
Set Value on Cascading Select: pick the parent option and, if needed, a child option.
Field Type Categories Summary
By Capability
Fields that can be used in Field value conditions:
- Summary, Description, Issue Type, Priority, Assignee, Reporter, Labels
- Custom fields: Text Field (single line), URL Field, Number Field
- Custom select fields: Select List, Radio Buttons, Multi-Select, Checkboxes
- Status has its own Issue status condition (Issue View and Transition)
- Operators per field type: Operators by Field Type
Fields that support Limit Options:
- Priority, and Issue Type on Create and Issue Transition
- Fix Versions (Issue Transition only)
- All custom select fields (Select List, Radio Buttons, Multi-Select, Checkboxes)
- On the Issue View: Priority and the custom select fields
Fields that support Set Value:
- Summary, Description, Issue Type, Priority, Assignee, Reporter, Labels, Due Date (Create screen only)
- Custom fields: Text Field (single line), URL Field, Number Field, Date Picker, Date Time, User Picker, Multi User Picker, Multi-Select, Checkboxes, Cascading Select
Fields that support Smart Values (Set Value):
- Date fields: Due Date, Date Picker, Date Time (date functions and
field()) - User fields: Assignee, Reporter, User Picker, Multi User Picker (
currentUser()andfield()) - Labels (
field())
Fields with read-only access:
- Status (use it in the Issue status condition; it can't be modified directly - use Jira workflows instead)
Fields that work on some screens only:
- Due Date, Target Start, Target End: Global Issue Create only
- Resolution: Issue Transition only
- Original Estimate: Issue View and Issue Transition
- Components, People: Global Issue Create and Issue View
- Issue Type: Global Issue Create and Issue Transition (Set Value and Limit Options only)
Fields with limited locking:
- Due Date, Target Start and Target End can be locked on Global Issue Create only, and Resolution on Issue Transition only
- Status, Issue Type and Request Type can't be locked on any screen
Fields that support Validation Rules:
- All field types support presence validations (Must not be empty, Must be empty)
- Date fields support date validations (After today, Before today, After/Before field, Date at least X days from today)
- Number fields support number validations (Greater than, Less than, Between, Not zero)
- Text fields support text validations (Min/Max length, Contains, Not contains)
See Validation Compatibility section below for detailed breakdown.
Validation Compatibility by Field Type
Field validation rules enforce data quality and business rules at the point of data entry. Different field types support different validation types based on the data they contain.
Presence Validations (All Field Types)
Supported validations:
- Must not be empty
- Must be empty
Compatible with:
- All system fields (Summary, Description, Priority, Assignee, Reporter, etc.)
- All custom fields (text, select, date, number, user picker, etc.)
Use cases:
- Conditional required fields
- Ensure fields are cleared in certain workflow states
- Context-aware validation
Date Validations
Supported validations:
- Date after today
- Date before today
- Date at least X days from today
- Date after another field (cross-field)
- Date before another field (cross-field)
Compatible field types:
System fields:
- Due Date
Custom fields:
- Date Picker (
datepicker) - Date Time (
datetime) - Target Start (
jpo-custom-field-baseline-start) - Target End (
jpo-custom-field-baseline-end)
Use cases:
- SLA enforcement (Due Date ≥2 hours from now)
- Date sequencing (End Date > Start Date)
- Planning horizon validation (Release Date ≥30 days ahead)
- Prevent past/future dates
Example:
Field: Due Date
Validation: Date at least X days from today
Days: 0 (allows today and future)
Message: "Due Date must be at least 2 hours from now for Critical tickets"
Number Validations
Supported validations:
- Number greater than
- Number less than
- Number between
- Not zero
Compatible field types:
Custom fields:
- Number Field (
float), including a Story Points field of this type
Common use cases:
Use cases:
- Story Points quality gate (> 0, < 41)
- Budget thresholds (> $1000)
- Percentage validation (0-100 range)
- Prevent zero values
Example:
Field: Estimated Budget
Validation: Number greater than
Threshold: 0
Message: "Budget must be greater than 0 to ensure cost tracking"
Text Validations
Supported validations:
- Text minimum length
- Text maximum length
- Must contain text (substring)
- Must not contain text (substring)
Compatible field types:
System fields:
- Summary (
summary) - Description (
description) - ADF text extracted automatically
Custom fields:
- Text Field single-line (
textfield) - Paragraph multi-line (
textarea) - URL Field (
url)
Text extraction:
- Plain text fields: Character count includes all visible characters
- Rich text fields (Description): Text extracted from Atlassian Document Format (ADF), formatting ignored
- Whitespace-only text counts as length 0
Use cases:
- Incident summary quality (≥15 characters)
- Prevent TODO/TBD placeholders
- Require a tag in the summary (such as "[Customer]")
- Enforce brevity (≤100 characters)
Example:
Field: Summary
Validation: Text minimum length
Length: 15
Message: "Summary must be at least 15 characters to ensure meaningful description"
Cross-Field Validations
Cross-field validations compare values between two fields to ensure consistency.
Supported validations:
- Date after another field
- Date before another field
Requirements:
- Both fields must be date fields
- Both fields must have values for validation to apply
- If comparison field is empty, validation passes (fail-safe behavior)
Common patterns:
| Target Field | Validation | Comparison Field | Use Case |
|---|---|---|---|
| End Date | Date after field | Start Date | Ensure valid timeline |
| Review Date | Date before field | Release Date | Review before release |
| Due Date | Date after field | Start Date | Due date after work begins |
| Resolution Date | Date after field | Created Date | Resolved after creation |
Example:
Field: End Date
Validation: Date after another field
Comparison: Start Date
Message: "End Date must be after Start Date to create a valid timeline"
Checking If Your Field Is Supported
Step 1: Identify your field type
- Go to Jira Settings → Issues → Custom Fields
- Find your field and note the "Type" column
Step 2: Match field type to this list
- System fields: Look in System Fields section by field name
- Custom fields: Match the type ID (e.g., "Select List (single choice)" =
select)
Step 3: Verify action support
- Check that the action you want, and the screen you want it on, are listed for that field type
- Special fields (select types) support Limit Options
- Due Date, Date Picker and Date Time fields support Smart Values
- User fields support the
currentUser()Smart Value
If your field isn't listed:
Formify's field list shows only fields of a type Jira lets apps change; some of them can't be changed on every screen (see Field-Specific Limits). Fields such as Sprint, Attachment, Jira's Story point estimate and fields added by other apps don't appear there. Rules on Request type have no effect on any screen.
- Contact support with the field type ID if you're unsure
- Consider using a standard Jira field type instead
Related Pages
Actions documentation:
- Defining Actions - How to configure each action type
Smart Values:
- Using Smart Values - Date calculations and field references
Limitations:
- Screen-Specific Limitations - Which actions work on which screens
- Known Platform Limitations - Atlassian API constraints
Use cases:
- Limiting Dropdown Options - Examples using select fields
- Pre-filling Values - Examples using Smart Values
This list reflects currently supported field types and is updated as Atlassian adds new capabilities to the UI Modifications API.