Automate processes outside of Jira Workflows with this new JMWE for Jira Cloud feature
If you've ever configured a Jira workflow, you know that regular workflow post-functions run on transitions - that is, when an issue transitions from one status to another. Let's say an issue transitions from OPEN to IN PROGRESS. As part of a workflow transition, many rules can be set up to automate processes.
Jira Misc Workflow Extensions (JMWE) for Jira Cloud includes dozens of configurable workflow post-functions that can enable a virtually unlimited number of use cases. However, what if important issue updates take place outside of status changes - without a transition taking place? That's where our new powerful Event-based Actions come in.
Event-based Actions let you run any of the JMWE post-functions (or sequences of post-functions) outside of Jira workflows using these triggers:
- Issue Field Value Change
- Issue Commented
- Issue Updated
- Issue Created & Issue Transitioned
For example, when a user updates an issue or modifies certain fields, it can trigger a rule to:
- Synchronize issues, i.e., copy content from parent issue to child
- Perform calculations, i.e., instantly calculate the value of fields from other fields:
Viewing time 2 min 15 sec
- Validate field changes, i.e., check the value of fields against the requirement and show guided messages to users:
Viewing time 2 min 29 sec
- And do so much more - see many examples below!
Even if you already use Jira's built-in automation rules to cover some (not all!) of these needs, you can still benefit greatly from using JMWE's new Event-based Actions.
JMWE's Event-based Actions vs. native Jira Automation rules
While many automations outside of workflows can be done using Jira's built-in automation features, JMWE delivers the following advantages:
- Scale. JMWE allows you to run these Event-based Actions across an unlimited number of projects or globally, while Jira Cloud Standard limits you to a tiny number - only 500 total per month - of multi-project and global rule executions.
- Depth. You can automate actions using any of JMWE's post-functions, and since they are powered by our simplified scripting options, you can set up much more advanced rules… and we mean much more!
- Rule attribution. Built-in automation rules always run on behalf of the Automation "app user" - meaning their actions will appear under that Automation user, not an actual user. In JMWE's case, you have the option to run a rule on behalf of an actual user (such as the current user).
Here are some ideas of how to use Event-based Actions
"Issue field value changed" event
This event triggers an action when an issue field value changes. All Jira native and custom fields are supported by this trigger.
Use cases include:
- When a support request receives a low customer satisfaction rating, email a notification to a manager to help keep track of performance;
- Send an email to the Reporter when priority changes to high to keep them informed;
- If a field changes in a parent issue, then update the same field in all sub-tasks to keep data between issues synchronized;
- If the Epic due date changes, update the due date on issues in the Epic and send an email to the Reporter to keep them updated;
- If the project changes, reassign the issue to another person on a team;
- Calculate the value of a field (i.e., project cost) based on other fields (i.e., hours spent * cost per hour) and display it in a read-only field;
- Validate input when a user changes a field, and display an in-app message when the input doesn't follow the required format to alert the user. Even better - automatically revert back to the previous value;
- If the priority field changed to High, display an in-app custom message to the user instructing them to provide reasoning for the change in the comments section;
- And many more!
"Issue commented" event
This event triggers an action when a comment is added to an issue.
Use cases include:
- Keep comments synchronized between issues. For example if a comment is added to a Service Desk request, add the same comment to all linked Jira Software issues;
- Automatically transition an issue when the customer adds a new comment;
- When a comment is added to a closed issue, reopen the issue and send a notification email to the last assignee;
- For true Jira trail-blazers, try advanced solutions such as identifying specific keywords in the comment to find business-impactful data, such as customer feedback, warning signs, etc.;
- And many more!
"Issue updated" event
This event triggers an action when an issue is updated.
Use cases include:
- When issues with specific types such as bugs with high severity issues are updated, send an email notification to a team lead;
- For true Jira trail-blazers, try synchronizing the issue with external systems;
- And more!
"Issue Created" and "Issue Transitioned" events
These events trigger an action when an issue has either been created or transitioned.
The best way to automate Jira workflows is to add post-functions directly to your workflows. These post-functions can be added to transitions between statuses or upon issue creation. Often, however, businesses can benefit from running some important global rules. For example, you might want to save the date and author of a Close transition across all workflows. This would require adding post-functions on every transition that closes an issue, on every workflow. With JMWE's new event-based actions, you can configure post-functions outside of workflows and apply them to any and all projects.
Note: While this type of automation can be achieved using built-in Jira automation features, in Jira Standard, you are likely to reach the limit of executions within mere hours.