Automate processes (basic and advanced) to tailor your workflows

Workflows enable you to automate business rules. You can auto-assist users in deciding when one step has been completed successfully so the next step can begin. And Jira is the ultimate workflow enabler.

Although Jira offers many built-in rules to automate processes, there are still significant limitations on what you can do “out-of-the-box.”

That’s where Jira Misc Workflow Extensions (JMWE) comes in! JMWE gives you the tools to automate virtually unlimited use cases, no matter how simple or sophisticated they might be.


JMWE provides a large collection of workflow conditions, post functions, and validators to extend Jira workflows – inside Jira workflow enginewithout code. These extensions alone can support most of your automation needs.

JMWE also allows you to automate your business workflows outside of the Jira workflow engine using triggers – such as field changes or issue updates.

With JMWE, you can do things like:

  • Automatically assign issues to users or send out custom action-based emails
  • Change availability of transitions based on different parameters, such as statuses of linked issues or sub-tasks
  • Automatically create one or multiple issue(s) (or delete issues) during a transition – or on other event triggers
  • Automatically add comments to fields
  • Automatically transition the parent issue when sub-tasks are transitioned (or linked issues, or Epic/Story, etc.)
  • and so much more

Most, if not all, of your automations can be done with Jira Misc Workflow Extensions. Below, discover some of the JMWE’s power features, including:

Using point-and-click tools—post functions, conditions, and validators—to configure workflows without code

JMWE provides a large collection of more than 40 workflow post functions, conditions, and validators – all the building blocks you need to extend your workflows—without code—to support any number of use cases. They are all available within the Jira workflow designer and are very easy to configure.

Here are just a few of the JMWE conditions, validators and post functions types that simplify the process of extending Jira’s native features to quickly build and automate your business processes:

  • Field updating post functions such as set field value, copy field value to parent, copy to linked issues, link or unlink issues, set issue security from user role, increase value of field, and many more.
  • Communications post functions such as email issue, comment issue, comment linked issues, etc.
  • Assignment post functions such as assign to role member or to last role member.
  • Transition triggering post functions such as transition issue, transition parent issue, return to previous status, etc. See all post functions for Jira Cloud or for Jira Server and Data Center.
  • Jira workflow conditions include previous status, separation of duties, hide transitions, and many more. See all conditions for Jira Cloud or for Jira Server and Data Center.
  • Jira workflow validators include parent status validator, linked issues status, linked issues validator, comment required validator, and more. See all validators for Jira Cloud or for Jira Server and Data Center.
For the lists all JMWE and Jira native conditions, validators, and post functions, check out these Jira Workflow Cheat Sheets* 

*For the most up-to-date list of extensions, please refer to Jira Cloud documentation or Jira Data Center and Server documentation.

Extending Jira workflows with simplified scripting

Extending JMWE post functions, conditions, and validators further

By now you know that Jira Misc Workflow Extensions comes with a diverse collection of point-and-click building blocks that you can configure without code. But if you’d like to customize things even more, you can easily click your way through scripting to make your workflows even more powerful.

JMWE offers simplified scripting features in addition to the point-and-click configuration, not instead of it. Because JMWE is set up this way, most “scripting” involves just a few clicks, without any additional coding.

Essentially, instead of writing the whole workflow extension yourself, you simply customize JMWE with snippets of code.

For example, if you want to transition all linked issues and provide, for one of the transition screen fields, a calculated value, you just need to write the code that calculates that value (usually one to two lines), and not all the code that iterates over the right linked issues, then prepares the transition, validates it, executes it, etc. (which would require at least a hundred lines of code).

Anyone in your organization who wants to reuse or edit JMWE workflow configurations can easily understand what they do, without getting lost in lines and lines of code.

Whether you’re using simple or sophisticated scripts, the user-friendly editor with interactive inline help, syntax highlighting, and a script tester makes customization easy. Using JMWE, even Jira admins who are not expert coders can quickly deploy workflows.

Jira expressions or Nunjucks-based simplified scripting is used in Jira Cloud. Groovy-based simplified scripting is used in Jira Server and Jira Data Center.

Watch this video on how simplified scripting works in JMWE

Build-your-own (scripted) condition, validator, and post function

JMWE’s Build-your-own (scripted) Condition, Build-your-own (scripted) Validator, and Build-your-own (scripted) Post-function let you extend your workflows beyond what configurable extensions can do.


For example, using the Build-your-own (scripted) Condition, you can create a condition to hide the transition from the user if they are not an approver, allow the issue to be closed only by the reporter, show an “escalate” transition when the time-to-resolution has been breached, and so much more.

JMWE Editor and Tester, with interactive inline help system, makes scripting easy

JMWE’s Editor and Tester simplifies scripting using its proprietary interactive inline help system. It offers a simplified API that hides the complexity of the Jira API.

It features on-the-fly syntax highlighting and syntax checking, as well as comprehensive documentation and many examples to help you get started.

The JMWE Editor and Tester shows: 

  • Expected values for each field type (displays what the script should return)
  • A description of global variables and functions that are available to use in your scripts
  • An explanation of how to access any issue field
  • Methods and properties available on issue objects, and more

Script testing

JMWE’s scripting GUI lets you test the syntax on the spot to avoid deploying non-functional workflows. You can test your script against any issue so you can debug it and make changes without having to actually trigger the transition and look at the Jira logs to see the results.

Very little coding experience is required to use JMWE’s Editor and Tester, so you can quickly learn how to create sophisticated workflows.

Simplified Jira API – no need to rewrite your scripts

JMWE also includes a simplified Jira API for the most common tasks that makes writing sophisticated scripts easy. Instead of spending hours searching the Jira API documentation to write even the simplest code, you can get to work quickly using comprehensive JavaDoc-style API documentation of any Jira, JMWE, Java or Groovy class included.

