Recherches récentes
Pas de recherche récente

Alex Kolodzey
Adhésion le 15 avr. 2021
·
Dernière activité le 22 oct. 2021
Suivis
0
Abonnés
0
Activité totale
20
Votes
8
Abonnements
8
APERÇU DES ACTIVITÉS
BADGES
ARTICLES
PUBLICATIONS
COMMENTAIRES DE LA COMMUNAUTÉ
COMMENTAIRES SUR L’ARTICLE
APERÇU DES ACTIVITÉS
Dernière activité effectuée par Alex Kolodzey
Alex Kolodzey a ajouté un commentaire,
I see that it has been added as well, but it says it's for Enterprise only (in the update post). I am on Professional and can see the option. Does this option have no effect for me, then?
Afficher le commentaire · Publication le 15 déc. 2020 · Alex Kolodzey
0
Abonnés
0
Votes
0
Commentaire
Alex Kolodzey a ajouté un commentaire,
I agree. It would be useful to have feedback directed to the author by default.
Afficher le commentaire · Publication le 14 déc. 2020 · Alex Kolodzey
0
Abonnés
0
Votes
0
Commentaire
Alex Kolodzey a créé une publication,
As in the title: I would like to see Agents become Followers on tickets if another Agent takes the ticket.
The reason for this, is to ensure that agents don't "lose" tickets when they are handed off. Though agents should be proactive in transferring tickets, this does not always work and feels clunky given all the other automation that is available.
I can work around this partially, by creating a trigger that tests if the Assignee has been changed to the current user and then adding the current user as the Follower if so. This "works" by pre-emptively setting the follower so that it exists before a change of hands of the ticket. However, this only works if an Agent takes the ticket. If the ticket is assigned to an Agent by someone else, then this never occurs.
Ideally, the way I would like to see this implemented is an option similar to the pre-existing one for CCs to Followers in Admin>Settings>Tickets:
Something like "Automatically make old assignee a follower", which you can check to globally manage the setting.
Since triggers can detect "Change"/"Changed to"/"Changed from", it may also be useful to add something like "previous assignee" as something that Followers can be set to.
The only other work around I can think of, is making a trigger for every single agent where it tests "Assignee changed to " and then an Action of "Add Follower ". That would be too much to manage longterm.
Publication le 02 juin 2020 · Alex Kolodzey
8
Abonnés
8
Votes
4
Commentaires
Alex Kolodzey a créé une publication,
I would like to request that the Change tests (Changed, Changed to, Changed from, etc) be added for custom Drop-downs for triggers.
I was unable to find a similar topic, but I did find someone's comment that aligns with my request here.
We use Drop-down custom fields in tickets to categorize requests. These are generally manipulated by our support personnel only.
I would like to be able to send notifications when a Drop-down is changed, so that I can target the correct internal/external groups that need to receive a one-time notification of this event.
Right now, I appear to be limited to only Is/Is not/Present/Not present. This does not work for me, since it fires every time a ticket receives any update. I cannot restrict this to a Created ticket condition since these dropdowns are either A) not always selected on ticket creation and B) can be changed during troubleshooting.
For my needs I would appreciate being able to just set a condition for " Changed to ". I've reviewed some options for using tags but that just seems like a messy work around, and there is some risk that tags will be unintentionally edited by personnel during ticket updates. Additionally, even the tags associated with the dropdown can still only be tested as "Contains at least one of the following" or "Contains none of the following".
I realize this may not be straightforward since Drop-downs are probably lumped into all other "custom field" types, which these additional tests may not apply to. However, Drop-downs can already be used in specific tests to check their precise values so some differentiation must be possible, and "Changed" seems generic enough to apply to just about anything at a minimum.
Perhaps it requires its own topic, but maybe "Added"/"Removed" should be testable conditions for tags? That would potentially resolve my issue (since custom fields automatically add/remove tags) and other tag-related ones.
Publication le 12 mai 2020 · Alex Kolodzey
70
Abonnés
48
Votes
21
Commentaires