Vor Kurzem aufgerufene Suchen
Keine vor kurzem aufgerufene Suchen
Feature Request: Add "Changed", etc, trigger test for custom Drop-down ticket fields
Gepostet 12. Mai 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.
76
23 Kommentare
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
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
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
Jordan Cousins
How many up-votes does a suggestion require before Zendesk pays any meaningful attention to it?
2
John DiGregorio
I am really surprised this can't be done through a trigger or automation.
2
Suja Socrates
We would love to have this feature ASAP. Now we are writing a lot of custom code to accomplish this.
2
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
Viktor Hristovski
Ben Bauer , 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
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
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
Anmelden, um einen Kommentar zu hinterlassen.