Recent searches
No recent searches
Feature Request: Add "Changed", etc, trigger test for custom Drop-down ticket fields
Posted May 12, 2020
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.
70
21 comments
Nicole Saunders
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.
0
Heather Rommel
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.
0
Suja Socrates
We would love to have this feature ASAP. Now we are writing a lot of custom code to accomplish this.
2
Christopher Rehn
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.
1
Viktor Hristovski
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
5
Ben Bauer
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):
Example trigger list
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.
0
Viktor Hristovski
@... , 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
1
Kirill Akimov
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.
4
Anthony Stenhouse
+1 A Trigger firing when a drop-down selection changes would allow us to send targeted Slack notifications and improve our workflows.
0
John DiGregorio
I am really surprised this can't be done through a trigger or automation.
2
Jordan Cousins
How many up-votes does a suggestion require before Zendesk pays any meaningful attention to it?
2
WRO Jacuk-Zurak, Marta
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
0
Christian Degn Andreasen
+1 for this!
0
Monica
Adding my support to this request as well. Being able to make target when a field is changed is crucial for automations and triggers to not create workarounds (triggers/tags) or manual agent actions (another field to say the first field was changed set by a macro).
1
Stephen
+1 this is definitely a feature that needs to be considered.
0
Tommy
Yeah, missing feature for sure
0
Jonathan Perel
They have a “Custom ticket field change events” in the Support App API, but no way to trigger on a changed custom menu field. Seems like some very basic missing functionality. I wouldn’t hold my breath on it being implemented any time soon (original request is from 2020), so a custom app is likely the only solution.
https://developer.zendesk.com/api-reference/apps/apps-support-api/ticket_sidebar/?_ga=2.103234624.1572339015.1698554393-220321896.1698273118#custom-ticket-field-change-events
0
Daniël Nieuwendijk
👆This feature would be a great improvement to Triggers. I run into this limitation regularly, when I just want to fire a trigger when a certain custom field is changed. Please add the tests that are already available for system fields also to custom fields:
3
Shawna James
Hey everyone, thank you for taking the time to provide us with this product feedback. We apologize for the delay on our end in providing you with a response to the feature request.
I work in managing our customer product feedback forums and have been in communication with the product team that owns this area. They noted the following: this is a great feature request and we have added it to the backlog for future consideration. This means that we will think about adding it as a priority later in our planning cycle. We are going to leave this post open for comment to allow others to provide their feedback and use cases, however please note as is stated in our Community Guidelines that we can not commit to prioritizing any one piece of feedback we receive in the community.
If you are interested in learning more about this and other features being built please make sure to check out and follow our Community events, What’s New Community Topic, and Zendesk Updates. Again, we apologize for our delay and appreciate you being a valuable Zendesk Community member.
Thank you again for your feedback and for being a valuable customer with Zendesk.
0
Lindsey Rhyne
+1, any update?
0
Sid DeVins
We would also love to have this feature. Tons of our workflows are either needlessly complex or can't be implemented at all because of this limitation.
0