Create smooth communication between support and development teams with Jira automation rules

[#1]

Have you ever faced the issue when a support/operation team doesn’t know what is happening on the development project? I bet you have. Communication is the key to efficient work, however, because of Jira peculiarities, it may be difficult to synchronize support and development teams.

Usually, a project structure has three actors: an end user, a support team member (agent), and a development team member (developer). Despite being connected via the Jira ecosystem, support /operation projects in Jira Service Management often lack information from development projects in Jira Software.

When the end user submits a request (support request) in a support project the agent performs triage, and if there is a need to involve development teams, the agent then creates an issue in a development project, linking the support request to the development issue via issue linking.

Due to Jira’s privacy settings, the end user usually is not allowed to see this newly created Jira development issue, even if it is related to the original end-user request. Because of that, the project is divided into two separate parts — one for end users and another for developers, where an agent is taking the mediator role. It creates tension, as the end user doesn't get a direct communication channel with the development team. From the business side, it also leads to a bigger budget, as more time is taken to deliver messages from end-user to developers and visa-versa.

To make the communication process less time- and money-consuming and increase end-user satisfaction, we offer you rules that automatically synchronize support requests and development issues.

Get new comments notification 

1. The rule is triggered when the comment is added to the development project

   You can make it triggered for comments with specific conditions to consider only specific comments or check if comment content contains a specific world as shown in the example below:

2. Then you add a linked issues condition and send the same comment to the linked support ticket

   You can use JQL, as shown in the picture below, or you can filter by specific link type.

   Finally, you can configure if you want to show this new comment for the customers or make it internal only:

   For all this to run smoothly, the rule should be multi-project (global), because we interact between different projects. There is a limit on the number of multi-project automation, please, be aware of that.

Send updates from a development project to a support project

We will use webhooks to make it work. Сreate a listener rule in a support project. The rule will “listen” if there are any new comments added to the development project. As soon as it happens, the automation rule in the development project will send a webhook with the comment data in it, and the support project will “listen” to this webhook and take some further actions.

This is an example of the rule sending the webhook:

In the webhook you send the comment to the linked issue using the webhook custom data section:

 {

    "issues":

        [{{#issue.issuelinks}}"{{issue.key}}"{{^last}},{{/}}{{/}}],

     "data":

        {

            "key":"{{issue.key}}",

            "comment":"new comment : {{issue.comment.last.body.jsonEncode}}"

         }

}

Here is an example of a ’listener’ automation rule which receives the webhook and adds a comment from the webhook data:

You can also synchronise all important changes: create a dev ticket when a support ticket is created, status updates, change of assignee or the team working on the request, etc.

When the system is triggered by an assignee change, you can check if your development issue is linked to the support request. If it is, it sends webhook custom data that is related to your event — in your case new assignee name — as you can see in the example below:

In a similar way, you can manage other significant changes in the development project using various triggers, conditions, and webhook custom data we send.

And that is how you can use automation rules to ease your work on Jira projects. If you have any questions, feel free to ask them in the comments below.

[Jamie MacDonald]

In this scenario, how would the synchronized comment appear to have been authored by? I've used Automation to do something similar, but the comment author shows as the automation for Jira user.

[Alex Kiselev _Itransition_]

Hi Jamie,

Sorry for the late response.

I can suggest aggregating the information about the event in Software project into the message to be displayed as internal comment in Service project.

So it could be:

Event type: <issue commented>

Actor: <user name>

Content: <comment body>

Automation still is internal comment author, but all relevant information is in Service ticket internal  comment.