Zendesk triggers are used to react to ticket changes and execute workflows on these tickets. Change status, update ticket fields and forms, execute webhooks, or add comments or internal notes on those tickets.

Where triggers focus mainly on tickets, Zendesk also has Messaging triggers in the Admin Center that work solely on Messaging conversations. These triggers are an evolution of the old Chat triggers and they react to the status of conversations before they reach an agent

You can trigger Messaging triggers when a customer starts a conversation, when a message is send, or when a conversation is added or removed from an Omnichannel Routing queue. Once triggered, you can use conditions like source, day, availability to decide to act on those conversations.

If your trigger applies you can then tag the ticket, send a message to the customer, alert them of average wait times and so on.

However, once a messaging conversation reaches your agents, reacting to tickets created via the Messaging channels happens in the regular Triggers.

Until recently the options there were limited. Even though you could react to ticket updates (e.g. a customer has responded), there were no messaging specific elements in those trigger conditions. That is, until now.

Messaging session state

New this month is the introduction of a Messaging Session State condition in Zendesk Triggers. This new condition can react to, you've guessed it, the state a conversation is in.

A conversation can have three states:

• Active: The customer is actively reacting to the conversation within the Zendesk widget or social channel.
• Inactive: after ~10 minutes of inactivity the conversation turns to inactive. This signals the agent that the customer has left the page, minimized their browser, locked their mobile phone etc.
• Ended: the agent has either pressed the end session button in a conversation, or solved the ticket

With the new Messaging Session State condition, we can now react to these statuses.

Set an inactive conversation to Pending

One trigger we can create can automatically put inactive conversations to the Pending status. This will pause any running SLA's and remove the ticket from an agents' Active tickets view or allow the agent to get new tickets reassigned via Omnichannel Routing.

Set an active conversation to Open

If such an inactive conversation turns active again, for example the users opens the webpage again or starts typing, we can react to this change and reopen the ticket again. This will make the ticket reappear in Agent Home, and signal an update by the customer. Your SLA however will only start running if the customer actually replies.

Log conversations ended by an Agent

There's a third status, ended, which fires if an agent manually ends the current conversation. This new End Session button was recently added as a feature (and can be activated via the Messaging Settings in Admin Center).

Pressing End session will stop the conversation and redirect the customer back to your AI Agent or, of no AI Agent is setup, will create a new ticket for further replies from the customer.

This end session step is not really signaled in the ticket UI though. You can open the Events view and see the ended session action there, but otherwise there's no real signal to other agents that someone quit the conversation.

With the new session trigger conditions you could however add an Internal Note to the ticket that does let others know that an agent manually ended the conversation.

A note on Omnichannel Routing

It's important to note that even those Messaging state conditions are useful, they are not the only way to react to those changes. If you have enabled Omnichannel Routing in your instance (you should!) part of the functionality described above is also natively available as part of Capacity release .

By enabling auto-release you cannot only remove inactive tickets from agents' capacity, but you can also automatically set the status of those conversations to Pending.

Deciding which approach you take depends on your setup.

If you want all tickets to be treated equally and just move all of them to pending upon going inactive, it's easiest to just enable the Omnichannel Routing auto-release option.

But for some scenario's you might want to have a more granular approach. You might, for example, want to un-assign and put to pending basic support tickets, but keep complex tickets and sales conversations assigned to the current agent until the issue is resolved.

With the triggers you can add conditions and only move (and unassign) some tickets, while leaving other tickets untouched.

Similarly, you could also use these triggers in a different way. You could for example lower the priority of inactive conversations. Or you can use automations to only solve inactive conversations after 4 hours.

Either way, I do like the fact that we can interact with more and more elements of Messaging conversations.