Feature Request: Add "Changed", etc, trigger test for custom Drop-down ticket fields
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 "<custom field> Changed to <field value>". 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.
-
Thank you for taking the time to post this detailed feedback, Alex, and welcome to the Zendesk Community!
If other users like this idea, please up-vote Alex's post and add any details you can in the comments below. -
I know what you mean on this one. The only thing I can think of as a workaround is to create a new field to capture the old value of the field you want to trigger on. Then you'd need to set up a bunch of triggers to auto set the old field value.
Them you could base your triggers on those two fields.
Clunky but it should work. -
We would love to have this feature ASAP. Now we are writing a lot of custom code to accomplish this.
-
This feels like a basic standard feature that would benefit us a lot.
My workaround today is adding a tag when the trigger fires, and having that tag as a requirement for "does not exist" upon firing. However, this does not help for Triggers that may need to fire more than once, but not always.
-
We also need this option, we are using the jira-zendesk integration and id like to notify the assignee when a jira status changes. I have the statuses setup in a dropdown field
-
Our workaround has been to take a custom dropdown field and write a trigger for each item in the dropdown. Of course, as mentioned above, this can grow to a large volume of custom code. I definitely agree that custom dropdown fields should have the "changed" condition added.
Example dropdown list (with tags):- route to Team A (last_a)
- route to Team B (last_b)
- route to Team C (last_c)
Example trigger list
- If dropdown is "Team A" and tags don't include "a", then add internal notes, assign to group A, and add tag "a"
- If dropdown is "Team B" and tags don't include "b", then add internal notes, assign to group B, and add tag "b"
- If dropdown is "Team C" and tags don't include "c", then add internal notes, assign to group C, and add tag "c"
An example ticket where agents use the custom dropdown field to route from A to C to B will have these tags:
a, c, b, last_b
The one remaining gap in this approach is that you can't have the triggers fire additional times for a single value. For example, if the custom dropdown field goes from A to C and back to A again, then the trigger doesn't fire on the 2nd execution of A. You could remedy this by having each trigger remove every other tag in the set. Of course, that would make adding new values to the custom dropdown a giant pain, because you'd have to update the full set of triggers. And you'd lose the psuedo-history of having all the tags added.
-
@... , what I did was assigned tags to each of the values of the dropdown field. Like your team A , team B and team C with their tags . Then i set additional triggers to add another tag as a copy of the value of the tag. So like if the ticket has team A tag, add teamAcopy tag also.
Then in another set of triggers , i examine if the ticket has lost the original tag, but has the copy tag.
So if the ticket contains teamAcopy but doesn't contain teamA, i add a tag which i named Teamchanged and remove the teamAcopy. Basically, if your dropdown has 3 fields, you need 6 tags for this logic.Once this is done, i do the main action (like notify the team etc) based on the Teamchanged tag
-
Hey, Zendesk Team!
I'd like to join the discussion as we have the same problem but with Text fields. It would be cool if we have a possibility to track the fact that any of custom ticket text field is being changed and notify the assignee about that. This is vital feature for jira-zendek integration. -
+1 A Trigger firing when a drop-down selection changes would allow us to send targeted Slack notifications and improve our workflows.
-
I am really surprised this can't be done through a trigger or automation.
-
How many up-votes does a suggestion require before Zendesk pays any meaningful attention to it?
-
Hello,
+1 for this idea. We got situations where the value in a custom drop-down changed, and we would like to assign the value back or notify people or webhooks.
This feature "changed to"/"changed from" would help us
Thanks
Por favor, entrar para comentar.
12 Comentários