Búsquedas recientes
No hay búsquedas recientes

Alex Kolodzey
Incorporación 15 abr 2021
·
Última actividad 22 oct 2021
Seguimientos
0
Seguidores
0
Actividad total
20
Votos
8
Suscripciones
8
RESUMEN DE LA ACTIVIDAD
INSIGNIAS
ARTÍCULOS
PUBLICACIONES
COMENTARIOS DE LA COMUNIDAD
COMENTARIOS DE ARTÍCULOS
RESUMEN DE LA ACTIVIDAD
Última actividad de Alex Kolodzey
Alex Kolodzey hizo un comentario,
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?
Ver comentario · Publicado 15 dic 2020 · Alex Kolodzey
0
Seguidores
0
Votos
0
Comentarios
Alex Kolodzey hizo un comentario,
I agree. It would be useful to have feedback directed to the author by default.
Ver comentario · Publicado 14 dic 2020 · Alex Kolodzey
0
Seguidores
0
Votos
0
Comentarios
Alex Kolodzey creó una publicación,
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.
Publicado 02 jun 2020 · Alex Kolodzey
8
Seguidores
8
Votos
4
Comentarios
Alex Kolodzey creó una publicación,
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.
Publicado 12 may 2020 · Alex Kolodzey
70
Seguidores
48
Votos
21
Comentarios