Going Beyond Native Jira
Jira's native screen configuration provides basic field layout and required field settings. While this works for simple scenarios, it quickly becomes limiting when you need context-aware field behavior. Formify extends native Jira capabilities to give you the flexibility modern teams need.
What Native Jira Screen Configuration Offers
Jira's standard screen management lets you:
- Add or remove fields from screens
- Mark fields as required or optional
- Create different screen schemes for different projects
- Use different screens for create, view, and edit operations
This works well when your requirements are static - when the same fields should always be visible and the same fields should always be required, regardless of context.
Where Native Configuration Falls Short
Problem 1: Long Forms with Irrelevant Fields
The native approach: Include all possible fields on the screen since you can't show them conditionally.
The result: Users scroll through long forms filled with fields that don't apply to their current task. A Bug report form includes Feature-specific fields. An internal task shows customer-facing fields. Users get overwhelmed, adoption suffers, and data quality drops because people rush through forms or skip optional fields.
What Formify adds: Progressive disclosure - show fields only when relevant based on issue type, project, priority, or the values of other fields such as text, number, user, label and option fields.
Example: Native Jira can show "Steps to Reproduce" only for Bugs, but only by giving Bugs their own screen through an issue type screen scheme, and every such split is another screen to maintain. It can't show the field only when another field has a certain value, such as Priority = Highest. Formify does both with one rule on the field.
Problem 2: No Context-Aware Validation
The native approach: Fields are either always required or always optional.
The result: You can't enforce "Root Cause is required for high-priority incidents" - you have to make it required for all incidents (annoying for low-priority items) or never required (losing data quality on critical issues). Teams resort to training, documentation, or manual checking to enforce conditional requirements.
What Formify adds: Conditional required fields based on the value of text, number, user, priority, issue type, label and option fields (select lists, radio buttons, multi-select lists, checkboxes), on issue status, or on the user's groups, roles and permissions.
Example: Native Jira can't require "Business Justification" only when a "Cost Band" select list is set to "Over 10,000". Formify can make fields required based on values in other fields, issue status, user role, or several of these together.
Problem 3: Manual Data Entry for Repetitive Values
The native approach: Use field defaults or ask users to fill everything manually.
The result: Users repeatedly enter the same values (like the same labels for one bug type, or Assignee based on priority). Default values help but don't adapt to context - a default applies to all issues, not just relevant ones. Teams waste time on data entry instead of solving problems.
What Formify adds: Context-aware field pre-filling and computed values, including date calculations and field references.
Example: Set Assignee to the backend lead when Issue Type = "Backend Bug" and to the frontend lead for frontend bugs, right in the create dialog. Jira's own default assignee is set per project or per component, not per issue type. Formify sets values based on context and can even compute dates like "next business day" or "Monday next week."
Problem 4: Can't Limit Dropdown Options Conditionally
The native approach: All options in select fields are always visible to all users.
The result: Priority dropdowns show P1-P5 for all issue types, even when only P1-P2 make sense for incidents. Users select inappropriate values, requiring cleanup. Select lists include deprecated options users shouldn't choose. Long dropdown lists slow down selection and increase errors.
What Formify adds: Conditional option visibility - show only relevant choices based on context.
Example: Native Jira can't show only "Critical" and "High" priorities for Bug issues while showing all priorities for Tasks. All issue types see all options. Formify filters options based on issue type, project, status, the values of other fields, or the user's groups and roles.
Problem 5: No Role-Based Field Visibility
The native approach: All users with "Edit Issues" permission see all fields on the screen.
The result: You can't keep internal fields (like budget codes, contract details, or triage notes) off the forms of contractors or external contributors while showing them to internal staff. Everyone works through the same long form, or you create separate projects with different screens - a management nightmare.
What Formify adds: User-based conditions that show/hide fields based on group membership, project role, or permissions. This shapes the form; for data some users must not see at all, see Data security below.
Problem 6: Static Field Labels and Help Text
The native approach: Field names and descriptions are the same in all contexts.
The result: Generic labels like "Description" don't guide users toward providing the right information. Bug reports need "Steps to Reproduce" while features need "User Story" - but the same field serves both purposes with a generic label that doesn't help either audience.
What Formify adds: Context-aware field labels and descriptions that change based on issue type, status, or other conditions.
Problem 7: Can't Lock a Single Field Conditionally
The native approach: Take the field off the Edit screen, or add a property to a workflow status. Field configurations (field schemes on newer sites) can hide a field or make it required, but they have no read-only setting.
The result: Neither locks one field in one situation. A field off the Edit screen is read-only in every status and for everyone, and bulk edit and the REST API can still change it. A status property such as jira.issue.editable or jira.permission.edit.group works per status and can keep one group editing, but it locks the whole work item, not one field. So you can't lock only "Fix Versions" once the work item is Done, or let only Release Managers change that one field.
What Formify adds: Read-only rules on a single field, with conditions on status, group, role, permission or other field values.
Side-by-Side Comparison
| Requirement | Native Jira | Formify |
|---|---|---|
| Show field only for specific issue types | Create separate screen schemes | Single rule with condition |
| Require field only when priority is high | Can't do - always required or never required | Conditional required rule |
| Validate Story Points > 0 with custom error message | Can't validate thresholds or customize messages | 15+ validation types with custom messages |
| Ensure End Date is after Start Date | No cross-field validation | Cross-field date consistency validation |
| Auto-fill assignee based on issue type | Default assignee is per project or component | Set value based on conditions |
| Show "Root Cause" only to managers | Can't do - same fields for all users | User-based condition |
| Hide deprecated priority options | Options always visible | Limit options based on context |
| Lock one field when status = Done | Status properties lock the whole work item | Make fields read-only conditionally |
| Change "Description" label to "Steps to Reproduce" for bugs | Can't change labels conditionally | Change label based on issue type |
| Set due date to "next business day" automatically | Can't compute dates | Smart Values with date functions |
What Formify Doesn't Replace
Formify extends native Jira - it doesn't replace it. You'll still use Jira's screen configuration for:
Basic field layout: Adding fields to screens, organizing field order, creating screen schemes - all handled by native Jira.
Always-visible, always-required fields: If a field should be visible and required in all contexts, use native required field settings. No need for a rule.
Data security: Jira Cloud has no permissions for individual fields, and Formify rules work in the Jira interface only. If certain users must not see some data at all, restrict access to the work item or the project with Jira permissions.
Workflow transitions: Formify works on screens, not workflow logic. Use Jira workflows and validators for transition rules.
Best practice: Use native Jira for static configuration (layout, always-required fields) and Formify for conditional behavior (show/hide based on context, conditional required, dynamic values).
Competitive Advantage: Comprehensive Condition Types
Many field behavior apps on the Atlassian Marketplace focus exclusively on field-based conditions - showing or requiring fields based on values in other fields.
Formify goes further with three types of conditions:
1. Field-Based Conditions
Like competitors: trigger rules based on field values.
- "Hide field A when field B = X"
- "Require field C when field D contains Y"
2. Context-Based Conditions
Unique to Formify: Trigger rules based on project, issue type, or status.
- "Hide field only in Project X"
- "Require field only for Bug issue types"
- "Lock field when status = Done"
3. User-Based Conditions
Unique to Formify: Trigger rules based on who is viewing the form.
- "Hide field from users outside the Managers group"
- "Require field only for users with Administrator role"
- "Lock field for everyone except Release Managers"
Why this matters: You can create rules like "In the Customer Platform project, for Bug issues, when Priority is Critical, and user is in Developers group, require Root Cause Analysis field." No competitor offers this level of targeting.
When to Use Each Approach
Use Native Jira When:
- Field should always be visible on the screen
- Field should always be required (or always optional)
- Field layout is simple and doesn't vary by context
- You're setting up basic screen schemes
Use Formify When:
- Field visibility depends on other field values, issue type, status, or user
- Fields should be required only in specific contexts
- You need to pre-fill values based on context
- You want to limit dropdown options conditionally
- You need role-based field visibility
- You want to lock fields based on status or role
- You need to compute field values (dates, field references, expressions)
Use Both Together (Recommended):
- Native Jira defines the base screen layout and always-required fields
- Formify adds conditional behavior on top
- This combination gives you the best of both worlds: simplicity for static needs, power for dynamic requirements
Next Steps
Ready to see Formify in action?
- Start using it: Jump to Quick Start Guide to create your first rule in under 10 minutes
- Learn the concepts: Read Key Concepts to understand how rules, conditions, and actions work
- See examples: Explore Use Cases & Examples for ready-to-use configurations
Already convinced? Begin with Installation & Setup.