# Key Features

Dynamic Screen Rules 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.

{% tabs %}
{% tab title="Show/Hide Fields" %}
**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.

{% hint style="info" %}
**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.
{% endhint %}
{% endtab %}

{% tab title="Required Fields" %}
**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 estimated cost exceeds threshold
* 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.

{% hint style="success" %}
**Smart validation:** Users only see red asterisks when fields are actually needed, reducing form fatigue.
{% endhint %}
{% endtab %}

{% tab title="Lock Fields" %}
**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.

{% hint style="warning" %}
Fields locked on the Global Issue Create screen will be read-only but visible. On the Issue View screen, empty read-only fields are automatically hidden by Jira.
{% endhint %}
{% endtab %}

{% tab title="Set Values" %}
**Auto-fill field values**

Pre-fill or compute field values to reduce manual work and ensure consistency.

**What you can do:**

* Auto-populate Component based on issue type or project
* Set default Assignee based on priority or category
* Pre-fill dates, labels, or custom field values
* Copy values from one field to another

**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.

{% hint style="info" %}
Use [Smart Values](https://teranoapps.gitbook.io/dynamic-screen-rules/configuration-guide/using-smart-values) to compute dynamic values like "next Monday" or "Due Date - 2 business days".
{% endhint %}
{% endtab %}

{% tab title="Change Labels" %}
**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.
{% endtab %}

{% tab title="Limit Options" %}
**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 components based on project or issue type
* Hide deprecated resolutions or statuses
* Filter versions, labels, 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.

{% hint style="success" %}
**Prevent errors before they happen:** Invalid options simply don't appear, making it impossible to select wrong values.
{% endhint %}
{% endtab %}
{% endtabs %}

***

## Multiple Condition Types

Rules trigger based on comprehensive conditions - not just field values, but also context and user identity.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Field-Based Conditions</strong></td><td>Trigger rules based on values in other fields on the form. Supports operators like equals, contains, greater than, is empty, and more. Works with text, select, number, date, checkbox, and custom fields.</td><td><a href="../configuration-guide/defining-rule-conditions">defining-rule-conditions</a></td></tr><tr><td><strong>Context-Based Conditions</strong></td><td>Trigger based on project, issue type, or status - the context of the issue itself. Apply rules only in specific projects, different behavior for different issue types, or lock fields based on workflow stage.</td><td><a href="../configuration-guide/defining-rule-conditions">defining-rule-conditions</a></td></tr><tr><td><strong>User-Based Conditions</strong></td><td>Trigger based on who is filling out the form - their groups, roles, or permissions. Show sensitive fields only to authorized users or provide role-appropriate forms.</td><td><a href="../configuration-guide/defining-rule-conditions">defining-rule-conditions</a></td></tr></tbody></table>

{% hint style="success" %}
**Competitive advantage:** Unlike competitors that focus only on field values, Dynamic Screen Rules offers field-based AND context-based AND user-based conditions, giving you complete control over when rules apply.
{% endhint %}

### Examples by Condition Type

{% tabs %}
{% tab title="Field-Based" %}
**Show "Database Schema" when Component contains "Backend"**

* **Condition:** Component contains "Backend" AND Issue Type equals "Technical Task"
* **Action:** Show "Database Schema" field
* **Use case:** Technical fields appear only for backend work

**Supported operators:**

* Equals, not equals
* Contains, doesn't contain
* Is empty, is not empty
* Greater than, less than
* In list, not in list

**Supported field types:** Text, select, multi-select, number, date, checkbox, user picker, and most custom fields.
{% endtab %}

{% tab title="Context-Based" %}
**Require "Release Notes" in production projects**

* **Condition:** Project = "Customer Platform" AND Issue Type = "Feature" AND Status = "Ready for Release"
* **Action:** Require "Release Notes" field
* **Use case:** Ensure documentation before releasing customer-facing features

**What you can filter on:**

* **Project** - Apply rules only in specific projects
* **Issue Type** - Different behavior for Bugs vs Stories vs Epics
* **Status** - Lock or show fields based on workflow stage
  {% endtab %}

{% tab title="User-Based" %}
**Show financial fields to Finance team only**

* **Condition:** User in group "Finance Team"
* **Action:** Show "Budget Information" field
* **Use case:** Protect sensitive data from unauthorized access

**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
  {% endtab %}

{% tab title="Combined" %}
**Complex multi-condition rules**

Mix and match condition types using AND/OR logic to create sophisticated rules.

**How it works:**

* Multiple conditions within the same type have **OR** relationship
* Multiple condition types have **AND** relationship

**Example:** Show "Executive Summary" field when:

* (Priority = High **OR** Priority = Critical) **AND**
* (User in Group "Managers")

**Result:** Only managers see the Executive Summary field, and only for high-priority issues.
{% endtab %}
{% endtabs %}

***

## 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

\[SCREENSHOT: Validation types grid showing smart filtering]

{% hint style="success" %}
**Competitive advantage:** Unlike Jira's basic required fields or workflow validators, Dynamic Screen Rules provides 15+ validation types with conditional logic, custom error messages, and real-time feedback—all without writing Groovy scripts or purchasing ScriptRunner.
{% endhint %}

### Examples by Validation Type

{% tabs %}
{% tab title="Date Validations" %}
**Enforce SLA deadlines automatically**

Control when dates can be set based on business rules and SLA requirements.

**What you can do:**

* Set Due Date minimum 2 hours from now for Critical tickets
* 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.

{% hint style="info" %}
**Example:** Support team enforces 2-hour minimum lead time on Critical tickets. Users see validation error immediately if they try to set Due Date too soon, ensuring adequate time for triage and assignment.
{% endhint %}
{% endtab %}

{% tab title="Number Validations" %}
**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.

{% hint style="success" %}
**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.
{% endhint %}
{% endtab %}

{% tab title="Text Validations" %}
**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 in descriptions (e.g., "JIRA-" ticket reference)
* 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.

{% hint style="info" %}
**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.
{% endhint %}
{% endtab %}

{% tab title="Cross-Field Validations" %}
**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.

{% hint style="success" %}
**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.
{% endhint %}
{% endtab %}

{% tab title="Presence Validations" %}
**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
* Ensure Business Justification for features exceeding $10k budget
* 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.

{% hint style="info" %}
**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.
{% endhint %}
{% endtab %}
{% endtabs %}

### 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     |

{% hint style="info" %}
**Learn more:** See [Defining Field Validations](https://teranoapps.gitbook.io/dynamic-screen-rules/configuration-guide/defining-field-validations) for complete documentation of all 15 validation types, practical examples, and configuration guides.
{% endhint %}

***

## Smart Values - Computed Field Values

Go beyond static values with expressions that calculate field values automatically.

<details>

<summary><strong>Date Math</strong> - Set dates relative to today or other date fields</summary>

Automatically calculate dates without manual input. Perfect for SLAs and deadlines.

**Examples:**

* Set Due Date = `next business day`
* Set Start Date = `next Monday`
* Set Review Date = `today + 7 days`
* Set Deadline = `Due Date - 2 business days`

**Business value:** Consistent SLA handling. No manual date calculations. Dates automatically adjust based on when the issue is created.

{% hint style="info" %}
Date math respects business days and weekends, ensuring realistic deadlines.
{% endhint %}

</details>

<details>

<summary><strong>Field References</strong> - Copy or derive values from other fields</summary>

Keep related fields in sync automatically. Reduce manual data entry and copy-paste errors.

**Examples:**

* Set Summary = `copy from Parent issue`
* Set Component = `same as Linked Issue component`
* Set Custom Field A = `value from Custom Field B`

**Business value:** Ensure related fields stay in sync. Reduce errors from manual copying.

**Common use cases:**

* Copy epic details to child stories
* Inherit team assignments from parent tasks
* Sync related custom fields across linked issues

</details>

<details>

<summary><strong>Conditional Expressions</strong> - Calculate values based on logic</summary>

Implement business rules directly in forms. Make smart decisions based on field values.

**Examples:**

* `If Priority = High, set Assignee = Team Lead, otherwise leave empty`
* `If Story Points > 5, set flag = 'Needs Breakdown'`
* `Set label based on combination of project and issue type`

**Business value:** Implement business logic directly in forms. Complex decision trees become simple automated rules.

**Advanced patterns:**

* Multi-level conditionals (if-then-else chains)
* Calculations based on multiple fields
* Dynamic assignments based on workload

</details>

{% hint style="info" %}
Smart Values use an expression language similar to Jira Automation's smart values. Learn more in [Using Smart Values](https://teranoapps.gitbook.io/dynamic-screen-rules/configuration-guide/using-smart-values).
{% endhint %}

***

## Multiple Screens Support

Rules work across three key areas of Jira where users interact with fields.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Global Issue Create</strong></td><td><strong>All actions supported</strong><br><br>The dialog that appears when creating new issues. Perfect for progressive disclosure, pre-filling values, dynamic required fields, and cleaning up dropdown options.</td><td><a href="../understanding-rules/screens-and-contexts">screens-and-contexts</a></td></tr><tr><td><strong>Issue View</strong></td><td><strong>Most actions supported</strong><br><br>The issue detail page for viewing and editing existing issues. Ideal for locking fields based on status, role-based visibility, and context-aware labels.</td><td><a href="../understanding-rules/screens-and-contexts">screens-and-contexts</a></td></tr><tr><td><strong>Issue Transition</strong></td><td><strong>Most actions supported</strong><br><br>Status transition dialogs when moving issues through workflow. Best for transition-specific validation and ensuring data completeness at workflow gates.</td><td><a href="../understanding-rules/screens-and-contexts">screens-and-contexts</a></td></tr></tbody></table>

### Common Use Cases by Screen

{% tabs %}
{% tab title="Global Issue Create" %}
**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 Component 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.
{% endtab %}

{% tab title="Issue View" %}
**Perfect for protecting data 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** - Show financial fields only to Finance team
* **Setting values when fields change** - Auto-update labels 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 all fields except "Resolution" and "Time Spent", preventing accidental edits to closed work.
{% endtab %}

{% tab title="Issue Transition" %}
**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** - Show "Deployment Notes" only when transitioning to "Deploy"
* **Pre-filling resolution fields** - Auto-fill "Resolved" and "Fix Versions" on close
* **Ensuring data completeness** - Require all necessary fields before status change

**Example:** When transitioning from "In Progress" to "Done", require "Resolution", "Time Spent", and "Work Log" fields, ensuring complete closure documentation.
{% endtab %}
{% endtabs %}

{% hint style="warning" %}
Some field types have limited support on certain screens due to Atlassian's UI Modifications API limitations. See [Field Support & Limitations](https://teranoapps.gitbook.io/dynamic-screen-rules/field-support-and-limitations/supported-field-types) for details.
{% endhint %}

***

## Scoping and Targeting

Control exactly where rules apply for precise field behavior.

{% columns %}
{% column %}
**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

{% hint style="success" %}
**Project isolation:** Changes in one project never break another. Each team gets exactly the form behavior they need.
{% endhint %}
{% endcolumn %}

{% column %}
**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

{% hint style="info" %}
**One size doesn't fit all:** Bugs need different fields than feature requests. Configure accordingly.
{% endhint %}
{% endcolumn %}
{% endcolumns %}

### 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.

{% hint style="success" %}
**Surgical precision:** Target exactly the scenarios that need special handling without affecting normal workflows.
{% endhint %}

***

## Real-Time Execution

Rules evaluate instantly as users interact with forms, providing immediate feedback.

{% stepper %}
{% step %}
**Screen Loads**

Rules evaluate initial conditions and apply actions immediately. Fields appear, disappear, or pre-fill based on default values.
{% endstep %}

{% step %}
**User Makes Changes**

As users fill the form and change field values, rules continuously re-evaluate in the background.
{% endstep %}

{% step %}
**Actions Update Instantly**

When conditions are met or no longer met, actions apply or reverse immediately - no page refresh needed.
{% endstep %}
{% endstepper %}

**Business value:**

{% hint style="success" %}
**Smooth user experience** - No page refreshes or delays. Forms respond instantly to user input.
{% endhint %}

{% hint style="info" %}
**Immediate feedback** - Users know instantly if they need to fill additional fields. Context-aware forms adapt as users provide information.
{% endhint %}

**Example in action:** User creates a Bug issue. Initially only Summary and Description are visible. 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 Dynamic Screen Rules can do, choose your path:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>See How It Compares</strong></td><td>Understand what you can't do with standard Jira configuration and how Dynamic Screen Rules goes beyond native capabilities.</td><td><a href="going-beyond-native-jira">going-beyond-native-jira</a></td></tr><tr><td><strong>Quick Start Guide</strong></td><td>Create your first rule in under 10 minutes with our step-by-step tutorial. Perfect for hands-on learners.</td><td><a href="../getting-started/quick-start-guide">quick-start-guide</a></td></tr><tr><td><strong>Use Cases &#x26; Examples</strong></td><td>Browse ready-to-use configurations for common scenarios like progressive disclosure, dynamic required fields, and role-based visibility.</td><td><a href="../use-cases-and-examples/progressive-disclosure">progressive-disclosure</a></td></tr><tr><td><strong>Installation &#x26; Setup</strong></td><td>Not installed yet? Start here to add Dynamic Screen Rules to your Jira instance.</td><td><a href="../getting-started/installation-and-setup">installation-and-setup</a></td></tr></tbody></table>