Triggers & Automations - We want your feedback!

@bailey11
Yeah, we are using internal comments as tooltips for agents extensively. Regarding public comments, the usecase is following: when we automatically followup user, we want this information in the ticket, so the next agent who sees the ticket had full information about our communication with user. One way to achieve that would be the ability to add public comment to ticket: user will be notified, and ticket will have a full story. But this can also be achieved by internal note as a separate trigger action, so yes, public comments are not that viable for us while internal is critical.

Users in our instance are often created by our backend, with custom user fields populated. And when user creates a ticket, we need to show (to agents) those data from user custom fields among ticket fields. Of course, if it would be somehow possible to do with lookup fields, it would be enough for us. 

Thanks for the details @tommy12 !

Questions:

• Do you use triggers or automations more? Why? 

We use massively triggers and automations. We also use automations to manage the visibility of the ticket in the view and to show only ticket that have updates or are not managed from a certain time.

Our issue is the tickets that are not closed but have had more than 100 automation audits occur during the life of the ticket are excluded from the hourly automations run.

This limit is reached over the 50% of our ticket so this is the most product limitations that impact on our ticket management.

Use Cases:

We use massively the automations to hide and make visible the ticket inside the view. This has the advantage to show only ticket that have to be managed from our zendesk agents.

We assign the due date to the ticket an so we can manage the time when the ticket has to be present in a view.

The 100 automation audits occur during the life ticket limit is very restrictive product limitations.

The UI tells me if a particular trigger has issues. Points to a non existing ticket types.
It would be good to be able to get all these warnings via the api. Rather than have to manually look for all existing known issues if these could be found in one place that would be easier.

Do you use triggers or automations more? Why? 

• We use triggers way more - usually with time based, you set them up and rarely need to look at them again. Plus the UI is very clunky in automations vrs triggers

How often do you make changes to your triggers? 

• We make changes daily - we work on adding new workflows, troubleshooting, onboarding, etc. We have to edit a trigger at least once a day if not more

What is your most used condition in triggers?

• Trigger via tags or groups.  

Do you find yourself repeating this condition in multiple triggers due to product limitations? Do you find yourself repeating this action in multiple triggers due to product limitations?

• All the time - for example, you can't have multiple "Any" scenarios. So if you want this trigger to fire either Web form or email but not API, but only for these certain groups, you have to create a trigger for each channel
• Another limitation is that we use different signatures depending on the group. So we have to have multiple triggers for groups even though they essentially do the same thing. It would be better if it was a single trigger and then have statements where "if these groups/tags, use this action" and "if this group, use this action instead". we have 110+ triggers just for basic back and forth notifications

What is your most used trigger action? 

• Notify active webhook - we use this to set from addresses, add internal notes, look at profile, add parent/child ticket id, change ticket to another Zendesk instance, etc

Suggestions

• New automation conditions: Automation Time-Based Conditions – Zendesk help
• Schedule Trigger changes - ie. A lot of our changes are time sensitive and need to be coordinated. So someone is ready to test and the other is to click save. It would be best to schedule when to change so that only 1 is needed for the launch: Scheduled Trigger Activation/Deactivation – Zendesk help
• Ability to create a trigger in a deactivated state - too many times do I click enter and it publishes the trigger and then I need to go back and deactivate it
• Uniform UI for all changes - Views, automations, triggers
• Ability to report on when automations, triggers fire and the tickets they fire on
• When you are creating a trigger, it would be nice to be able to search for other triggers so you can compare your current trigger to another one without needing a separate window
• Ability to drag and drop conditions within triggers. Sometimes I create everything in the Any condition and need to move it to the All condition instead
• Ability to select trigger position - I have to search for a trigger to see what category it is in, unsearch, go to category then drag and drop trigger (which is difficult when there are 200+ triggers in a category. and then to find out it is in the wrong category too)
• Have a better description in audit log of changes to triggers
• Add Talk numbers as a condition - right now you have to use comment text which makes it impossible to use the filters to search for as it needs characters and can't search via numbers or symbols

UI/Navigation 

Conditions

+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 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.

@dan12 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.

Triggers and automations need some development on date field and custom date field functions.  

There are some basic functions such as "is within the next" or "is within the previous" but it is greatly missing the reverse of these which would be "is not within the next" and "is not within the previous".

Please add these functions.

@carmelo agreed on needing a list of tickets that triggers/automations ran on. The workaround we use is to have the trigger or automation add a tag to the ticket, prefixed with trigger_ or automation_ respectively, and then you can run searches on the tags. This is also how we apply and search on macros. It's not ideal since this should be a native feature, but it's the best we've been able to do so far.