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!
-
Hey Bailey Whitaker-Lea, we're always happy Zendesk pays attention to admin needs regarding business rules (or anything, really!). Admins are Zendesk's "unsung ambassadors" and it's great you're asking us how to improve these important core product features!
To answer your questions:
- Triggers just because of their nature (immediacy and execute on update; automations are limited as they only execute every hour and up to a max number of tickets).
- Depends on the type of trigger and how often workflows change, I guess? I've maintained over 1,200 at some point.
- Depends, but I'd say "Ticket is" (created/updated). On multibrand accounts, "Brand is" is also definitely used.
- No.
- Not really sure, but if I had to guess I'd say "Add tags".
- No.
Additionally, here's some personal feedback on improvements I'd like to see regarding business rules:
- Automations page. It's a crucial feature of the product and they're a bit obsolete, to be honest... Autos need an urgent update! Not just the automations page design, but automations also need version control/revision logs like triggers already have (I'd even argue Views and SLA policies should also have version control!)
- Triggers. Could be revamped and have multiple and/or conditions (see my post from a few years ago)
- Admins should be able to edit Closed tickets, even if only using business rules (as opposed to manually/in bulk). This is essential for proper data hygiene.
- Agent Workspace. We should have the ability to detect strings in messages via triggers (just like comments in 'classic'/email tickets), as well as being able to detect which user is messaging in the latest update (e.g. I usually add a tag to tickets in order to know who commented last, the requester or an agent; during a messaging conversation, this isn't possible).
- Create internal, admin-focused triggers based on system events (new group created, view/trigger/automation/etc deleted/created/etc), with the ability to notify with pop-ups (like Notifications app) or by email. For that to happen, we'd also need more complete and explicit audit log events, a feature that is still somewhat underwhelming (although the latest filtering ability is a time saver).
- Being able to identify business rules with invalid conditions, this would be a good use case for the admin trigger notifications mentioned in the previous bullet (i.e. as soon as a trigger condition is invalid, me or all admins would be notified).
- Trigger conditions and actions for suspended tickets
- Not necessary related to your post, but Skills-based routing should execute after triggers apply to tickets, not before. This is a crucial aspect that has frequently prevented me, as an admin, from recommending the feature entirely.
- Skipped tickets. Trigger condition for "Ticket is skipped".
- Change the ticket recipient ('sender address') via triggers or automations
Lastly, and looking at the most voted posts in the Community, some of these requests features:
- Add users as CC via Trigger or Automation (also to remove them)
- Ability to edit Closed tickets (also here)
- Customize home page (Support dashboard)
- Preserve Group in follow-up tickets
- Detect bounced emails
In general and to sum up, admins are hired and expected to conduct maintenance and clean-up tasks, whether one-off or periodical. Without a solid audit log event scheme and notification feature, we kind of have our hands tied to do a proper job, and have to resort to workarounds for things that (IMHO) should be present in the product already, so that we could focus on what's really important (the customer experience).
I do realize this comment is more of a Christmas list, and that not all is a priority or even planned on Zendesk's roadmap. Still, thank you for taking the time to review our needs!
-
Hi Pedro Rodrigues thank you for all the detailed feedback! These are great opportunities for the various teams at Zendesk to dig into. I'll work to route these to the appropriate PMs.
In terms of the Triggers & Automations related feedback here...
- Would you say that tags are being used most frequently because there is something you can't do with the current functionality?
- Automations is certainly on our list to tackle.
- Any chance you would be willing to share a specific use case of how you would use And/Or conditions? We are currently exploring ways to expand our logic and this will be really helpful.
- Triggers on system events is something we are exploring, but related to custom data, so this is a really interesting add. Thank you!
- When you think through how you'd want to be notified a business rule is no longer valid, what does that look like? A notification when modifying something that will impact a business rule? Or a banner on your triggers list page that tells you to go look at 'Rule 1'? Or solely the email notification you mentioned?
- What is your use case for triggers on suspended tickets? Are you just trying to categorize them, route them, something else?
- For skipped tickets as a condition, how will this help your workflow? This is actually a new one too, thanks!
I believe those are all the ones that live in my ownership area. Also, if you are up for it, there are additional questions in the linked form for more detailed feedback.
-
Hey Bailey Whitaker-Lea, thanks for posting this! I'm excited to hear what the team is cooking up and I'd be happy to volunteer for a feedback/investigation call if needed!
To answer your questions:- Triggers, by far. Most workflows require the system to be responsive to input, and as triggers execute immediately, they’re naturally more widely used. As Pedro Rodrigues said, Automations are limited to hourly execution and have a maximum execution limit. We also don’t know when in the hour they’ll run, which makes them harder to predict.
- Depends on volume and maturity of the workflow they power. New workflows usually get daily tweaks from user feedback and data review, mature flows or ‘core’ flows that affect all tickets seldom get adjusted.
- Usually Ticket is Updated, Tags contain(or do not contain) alongside Ticket Form (to ensure a workflow only applies to a certain type of ticket)
- Yes. It would be great to define a bundle of conditions that we could use in a repeatable manner (ex form is X, group is Y, and zodiac sign is Taurus) into a single selector for easy reuse. I usually just clone out a related trigger and tweak from there. It would make bulk updating triggers using same conditions MUCH faster. (This would also be insanely useful in Views).
- Send event to webhook (we push data to external services fairly often, mostly to Slack)
- Add tags
- Yes, often for webhook actions. It’s technically possible to do if/else conditionality in the webhook body using Liquid, but the mere existence of Liquid is proof there is a cosmic deity out there that thrives on our suffering. Even if you get it to work, it’s a huge pain to debug if anything goes awry, so it’s usually simpler and safer to avoid it, and just create duplicate triggers with one minor condition added for filtering. If proper if/else logic was possible to implement in a trigger, that would make things so much better!
(example: We CSAT our customers on a 1-5 scale, with 1-2 considered 'bad' , 3 as 'neutral' and 4-5 as 'good'. I need to send alerts to slack for those surveys when
Like Pedro, I have a wishlist of Triggers and Automation improvements that would make admin life so much easier.
- I'm sure you know this one already, but the Automations UI needs to be modernized, please. Even without features like versioning likes Triggers have, just the ability to search fields instead of a monster list every time would be a huge time and sanity saver. IMO, it's the second most painful UI in the entire platform today (dubious first place goes to Dynamic Content).
- Triggers and Automations have a disparity between being able to use a field as a condition and being able to use it as an action. This gave rise to the workflow of having Zendesk send itself an API call to set certain field types which can lead to other issues (ex: changing ticket requester, changing ticket received at email, set certain field types back to a null or empty state)
The types of operations available for certain field types needs to improve.
- For example, I have a numeric field type, we need to be able to test for is, is not, greater than and less than. Right now I have is, is not, present, not present.
- Text fields need to be able to search for a value more flexibily (is, is not, contains, does not contain, is changed). Today, we only the lovely choices of ‘Present, Not Present’.
- Date fields need to be able to understand the concept of ‘today’ as well in conditions. (Ex: date is before today).
- Every field type should also be possible to set back to an empty value (for an example, try setting a date field back to an empty value via a trigger action. You end up needing the aforementioned API workaround.
- Being able to have Zendesk surface or filter any rules that have invalid conditions (deleted fields, values etc.) would be really helpful, especially in multi-admin environments.
Again, super excited to hear that Zendesk is looking to improve this part of the product. Let me know if I can help further!
- Triggers, by far. Most workflows require the system to be responsive to input, and as triggers execute immediately, they’re naturally more widely used. As Pedro Rodrigues said, Automations are limited to hourly execution and have a maximum execution limit. We also don’t know when in the hour they’ll run, which makes them harder to predict.
-
I came across this great tool from a 3rd party which allows you to run a health check on most of the config including triggers and automations
I am surprised a similar tool isn't already a part of the standard Zendesk offering, could you please review and consider this for future development?
https://www.zendesk.com/marketplace/apps/support/863641/support-change-assistant/This app enables Zendesk administrators to quickly detect and fix broken references in Triggers, Automations, Views, Macros and Service Level Agreements (SLAs).
- Audit Triggers, Automations, Views, Macros and Service Level Agreements (SLAs) for broken references
- View a quick summary to show what needs your attention the most
- View a detailed line-by-line breakdown of each issue
- Navigate directly to the problem with a single click
- Filter results quickly isolate areas of interest
- Export results to easily get input from other stakeholders
-
Do you use triggers or automations more? Why?
Triggers, as others have said, because of the immediacy. I would move several existing triggers over to automations if I could have a greater level of control over when those automations execute — for example, if I could put a 10- to 15-minute delay on our "We received your request" acknowledgment email (which, in our case, includes AB suggestions), I would do that. I feel it may increase open rates instead of just being dismissed out of hand as "yet another bot-generated email." One hour seems a bit too long, and that's currently the minimum amount of time I can wait before executing an automation.
How often do you make changes to your triggers?
Weekly, and depending on seasonality, sometimes daily.
What is your most used condition in triggers?
Ticket creation, by a wide margin. We use a lot of tag-based logic as well, though.
Do you find yourself repeating this condition in multiple triggers due to product limitations?
Yes, we have many triggers with certain sets of conditions where the actions need to be slightly different on each, or vice-versa — tickets with many different sets of conditions, all with identical action sets.
What is your most used trigger action?
Setting the Form, and some of our custom fields. The form and one of our custom fields dictates everything about a ticket from who it gets routed to what Priority it's assigned, so we have to have a rule for every little thing that comes in so that it ends up with Form and (our custom version, not native) Ticket Type.
We also have a lot of "auto-solve" triggers, for tickets that we need to keep searchable for agents in our instance, but with no immediate action to be taken.
Do you find yourself repeating this action in multiple triggers due to product limitations?
Yep!
I agree with a lot of other users' wishes above, including modernizing the Automations UI and the fields it can take action on. This is my personal wishlist for Trigger & Automation improvements:
-
Trigger & Automation Actions upon SKILL.
We really really REALLY want to use Skills-Based Routing, but can't in current state because there's no way to automate the removal of Skills for certain special exception cases.
Skills work well only if 100% of tickets meeting certain conditions should have a certain Skill. If 5% of your tickets are exceptions that you want to write special Trigger rules for to swap out the Skills on that ticket… you can't.
We need to be able to reset ticket Skills when agents reassign or re-classify their tickets (by changing the Form, custom fields, etc) — must-have is by using Macros and Triggers, but potentially using Automations, too.
-
ELIF logic for Trigger Conditions.
For example, after the current section that says "Meets ALL," include an option to add an additional "Meets ALL" section apart from the first one.
This would really help us clean up our trigger list and eliminate redundancies, like our — no lie— 55! "Auto-Solve" triggers, which all have specific "Meets ALL" conditions and "meets ANY" simply won't cut it. Nearly all of these "auto-solve" triggers have identical actions.
-
Flag conflicts in the Trigger list with a warning.
This one is a pretty wild dream, but it would be an incredible improvement.
For example, if you have a rule at position 5 that adds a certain tag, and a rule at position 3 that checks for that same tag in its conditions, that's a potential conflict in your trigger firing order. Flagging those conflicts so that admins can easily identify and fix potential conflicts at a glance would be really great.
I'm currently tracking this using a Google Sheet of manually entered Conditions and Actions. Yes, it looks just as ugly as it sounds!
-
Trigger & Automation Actions upon SKILL.
-
Thanks for the great feedback Dan R. and Harper Dane !
Dan - your feedback validates quite a few improvements we are looking at. We are also considering expanding the data triggers can interact with, outside of the ticket. For Automations, I'm curious, is there a time interval you absolutely need? 15 minutes? Once at a specific date/time? The survey linked has some more detailed questions around use cases for the data being used in triggers as well as some of the enhancements you mentioned. It would be really helpful to have your input there too!
Harper - Interesting feedback around Skills! I know the Skills team has been working on ways to integrate with triggers, so I will make sure this use case gets routed to them. I absolutely hear you on the logic! We are actively working on enhancements in this area. Also, your last point would be a great tool for Admins. I'll add this to our feedback tool as we consider ways to help Admins identify issues with their workflows. I'd love to get your responses to the survey as well if you have the time!
Thanks all!
-
Bailey Whitaker-Lea
Thanks for replying, glad the feedback is helpful! I've filled out the survey!
As for automations, being able to do 15 minute increments would be really helpful. I don't think I'd realistically need shorter than that. Being able to have an automation only ever run once would be helpful, often I'll set them up to try to fix a data issue in bulk, but don't want it running forever.
Being able to see the timestamp of the last time the automation ran for the last X runs and a count of number of tickets affected would be really great too. -
Agree with Dan R on all of the above.
Increments as low as 15 minutes for automations would be a game-changer.
Seeing a log of tickets that a given automation has run on would also be extremely helpful (the same tool that we have for triggers at [instance].zendesk.com/rules/[triggerID]/tickets, but for automations).
-
Dan R. You're so fast!
I'll take a look at your survey responses and reach out via email as we kick off more in depth interviews.
Thank you again for the feedback, super helpful!
-
Bailey Whitaker-Lea
Triggers and Automations are near and dear to my heart so I'm happy to prioritize writing feedback that will help make them better! Also, Harper Dane I didn't know that feature existed, that's incredibly helpful! I wish that would be accessible easily from a trigger! -
Dan R. I just tested that firing log link and it turns out it actually works for automations as well, which I never realized before. Just paste your Automation ID number in, instead of the Trigger ID.
That said, this feature is hidden, not terribly user-friendly, and ZD Support has previously indicated to me that this firing lookup tool is deprecated and could go away at any time. That's all really a shame, as I use it on a near-daily basis and I'm certain I'm not the only one who finds it extremely valuable (or would... if people knew about it).
-
Hello
I would like to add to the feedback already given, with some repetitions (sorry)
1-We mainly use triggers because we need actions after an input/action rather than over time
2-We modify our triggers regularly, when a new use-case appears and we need to set up a new workflow. Or to improve triggers that were built at launch and were not optimised (as the years go by, our admin skills improve)
3-The most used conditions: "received at", "current user", "role" (requester) and "tags"
4-Yes, because it has already been written, we cannot create multiple groups of conditions and operators. We do it in other software (where we can sometimes switch to an advanced mode, to write complex conditions (as we already do in Explore for custom measures and attributes)).
5-The most used action: qualifying ticket fields and sending notifications
6-No, it doesn't seem to me
The conditions are missing usable data, especially in what I had noted to myself:
- Trigger:
o Submitter: we currently have a problem with setting up actions, especially when an agent or light agent transfers a customer's request to us, because this creates a ticket with the customer as the requester and the agent appears in a second comment just after, but it is impossible to create the conditions for action. If we had the Sumitter, we could do something
o We have the same problem with the impossibility of creating criteria to have a defined action on transferred calls. But here I don't know what data exists.
o On the domains or organisations: because we have a problem with the creation of an organisation with certain generic domains and it is impossible to create an alert notification for the follow-up
o Recipient (Ticket email address) : As said by others we had to set up an API call to get around this very big problem when a ticket goes from one department to another and the exchange has to continue via another email address (so that the next requests go directly to the right team)
- Automatism :
o The condition for searching a text on a ticket comment does not exist (can only search on the first comment "Description")
And for the Administration part, already said but being able to identify business rules with invalid conditions is very important. Some invalid conditions may be due to users who have left, I will see more at least a tab or a filter that allows you to display the rules that contain errors.
Thank you for asking our opinion.
-
To complete my feedback, another lack in the triggers in particular, are the conditions especially on phone calls. I don't know about the other channels other than email, but for telephony for example, we don't have specific triggers, so we have to go and look for text to identify the line called, we don't have triggers for IVR choices either...
댓글을 남기려면 로그인하세요.
13 댓글