Avalanche Support

I upvote this idea. Having access to this field will also allow reporting the number of incidents by problem not only by its ID, but also displaying other ticket properties such as subject, etc.

Upvoting this idea. I have been squeezing my mind to come up with a workaround to display the problem subject next to its ID in explore so that I can actually get an informative query, but I can't do much.

Best I could do was unifying the subject in all incidents of the same problem and add the ticket subject to the attributes. However, when an agent forgets to use the exact same subject with the exact same letter cases and just leaves the end-user's default subject until ticket is closed, the query becomes inefficient.

Also would love to be able to customise the incidents view from the parent problem.

Add a new option for "on a holiday?" trigger condition other than 'yes' and 'no'.
'Within SLA' option can return true when the holiday is SLA-duration away to prepare the end-user for upcoming interruptions.

Use case:

Ticket with low priority, which has a 2 working-day SLA, created on December 23rd, a normal working day, may not be addressed until the 27th. As our standard holiday is on December 25-26. We need to set customer expectations in an automated way.

Currently, the trigger is actively setting customer expectation only during the holiday itself. We find ourselves having to push agents to clear all tickets before the holiday starts or having to manually update our triggers before and after the holidays.

It would be great to have a new trigger condition called something like "Within SLA from a holiday?" that would return true, not just on the holiday date, but during SLA time before it too.

A workaround using a second schedule and switching them with triggers is possible, but sounds unnecessarily complicated. I'm sure Admins would LOVE this.

Hi @.... I saw the article, but it doesn't work for our needs. Using standard calculated metric is not a solution for our dashboard with multiple tabs and 10+ queries in each one. It makes it impossible to toggle our filters as needed.

Upon further review of the filter that we set up, we have 2 tags excluded. The bizarre situation is that one of them is actually excluded as intended while the other isn't. They are mutually exclusive in all tickets.

Update: I think the tickets which have been excluded successfully are the ones with a single tag. When the ticket tag filter is set to "exclude values" instead of "select values", it apparently queries if ticket tags == "undesired_tag1" or "undesired_tag2", etc. It returns true only with exact match, thus excluding it. How it SHOULD logically operate would be the same way as using the standard calculated metric

IF ([Ticket attribute] = "value"  AND NOT INCLUDES_ANY([Ticket tags], "undesired_tag_1", "undesired_tag_1")) 
THEN [Ticket ID]
ENDIF

It's impractical that I would do this for every single report, so can you please fix it?

I just found out that all those months, our tickets tagged with "testing_request" are NOT excluded as we set them in the filter. It makes us look like a joke and inflating data. We are absolutely furious. How was that reported 2 years ago and still not fixed?