Triggers & Automations - We want your feedback!
Zendesk admins, we're interested in improving triggers and automations, but would like to hear from you first. Specifically, we're exploring ways to add support for referencing new data in triggers and automations and making conditional logic more flexible. We'd like to hear how these enhancements might change and improve your workflow.
Questions:
- Do you use triggers or automations more? Why?
- How often do you make changes to your triggers?
- What is your most used condition in triggers?
- Do you find yourself repeating this condition in multiple triggers due to product limitations?
- What is your most used trigger action?
- Do you find yourself repeating this action in multiple triggers due to product limitations?
Please let us know your thoughts in the comments below.
Use Cases:
We would like to hear your use cases in more detail, but understand that can be sensitive information. If you're open to sharing more information, please use the following form:
https://forms.gle/MqN1CdZ5nq2bwRBT6
Thank you for sharing your feedback as we work to improve your experience!
-
Do you use triggers or automations more? Why?
- Triggers way more. There are only a set number of time-based events that I need to take care of. most of the time, I need to apply actions to real-time events.
How often do you make changes to your triggers?- Almost daily, if not daily. This is in part to expanding scope of some teams so we need to tweak and improve as we go. Sometimes it's edits for other reason (new branding, new text in notifications, new integrations with internal tools, etc.)
Feedback:UI/Navigation
- Consistency! Creating/updating a macro, trigger, view, or automation is not the same set of clicks for each. Same for grouping and reordering.
- Sometimes I'm working on a rather lengthy trigger, either because of the conditions, or the content of a notification - especially when working out a JSON payload or liquid markup text. I need to be able to save and continue, without being booted back out to the menu and having to search for my trigger again. (This is especially annoying for macros and views).
Conditions
- We need more flexibility in the conditions. If/then, and case switches would be great.
- We need comparison options on numeric and decimal fields (<, >, =, >=, <=) so we can route, notify, assign, whatever based on those values.
- Automation actions and conditions - they all start with "ticket: xxxxxx", so I can't find anything by starting to type "group" or the label of a custom field, like I can for triggers. That means I have to squint and scroll and scroll and scroll to find the condition or action I'm looking for, especially if I need it for a custom field.
Troubleshooting
- I need to know which tickets a trigger ran on. The count of runs in the last 7/30 days is great, can't that link to a list of those tickets?
- Better troubleshooting for triggers and automations. Would be great if we could step through conditions, highlight a match to a condition for a ticket, or use a real ticket to test against a trigger/automation (without actually running on it). It's not always easy to figure out why a trigger/automation ran/didn't run when I was expecting it to/not to.
Other/Nice-to-have
- The byte limit of 8192 in a notification content. We use a third party survey tool and we embed a code in our email notifications for surveys. I'm limited in what I can do because of the byte limit. For example, if I wanted to use liquid markup to send one type of survey in one scenario and an other for a different scenario, I can't because embedding code for two surveys busts the limit. There are other (but similar) use cases where I've hit the byte limit.
-
+100 on Carmelo's comment about being able to see what tickets a trigger or automation ran on. Having the count displayed in the trigger list link out to a (filterable) list of affected tickets would be incredible.
Carmelo Rigatuso I ran into that 8192 byte limit in the past, you can work around it by having your HTML/Liquid content that exceeds 8192 bytes stored in Dynamic Content blocks. The trigger then calls the Dynamic Content block instead, whose placeholder is well under the limit.
You can also nest dynamic content instead other dynamic content, but the UI for organizing and sorting is pretty bad, so it's not recommended for sanity-preserving reasons. -
Dan R. Bold of you to assume I have any sanity left to preserve ;) Thanks for the tip on the byte limit workaround, I'll check it out.
Iniciar sesión para dejar un comentario.
33 Comentarios