Zendesk Trigger Naming Best Practices

5 Kommentare

  • Pedro Rodrigues
    Aktionen für Kommentare Permalink

    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!

  • Justin Pease
    Aktionen für Kommentare Permalink

    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.

  • Fiona
    Aktionen für Kommentare Permalink

    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. 

  • Brett - Community Manager
    Aktionen für Kommentare Permalink

    Thanks for sharing this Fiona :)

  • Dylan Cunniffe
    Aktionen für Kommentare Permalink

    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


Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.

Powered by Zendesk