Event-based actions

Create an event-based action

To create an event-based action:

1. Navigate to the Jira Settings → Apps → Event-based actions. This page lists the existing event-based actions with the respective Status, Action name, and Event(s) details.
   
   

   Open

   

    

2. Click New event-based action on the bottom left corner of the page to navigate to the Event-based Action Editor screen where you can configure the following details:
   
   

   Open

   

    

   • Name (mandatory): Enter a meaningful name.

   • Description: Enter a more detailed explanation of what the action would accomplish.

   • Event: Select the Jira event that triggers the action from the following:
     Trigger (mandatory):

     • Issue Created (default option): Triggered when a new issue is created, including when an issue is cloned.

     • Issue Updated: Triggered when an issue is modified, such as being edited or transitioned.

     • Issue Deleted: Triggered when an issue is deleted.

     • Issue Commented: Triggered when a comment is added to an issue.

     • Comment Updated: Triggered when a comment is updated on the issue.

     • Comment Deleted: Triggered when a comment is deleted from the issue.

     • Issue Transitioned: Triggered when a transition is performed on an issue. You can optionally filter the source and/or destination statuses of the transition.

     • Issue Field Value Change: Triggered when one of the fields you have selected is modified on an issue.

     • Attachment Created: Triggered when an attachment is added to an issue.

     • Attachment Deleted: Triggered when an attachment is deleted from the issue.

     • Issue Link Added: Triggered when an issue link is added to an issue.

     • Issue Link Deleted: Triggered when an issue link is deleted from an issue.

     • Work Log created: Triggered when a worklog entry is added to the issue.

     • Work Log updated: Triggered when a worklog entry is updated on the issue.

     • Work Log deleted: Triggered whenever a worklog entry is deleted from the issue.

   • Ignore events caused by JMWE post-functions and actions: Select this option to ignore events resulting from changes performed by JMWE post-functions and actions that trigger this event-based action. If you do not select this option, it increases the risk of creating an infinite loop if this event-based action makes changes that end up triggering the same event that the action listens to.

   • Ignore events caused by Jira Automation and other apps: Select this option to ignore events resulting from changes performed by Jira Automation rules, or by other apps. For example, if you have configured an event-based action to listen to the Issue Transitioned event, you might care only about comments created by users, and want to ignore transitions performed by an Automation rule.

   • Scope: Specify the project(s) and issue type(s) on which the action is run. You can further choose to apply the action on the issues that match a JQL filter or Nunjucks condition.

     • Projects: Select one or more projects from the available options for the action to be applied on. When you leave this field empty, the action is applied to all the projects in your Jira instance.

     • Issue types: Select one or more issue types from the available options for the action to be applied on. When you leave this field empty, the action is applied to all the issue types in your Jira instance.

     • Only apply to issues that match a JQL filter: Select this option to apply the action on issues that match a JQL filter. Click Edit JQL to search for issues using a JQL filter in the JQL editor window and click Submit.
       Example:

       project = TEST and issuetype = Bug

     • Only apply to issues that match a Nunjucks condition: Select this option to apply the action on issues that match the Nunjucks condition mentioned in:
       Nunjucks condition: Enter a Nunjucks template that returns true (or any value that is neither empty nor false) for any issue on which the action should run.
       Example:

       {{ issue.fields.project.key == "TEST" and issue.fields.issuetype.name == "Bug" }}

       Click here to understand how to pass variables within a sequence.

   • Post-functions: Click Add post-function to navigate to the window that lists all the available post-functions. Select a post-function, configure it as needed and add it to the list here. The post-functions added here are run in the sequence displayed. You can use the ☰ handle to drag a post-function and drop it wherever required in the list to reorder the sequence.

   • Error handling
     Skip subsequent post-functions if a post-function encounters an error: Select this option to skip running the remaining post functions in the sequence when an error occurs in one of the post functions.

3. Click Save to add the newly created event-based action to the Event-based action screen.

Edit an event-based action

1. Click Edit in the Event-based actions screen to modify the respective event-based action.

2. Modify the action details in the Event-based Action Editor screen.

3. Click Save to save the changes.