And you won’t need to rewrite or update your scripts when the Jira API changes (which happens with every major release). JMWE’s simplified API shields you from these changes.

If you haven’t yet, take a quick look at JMWE’s scripting editor.

Reusing post function configurations with Shared Actions

Once your Jira instance has multiple workflows, it won’t be long before you’ll find yourself recreating the same post functions — or sequences of post functions — on numerous transitions and projects.

Using the Shared Actions feature of JMWE, you can create and more easily maintain a single source of truth for any of your commonly configured post functions.

Post functions and post function sequences can be created once and reused across multiple workflows.

For example, set multiple fields using set field value post functions and then add them to various transitions as one Shared Action, without the need to recreate them again and again. Or configure a post function to send an email and then reuse it in different workflows.

And because they are post function based, Shared Actions can also be used outside of Jira workflows with JMWE’s Event-based Actions and Scheduled Actions.

Why this matters: ​

  • Because Jira doesn’t support copy-and-paste for post functions, Shared Actions makes it easier for you to reuse common configurations quickly.
  • One Shared Action can include multiple post functions to run in sequence—you can create a more sophisticated process once, then reuse it in your workflow transitions.
  • Using Shared Actions makes frequently used post functions easy to maintain—changes to the Shared Action will instantly apply to all transitions where it is used.

How it works: 

In the Shared Actions page, combine one or more JMWE post functions into an action. Then, use the Shared Action post function to add your configuration to various transitions, even in different workflows.

Watch this 3-minute video to see how to add a comment that shows who transitioned an issue and when using JMWE’s Shared Actions:


Learn more about JMWE’s Shared Actions in the documentation for Jira Cloud or for Jira Data Center and Server.

Jira automation outside of workflow transitions with Event-based Actions

Regular workflow post functions run on transitions: that is, when an issue transitions from one status to another (for example, an issue transitions from OPEN to IN PROGRESS). But what if important issue updates occur outside of status changes without a transition taking place? 

With Event-based Actions, you can run any of the JMWE post functions—or sequences of post functions—outside of Jira workflows. These actions can be triggered by:

  • Issue field value change
  • Issue commented
  • Issue updated
  • Issue deleted
  • Attachment created/deleted
  • Issue link added/deleted
  • Work log created/updated/deleted
  • Issue created
  • Issue transitioned

These actions can keep issue fields synchronized, validate field changes, develop highly focused email notifications, and much more—all without service limits of Jira’s native automation features.

You can even perform calculations using Event-based Actions. For example, you can use existing field values to dynamically configure value of a different field, all based on Issue field value change.


JMWE’s Event-based Actions vs. Jira Automation:

  • You can build many different automations using Jira’s native rules. But in multi-project and global automations, Jira Cloud Standard allows for a maximum of 500 executions per month. This is a very small amount and can often be reached in hours, or even minutes. If your team exceeds this limit, automations simply stop running. With JMWE, you can run an unlimited number of workflow automation rules.
  • With JMWE’s Event-based Actions, you can automate actions using any of JMWE’s post-functions, and because they are powered by our simplified scripting options, you can set up considerably more advanced rules.
  • Built-in Jira automation rules always run on behalf of the Automation “app user,” meaning that 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). 

Learn more about JMWE’s Event-based Actions in the documentation for Jira Cloud or for Jira Data Center and Server.

Scheduling post functions to run at set times with Scheduled Actions

Regular workflow post functions run on transitions, but with Scheduled Actions you can schedule post functions to run against issues returned by a JQL search.

You can set up many types of automation, such as workflow transitions, issue status updates, and user changes, all based on your predefined schedules.

For example, you can automatically transition any issue escalated yet not addressed within your SLA threshold.

Scheduled Actions enable you to automate post-function execution at specific times on selected issues of your Jira instance, such as:

  • Send emails automatically every day;
  • Create a new subtask every week;
  • Update issue with information from another Jira instance every hour.

Things to know: 

  • ​Works based on predefined times, not workflow transitions
  • Flexible scheduling allows for any frequency (10-minute minimum)
  • Can execute many types of automations, such as workflow transitions, issue status and user changes, all in sequence
  • Can toggle on and off to update existing projects and make bulk changes

Watch this 2-minute video to see how to send a daily reminder email to assignees of issues that are “in progress” using JMWE’s Scheduled Actions:


Learn more about JMWE’s Scheduled Actions in the documentation for Jira Cloud or Jira Data Center and Server.

See issue transitions in the activity view

The transition history tab lets Jira users (not just Jira administrators) easily see all issue transitions, when they took place, and who triggered them, all in one list. You can rely on this feature for activity information essential to your business processes.

For example, managers and auditors could get a clear understanding of what actions have been taken on issues, verify that the right people work on or approve them, and that processes always follow the appropriate workflow.

You can also see Time in status for each transition so that you can more easily evaluate the history of status changes of an issue.

The JMWE Transition tab lets users view the following information for each transition:​

  1. Transition statuses. It lists To and From statuses of transitions in chronological order. (NOTE: Because auto-transitions don’t change the issue status, JMWE does not show them).
  2. When the transition was triggered (with timestamp). You can hover over the date to see the full timestamp value, which is especially useful for relative date/time values.
  3. Author of the transition
  4. Time in Status: How long the issue spent in the original “from” status (left of the arrow) before being transitioned. 

The JMWE Transitions tab is enabled by default, but you can also turn it off to remove it from user views. If you choose to hide the JMWE’s Transition tab, uncheck the option on the configuration page of the JMWE app. 

To learn more about JMWE, explore this Getting Started Guide. Videos featured in the guide will help you learn how to best use JMWE and how to configure workflow extensions.

Last updated: 2023-07-31

Recent resources

Back to Top