Required Fields in Macros

Thank you everyone for continuing to upvote this. This is not on our roadmap for this year, so I have changed the status of this to Not Planned, for now. We are going to leave this post open for comment to allow others to provide their feedback and use cases, however please note as is stated in our Community Guidelines that we can not commit to prioritizing any one piece of feedback we receive in the community.

This year we have a lot of exciting investments in product capabilities planned. Join us next month at Relate to find out more. You can attend in person or stream the product keynote online.

Thank you again for your continued feedback, it's really appreciated.

It's pretty surprising that this is not a native feature. I can't imagine a support organization that doesn't use customized language in their emails and doesn't want to send {FILL IN} to a customer. Why isn't this supported?

Upvoted! I came here to write a post about this exact thing.

Pedro's suggestion is great (thank you for that, btw!), but I would love to see this as a native option when you're creating a macro. We already have the ability to use placeholders in a macro. Perhaps, we could use a blank placeholder (a la TextExpander) and have a checkbox or something on the macro's edit page for [✔] entry required to submit ticket.

An omnichannel agent might forget to take the workaround placeholders we use in macros (like INSERT REASON HERE or ENTER ID HERE), especially if we're slammed and they're burning through emails and other interactions. And with thousands of agents, we may not catch these mistakes as often as we'd like. Better to cut agents off at the pass and prevent them from submitting the ticket.

Oh that's an interesting solution! Thanks!

Hello 423740402353, I agree that this would be a really useful feature.

There may be a workaround that allows you to control this, but it will only work for email-based communications (this is because comments added to Facebook and WhatsApp are sent to the requester immediately by Zendesk).

Create a new trigger and position it above all the triggers that notify the requester.

Conditions (ALL)

• Ticket is updated
• Comment is public
• Current user is agent
• Tags contains none of the following: admin_macro_mistake 
• Comment contains the following string: XYZ

Note: this example works if all your macros have 'XYZ' for the agents to fill in. You can use "Conditions (ANY)" if you have more variable expressions, for example "(INSERT NUMBER)", "(FILL THIS IN)", and so on.

Actions

• Add tags: admin_macro_mistake

You can add more actions to the new trigger, of course, depending on how you want to follow-up on these cases.

In any case, if a ticket includes this tag then it probably means that the agent applied a macro and forgot to replace the text.

To prevent the requester from receiving the comment, you can add a 'Tags contains none of the following' condition to your triggers that notify the requester, in order to exclude 'admin_macro_mistake':

Consequently, the notify requester trigger won't be fired:

Additional trigger (reset the mistake; optional)

What if the agent later applies the macro correctly, and we still have the tag applied to the ticket? We probably want to remove it!

My suggestion here would be something like the following example (please make sure it's positioned after the first one):

---

This workflow works best if your variable text is always the same (for example, 'XYZ'), so if possible, please consider standardizing that variable expression, and use it across all your macros when applicable.

Also, consider your 'notify requester' trigger placeholder. If the requester receives...

• ...all public comments in the ticket, then it's probably best if you convert the incorrect public comment to an internal note before adding another comment.
• ...just the latest comment, then it's 'safer' because the requester will only receive the last public comment (you can still convert the incorrect comment to internal note, of course!)

Hope this makes sense! In the meantime, I've given your suggestion an upvote :-)