Delete an event-based action

1. Click Delete in the Event-based actions screen to remove the respective event-based action permanently.

2. Click OK in the confirmation dialog to confirm. The event-based action is deleted.

Enable/disable an event-based action

In the Event-based actions screen, turn the toggle Off or On in the Enable column to disable or enable the respective event-based action. By default, a newly created event-based action is enabled.

Pass variables within a sequence

Using the {% setContextVar %} Nunjucks tag you can pass data from one post-function to all subsequent post-functions.

• context: Holds all the context variables added in the current post-function. For example, if you create a context variable myVar in the first post-function of the sequence:

  {% setContextVar myVar = "a value" %}

  This variable will then be available to all its subsequent post-functions as:

   

Variables specific to the Create Issue post-function

• newIssueKey: Stores the issue key of the last issue created by a Create Issue(s) post-function in the action. You can access it as:

   

• newIssueKeys: Stores an array of the keys of all the issues created by any Create Issue(s) post-function in the action. You can access the created issues from

  For example: to add a comment on the current issue with the keys of the issue created

You can access the information of a specific issue using the issue filter. For example: To get the assignee of the issue created by the Create Issue post-function

Pass context variables to an Event-based action

Variables specific to the current transition

If the post-function is run during a transition, information about the transition is accessible.

• transition.transitionId: Stored the ID of the transition.

• transition.transitionName: Stores the name of the transition.

• transition.from_status: The status from which the current transition starts.

• transition.to_status: The status to which the current transition leads.

• transition.workflowName: The name of the workflow the transition belongs to.

• transition.workflowID: The ID of the workflow the transition belongs to.

Access these variables using the prefix context.. For example:

This returns ID of a transition.

Variables specific to Comment

If the post-function is run during a transition, the comment that was entered on the transition screen is available. 

The newly created comment is available if the post-function is run during an action triggered by an Issue Commented event.

• context.comment.body: The body of the comment, as text with wiki markup.

• context.comment.created: The date/time the comment was created.

• context.comment..author.accountID: The account ID of the author of the comment.

• context.comment.author.displayName: The display name of the author of the comment.

• context.comment.jsdPublic: Determines if the comment is shared with Customers (for Jira Service Management projects).

Variables specific to Attachment

If the post-function runs as part of an Event-based action listening to the attachment_created or attachment_deleted event, the attachment added or deleted is available through the context.attachment variable.

• attachment.filename: Stores the filename of the attachment.

• attachment.id: Stores ID of the attachment.

• attachment.created: The date/time the attachment was created.

• attachment.size: The size of the attachment.

• attachment.mimeType: The mime-type of the attachment.

• attachment.author.accountId: The account ID of the user adding the attachment.

• attachment.author.displayName: The display name of the user adding the attachment.

Access these variables using the prefix context.. For example:

This returns ID of an attachment.

Variables specific to Issue Link

If the post-function runs as part of an Event-based action listening to the issue_link_created or issue_link_deleted event, the issue link added or deleted is available through the context.issueLink variable.

• issueLink.sourceIssueId: The issue ID of the source issue of the issue link being added or deleted.

• issueLink.destinationIssueId: The issue ID of the destination issue of the issue link being added or deleted.

• issueLink.issueLinkType.name: The issue link type of the issue link being added or deleted.

Access these variables using the prefix context.. For example:

This returns the issue link type of the link being added.

Variables specific to Work Log Link

If the post-function runs as part of an Event-based action listening to the worklog_created, worklog_updated, or worklog_deleted event, the worklog data is available through the context.worklog variable.

• worklog.timeSpent: Work Log string added/updated/deleted.

• worklog.timeSpentSeconds: Work Log in seconds added/updated/deleted

• worklog.comment: Comment added/updated with the Work Log.

• worklog.created: The date/time the worklog was created.

• worklog.updated: The date/time the worklog was updated.

• worklog.started: The date/time the worklog was started.

• worklog.author.accountId: The accountID of the user adding the worklog.

• worklog.author.displayName: The display name of the user adding the worklog.

Access these variables using the prefix context.. For example:

This returns the date and time of when the worklog was created.