Show all linked issues in agent view issue ticket

[Heather Marquez]

Hello, 

I have an automation rule to link all tickets within a project from the same reporter email address. What I find is that the agents cannot then see these from the issue view.

We want agents to easily see all the requests from the same reporter to better troubleshoot issues.

I have gone through many searches to find a solution but hoping someone here can point out a way?

Thanks in advance!

Heather

[Dan Breyen · Accepted solution]

Hi Heather, you'll have to decide if this is 'easily' or not, but could you make a filter where it shows all the issues by reporter and the agent just pastes in their email address or types in their name?  I have something like that setup that I use.

Hope that helps.

[Heather Marquez]

Thanks Dan! We take in hundreds of issues daily, some are duplicates from the same reporter over a period of a couple weeks. We are looking for a way to link all the tickets that the reporter has created (open and closed) so that agents can get a better picture of the experience, issues, and resolution.

Today the agent has to manually search for all issue tickets that a given reporter has submitted.

[Trudy Claspill]

Hello @Heather Marquez 

If you are looking for an automated way to link a newly created issue to all other issues created by the same person, you can do that with an Automation Rule.

TRIGGER: Issue Created

BRANCH: for related issues / JQL
  JQL: reporter = {{issue.reporter}} and issue!={{issue.key}}
  uncheck the box that says "only issues that have changed..."

  ACTION: Link Issue

[Heather Marquez]

@Trudy Claspill

This worked beautifully! Thank you very much for your help!

Two follow up questions:

1. I assume this only applies to new requests? If yes, do you know if there is a way to do a one time cleanup to link all other past requests by the same reporter email?
2. Also, since we are linking to the trigger issue, the newly created one will show all linked requests. I noticed that a related request may only show the trigger request rather than all requests. Is there a way to link to all related requests (e.g. same reporter email)? We want to make sure agents have full perspective when viewing any request (old and new). Screen shots attached showing this.

[Trudy Claspill]

Hello @Heather Marquez 

Regarding your follow up question #1a:

Yes, the rule I outlined, as I outlined it, should be linking the newly created issue to all issues that exist in the same project reported by the same user. It does not otherwise touch pre-existing issues.

Regarding your follow up question #1b (which seems to be maybe the same as follow up question #2): finding all issues by a given reporter up to this point and ensuring that each one has a link to every other one.

This is much more complex. I assume you are looking at multiple reporters each potentially having multiple issues? It seems like that might require a level of recursive action that I have not tried to use in an automation rule before. I need to spend more time thinking about this. I'm also going to tag-team @Bill Sheboy because he has done a lot more with automation rules of that level of complexity than I have.

[Heather Marquez]

Thanks @Trudy Claspill

The solution I'm looking for is one where one reporter will sometimes submit multiple requests, for what is most of the time the same need, in attempt to escalate. While we are inputting knowledge base etc to get to the root of that issue, we want any of our agents to see all the requests from the same reporter email.

Specifically, last week we had one customer who created 6 requests with different info within the same day. We had 3 different agents with different issue tickets and different information working with the customer to try and resolve at different times.

The logic is that if any of those agents could see all the requests from any of the customer requests, then one agent can work holistically on the issue with that customer. Hope that helps and thank you again!

[Bill Sheboy]

Hi @Heather Marquez 

I'm following up based on the ping from Trudy.  (hi, Trudy!)

Apologies in advance for the long answer...

First thing, the scenarios you describe seem better supported with tools like Jira Service Management (JSM), rather than trying to re-implement some of those features with Jira.  You may want to consider investigating that product.

Next, you are describing a situation where...

• Customers submit requests using Jira items, occasionally submitting the same request multiple times
• When the customer submits a request, their user is set as the Reporter of the Jira issue
• Agents manage requests, and want better visibility to all requests from a customer (i.e., Reporter of the Jira issue)
• You are asking about solving the visibility issue by cross-linking all issues with the same Reporter, allowing the view of a single issue to show all others
• You appear to be using the Standard License level of Jira Cloud
• You do not state this, but I am assuming your agents have a defined intake process for requests to transition them to delivery teams, such as a tier-based approach, and so people are working a queue as requests appear

Although it is theoretically possible to cross-link all the issues with the same Reporter, possibly using automation rules, I strongly urge against that.  Depending upon the number of Jira issues, such a rule would run quite often, need to trigger itself, and likely run into service limits: throttling, execution volume, execution time, etc.)  Plus, there are edge cases which will lead to extra rule execution and noise in the issue linking: reporter changes, entry errors / edits, issue deletion, etc.

And most importantly, there is a large change coming to automation packaging / limits and your rules may hit those limits; please look here for more information, and inform your Jira Site Admin if they do not already know this: https://community.atlassian.com/t5/Automation-articles/Introducing-our-new-packaging-model-for-Jira-Cloud-Automation/ba-p/2446099

Back to your question and scenario...

To me it appears there are two primary concerns:

1. duplicate identification
2. visibility of customer requests in an "easy" manner

For item 1, you could create a list of common key words, check them with JQL and the Contains ~ operator, and have an automation rule which tags (e.g., adds a label POSSIBLE-DUPLICATE) to newly created issues as a candidate for duplicate investigation.  (I believe JSM has an upcoming feature which makes this easier, and there is discussion of adding that to Jira Cloud also.)  Then your agents can review them to decide the disposition: close as duplicate, etc.

For item 2, the Jira issue view UX could show all linked issues, but the linking is a challenge.  (This would be more easily handled with a tool like JSM.) 

Depending upon your number of customers, you could investigate using Dashboards with saved filters by Reporter, or look at the Atlassian Marketplace for apps which provide some of the request management features you need.  For example, dashboard gadgets which allow selecting search criteria (like Reporter) from dropdown values and then update the entire dashboard view for analysis / action.

Kind regards,
Bill

[Heather Marquez]

Thank you so much @Bill Sheboy

Agree with everything you have said and the only change here is that we actually have both Jira Cloud Standard as well as JSM Premium as part of our products. I wasn't able to find anything for JSM that would provide a better solution to this problem?

We have been discussing the new automation changes as well and agree with the volume. Item #1 that you mention seems to also create a high volume and based on my understanding of the automation changes could also result in hitting the new limits?

As for item 2, completely agree that reporting will be key for all of this to drive down duplication over time.

[Bill Sheboy]

With the use of JSM, I recommend talking to your teams (or solution implementation provider if you are using one), as they will know better how to do what you asked.

Hitting the new automation limits is dependent on customer usage, and I was noting a rule that cross-links issues could have impacts...

The simplest case is as each new request is added, a scan of other issues from the same reporter leads to one round of linking N-issues.  That would be one rule execution, as far as the new count limits.

You seemed to also note linking older items, and that would require a scheduled rule, run repeatedly until "caught up" on linking.  That would be N x N linkings, for each Reporter, leading to a larger count.