Sending an Automated Email when a Link is Added or Removed from an Issue

Question

I have established a Change Management project where we create Change records to track what we are intending to deploy.  As part of each of these CM issues, we link tickets from our development project using the link type of "is action item for".

I would like to send an email to a set of individuals when a new linked item as been added to the CM ticket, but only if the CM ticket is in one of a specific set of statuses (Authorize, Awaiting Implementation, Implementing).

I would also like to send an email when one of these linked items is removed from one of the CM tickets, if the CM ticket is in one of a specific set of statuses (Authorize, Awaiting Implementation, Implementing).

One development ticket could appear in more than one CM ticket.

Currently, I can get the "Add" use case to work as long as the development ticket is not associated to any other CM ticket.

The "remove" use case is not working in most cases at the moment.

If I remove the CM ticket in a specific status condition all emails are generated, but this spams my users during our planning process.

Any help would be greatly appreciated.

Darryl Lee · Answer

Ok got it.

So as I mentioned, the best thing to do is create a test instance or project, and try this there. Ideally you would add Audit log messages to check the values like:

LinkType: {{linkType}} | Status: {{issue.status}} | Mercury Env: {{Mercury Environment(s)}} etc.

Then you can sure that any conditions you are checking are applied to SLAYCRM rather than the CM tickets. Otherwise you might need to adjust your trigger to the corresponding link type to "Is action item for". (Like maybe it's "Is blocked by this action item?")

ALSO I would recommend that you try using the Field Comparisons rather than JQL. You can more easily test exactly where something might be going wrong.

Doug Slay · Answer

Thanks Darryl.  The Change Management ticket CM-104 includes links to the development project (SLAYCRM). Those links are established as "Is action item for".  A development ticket will be associated to 2 CM tickets (one for UAT and one for PRD).

The intent is that I send an email to our stakeholders if we add a new link (SLAYCRM) or remove an existing link (SLAYCRM) from the Change Management ticket (CM-104), but only if the CM ticket is in a specific status.  That condition is what is causing this to fail.  If I remove the condition, I get the email send anytime I add or remove; however, this will spam the stakeholders as we add the associated tickets during our planning phase.

Darryl Lee · Answer

Ok, links always are tricky.

So let's see if I've got this right:

For example: CM-104 is the Change Management issue. And you are ADDING or REMOVING links to SLAYCRM (is that the Development Project)?

Question: "Is an action item for" similar to "Blocks"?

I mean to say: you expect all SLAYCRM tickets to be completed before CM-104 can move forward in its workflow?

In my testing, in the scenario above, the trigger "When: Issue Linked" actually considers SLAYCRM to be the "triggering" issue.

So I think this means that first off you should probably use an "Issue fields condition" to see if the Project is SLAYCRM. But you're wanting to send an email about CM-104. Something like:

"For issue CM-104, this new issue, SLAYCRM=123 was added as an action item."

ANYWAYS though, I did a bit of testing, and this bit of informational text is very useful:

So I believe in your scenario "Dev" is the source issue, and the "Change Management" is the destination, and you can use that {{destinationIssue}} smart value to check that something is being linked to a CM issue.

Anyways, I did this test: my "Change Management" project is BT. And my "Development" project is SIM. You can add as many conditions about that linked issue as you want.

From my BT issue, I would add a link to SIM that was "In Progress".

This rule picks up on the new link that was added, checks that it's SIM, and THEN checks that the project it linked to was BT, and if so, sends the email.

I realize this is confusing. :-}

You need to play with it, and I HEARTILY RECOMMEND 1) setting up a Sandbox/free instance/test projects to try this in, 2) adding a ton of Audit Log messages and write out things like TRIGGER: {{issue.key}} and LINKED ISSUE: {{destinationIssue.key}}, and then 3) test test test.

There is excellent instructions here: Debug an automation rule