Conditions in Approval Path
Overview
The “Conditions” feature allows you the ability to establish criteria using https://developer.atlassian.com/cloud/jira/platform/jira-expressions/. The chosen expression is evaluated by the Jira REST API based on the selected condition evaluator. These conditions serve as qualifiers for either generating an approval or incorporating a step into it.
When the criteria are satisfied, approval is created, or the assigned step seamlessly integrates into the approval process. Conversely, if the conditions aren't met or an error arises during assessment, approval creation fails, or the step is omitted from the flow.
Use Cases
Adding conditions to approval steps using Jira expressions offers a flexible way to manage your project workflows. Here are some interesting ideas for conditions you might consider:
Type | Description |
|---|---|
Work item (issue) Priority-Based Approval | Triggers an approval step only if the work item’s priority meets or exceeds a defined threshold (e.g., only work items marked as High or Critical require approval). |
Project Phase Dependency | Initiates the approval process only during specific phases of the project (e.g., Development or Testing, but not Planning). |
Time-Based Conditions | Requires approval if a work item remains unresolved or unattended for a specified period, signaling that it may need escalated attention. |
User Role or Group Check | Activates approval steps based on the reporter's or assignee’s role or group membership, ensuring only relevant personnel trigger approvals. |
Work item Type Specific Conditions | Differentiates approval logic based on work item type (e.g., Bug, Feature Request, Task), allowing unique workflows per type. |
Budget Constraints | Requires approval when the estimated cost or budget impact of a work item exceeds a pre-defined threshold. |
Dependency on Other Work items | Conditions approvals on the status of related work items (e.g., blocking work item must be resolved before approval can proceed). |
Customer Impact Analysis | Triggers mandatory approval if the work item is marked as having high customer impact, ensuring adequate review before action. |
Change in Work Item Severity | Initiates approval if a work item’s severity level increases, indicating potential escalation or risk. |
Compliance Check | Makes approval conditional on whether the work item complies with internal or external standards, especially in regulated industries. |
Each of these conditions can be tailored and combined to fit the specific needs of your project, ensuring that the approval process is both efficient and effective.
How to Start
Global
Navigate to the "Apps" dropdown menu on the side panel in Jira and click Approval Path.
Space
Navigate to the desired project, then select Approval Path on the top panel within the project.
Creating a Condition Rule
Click Conditions tab → Create button
Name your Condition rule.
Add Jira Expression: Condition will only be executed if the expression returns a logical value. The condition is met when the expression results are true; otherwise, it will not be met.
Add Condition Evaluator: The chosen expression is evaluated by the Jira REST API based on the selected condition evaluator. Jira expression will be evaluated as:
Current User - User who starts the approval path on the work item / using API Key/ using a workflow condition
Selected User - User selected in condition
Work item field User - User from selected work item field (field value must be set)
Select a Project to limit the condition to specific projects. (optional)
Message customization: Put a message to show when the condition evaluation fails.
Put the work item key for the test.
Condition verification
You can specify the key of a specific work item to verify the condition expression for that particular work item.
Click the ‘Test’ button to check your expression. You'll find details below indicating whether the expression is met, not met, or if an error is encountered, the returned result is not of type boolean.
Expression results
Example: How It Looks
This example explains how to configure a condition that restricts the approval process to specific work item types. Assume there is a project containing various types of Jira work items (e.g., Story, Task, Bug). The objective is to initiate the approval process only when the work item type is "Bug".
After entering the appropriate Jira expression and running a test, the following behavior can be observed:
When tested with a work item of type Bug, the condition is satisfied.
When tested with any other work item type, the condition is not satisfied.
Approval Path Condition
Approval Step Condition
Once chosen, the step will be included in the approval workflow only when the condition is met. Conversely, if the condition is not fulfilled or an error occurs during the evaluation of the condition, the step will be excluded from the approval process.
Managing Condition Rules
You can filter conditions by name or project.
All Condition rules are listed here. There are some actions available for each of them
Edit: You can configure the condition
History and Usage tab: see the history of edits
Duplicating: Use the duplicate option to create a new condition based on an existing one, saving time and ensuring consistency in configurations.
Archiving: If a condition is no longer needed, you can archive it for future reference. Archived conditions can only be viewed for history and usage with pre-archive configurations. Note that condition rules cannot be deleted, only archived.
Archived conditions are not applied to the approval path
Filtering and Sorting
Use the filter option to refine your search by selecting spaces or conditions. Enable or disable shoving globally available conditions.
Viewing Active Conditions
On the Conditions tab in global or project settings, users can see a list view. They may opt to view only active conditions, which show records that are not archived.