Zendesk Trigger Naming Best Practices | Community
Skip to main content

Zendesk Trigger Naming Best Practices

  • March 22, 2019
  • 5 replies
  • 0 views
J

If you’re a Zendesk user, you may very well have 10s, 100s, or perhaps even 1000s of Triggers. They provide a useful function, but as they grow in number, it can become increasingly difficult to visually navigate through the list and find them.

There is a recent article that suggests creating “blank triggers” to provide an improved level of organization. The approach feels wrong for two reasons:

  1. The introduction of “blank triggers” feels hacky. Admittedly, most any approach is to some extent a hack trying to work around the lack of any in-app organization.

  2. It continues to make use of the default Zendesk trigger naming convention, which I believe can be improved.

On point #2, the default naming scheme used by Zendesk is to describe the action taken (e.g. “Notify requester of comment update”). For the last several years, I’ve taken the approach of naming triggers by the event that… triggers them. Make sense? I think so. Here are some examples:

  • Ticket > Created
  • Ticket > Created > Without Group
  • Ticket > Created > Priority Urgent
  • Ticket > Updated
  • Ticket > Updated > Assignee Changed
  • Ticket > Updated > New Comment > Public
  • Ticket > Updated > New Comment > Private
  • Ticket > Closed
  • Ticket > Reopened
  • Ticket > Solved

In my experience, this has multiple advantages:

  1. It’s easier to scan

  2. It may reduce the number of triggers needed, as you can have multiple actions defined for any given triggering event(s).

  3. For me, it’s easier to think about by the triggering action. YMMV.

It’s not a perfect solution. It still requires manual sorting to keep them grouped together. Hope that helps, and let me know what you think.

    5 replies

    A
    • Anonymous
    • March 22, 2019

    We've got eight brands, thousands and thousands of tickets, so we need to use both:

    • Section separators named "=======XX-SECTION=======" with dummy conditions (ticket is created, if tags contain "qwerty123456789", delete tags "qwerty123456789")
    • Naming convention: "BRAND :: C/U :: GROUP :: CHANNEL :: ACTION" (where C stands for Created, U for Updated). Any "untouchable" triggers begin with "ADMIN :: (...)".

    Although I do understand the "hackiness" of the section separators (false triggers), they do come in handy since I can sum those sections up in internal documentation, explain their purpose, etc. Any admin will then understand why a specific trigger must be placed within a specific trigger family, and by having them we also avoid trigger positioning mistakes.

    I'd be happy to learn about other methodologies, however!

    J
    • Justin39
    • Author
    • March 22, 2019

    Pedro: That's a good point. The combination of both approaches may be best, or at least the best we can do with current features.

    A
    • Anonymous
    • July 4, 2019

    For me, it's still very early days with Zendesk. I've been creating my macros, triggers, automations, tags and shortcuts (chat) and been labelling them with a letter number system (e.g. C1 is the trigger that happens when someone uses the widget to request a cancelation, R2 is the macro I use for international returns. etc). 

    I've made a Sheet with a tab for each of these (Macros, Automations, Triggers, Tags, Shortcuts) which I've called MATTS (acronym) and is where I plan to track what each of them does, when they are used, last updated and if they are active or not.

    For tags, from what I've read in the community, there's no way to see all tags you've created, so I wanted to keep track of them as I made them. I also used a naming convention for them so that all tags in the same family start the same (e.g. return_reason_fit, return_reason_style etc)

    Since management seems difficult within Zendesk, I figured a master document would be the best option, but like I said it's early days for us and we'll be starting small, so not sure if this is scalable. 

    Brett13
    • Brett13
    • Community Manager
    • July 5, 2019

    Thanks for sharing this Fiona :)

    Dylan20
    • Dylan20
    • July 5, 2019

    I'm not as organised as you guys, but I've stated to add some organisation to my triggers.

     

    I'm following some principles of software design where I think of triggers as functions. I make sure to keep each trigger small and focused, then use an action verb and a short description of what it does.

    eg. [Notify] Requester of comment update

    [Assign] to Tech Support

    Terms & ConditionsCookie settingsAccessibility statement