Use Workflow Rules to transition issues on a per-project basis

This guide describes the use of the new Workflow Auto Advance feature that is built into the project mapping section from version 2.0.1 onwards.  The old workflow advance feature can for now still be found under Profile>Workflow, but this will be removed in the future.

Since 2.0.1


This feature allows workflow transitions to automatically trigger on issue creation and/or issue comment (eg to Reopen an Issue on Comment).  The chosen transition(s) can also be restricted to events originating from assignees or non-assignees.  The configuration is held inside a workflow rule.  Each project mapping can have multiple rules.

Creating a Workflow Rule

Navigate to Profile > Project Mappings, and then edit a project mapping.  You will see a section labelled Workflow.  Here we can add multiple workflow rules that will be tested as part of this project mapping.

Selecting the New Workflow Rule link will add a new empty rule to the mapping.  Once created, click the edit icon Unknown Attachment to go to the workflow rule configuration screen:

Rule settings






A description of the workflow rule.  This may be useful for others who see this configuration.

Workflow Name

Name of the workflow the rule is to be applied against.


Defines what event will trigger the transition.  There are three options:

  1. create - the transition will only be triggered by an issue creation event.

  2. comment - the transition will only be triggered by an issue commented event.

  3. create/comment - the transition can be triggered by either issue creation or an issue commenting.

Run Condition

Controls which user will drive the workflow transition. There are two options:

  1. forNonAssignee - the transition is driven by a user who is not the assignee.  For example, the reporter replying could mean that the assignee needs to do something.

  2. forAssignee -  the transition is driven by the assignee.  For example, a reply could mean that the issue is in progress, or it requires action from the reporter.

Issue Types

Define which issue types the issue has to be in for the rule to be triggered. Only Issue Types valid for the workflow defined in the Workflow Name will appear. If none are selected then this restriction will be ignored.


Define which statuses the issue has to be in for the rule to be triggered.


Define what transition sequence to perform, i.e. Pending External > Action Needed. You can also carry out multiple transitions: Pending External > Action Needed > Resolved.


Optional.  Apply workflow properties to the transition to meet special transition conditions.

To set the resolution in a transition you need to use the numeric ID that can be seen by hovering over EDIT in the Jira > Issues > Issue Attributes > Resolutions  list:


therefore to set that resolution you would use:


Run As Condition

What user to run the transition as.  This enables JEMH to carry out transitions that require different identities (i.e. Assignee). There are three options:

  1. emailSenderUserOnly - The issue reporter will be used to run the workflow transition, if the reporter is a JIRA user they will be used or if the issue was created by a non-Jira user the default reporter will be used.

  2. nominatedUserOnly - You can specify a default user that will be used to run the workflow transition.

  3. issueAssigneeOnly - The issue assignee will be used to run the workflow transition.

Example Rules

Using the workflow below, we want an issue to be set to Pending External when the assignee comments and Action Needed when another user comments back.

Only Issue Types valid for the workflow defined in the Workflow Name will appearThis is the rule for transitioning the status from Action Needed to Pending External when the assignee comments.

This is the rule for transitioning the status from Pending External to Action Needed when the sender comments.

The workflow rules from the project mapping screen.


Here I create an issue using the non-Jira user andy@localhost and change the issue status to Action Needed.

I then comment on the issue via email using the assignee. Here we can see that the status of the issue has transitioned from Action Needed to Pending External.

If I then comment back using andy@localhost we can see that the status transitions back to Action Needed.

Default Workflow Auto Advance Rules

If you have multiple project mappings in a profile that all work off the same workflow and you want each mapping to use the same workflow rules, instead of adding the rules to each profile mapping we can create a set of default workflow auto advance rules that will be applied if no rules are found in a project mapping.

To do this first navigate to Profile > Project > Project Mappings and create a new project mapping. In this new mapping do not specify a project and select the Is Default Mapping tick box.

Once the mapping has been created the Workflow Auto Advance Rules can be added in the same way as we did earlier in the step-by-step guide. What will happen is that when JEMH matches on a project mapping rule and finds that there are no Workflow Auto Advance Rules to apply in that mapping it will then check the default mapping to see if there are any rules there, if any rules are found and the project has a matching workflow then they will be applied.

Issue Type Restriction since 3.3.50

SINIf you require further issue type restriction in the Workflow Auto Advance rule then select Issue Type(s) and save by clicking the submit button.



Issue Type column will show you the currently saved issue types which which are valid to pass the issue type restriction. If there is an invalid issue type for the current workflow; then it will be highlighted in red with a message, “The issue type selected is invalid”. This can typically happen if a user is importing a profile from one system to another.

Related Articles