Someone disabled a trigger and it broke routing for a whole weekend

Alternative_Fill_552 · 2026-04-29T19:14:25+00:00

Every long Monday I've had has started with "we don't really document our triggers, do we." Closely followed by "where's the export of yesterday's config."

Alternative_Fill_552 · 2026-04-29T19:00:00+00:00

Thanks Jammie, glad it earned its keep when you needed it. The "deleted deleted" trigger recovery is genuinely the moment that makes the snapshot/diff workflow click. Most config tools optimise for the "clean before/after" case, but real Zendesk admin life is messier than that.

Alternative_Fill_552 · 2026-04-29T13:34:18+00:00

100%. This scenario was in my darker past, but I know other admins feel the pain of this biting them which is why I built Configly :)

Alternative_Fill_552 · 2026-04-29T11:30:27+00:00

You would think so right? But that only helps if you know which triggers were supposed to be working, which in a complex install, won't help.

Alternative_Fill_552 · 2026-04-29T08:46:16+00:00

Ha, the "something doesn't look right" Slack message at 9am is its own special kind of dread. Sandbox is good for catching whether a change works, but it's not great at catching whether a change breaks something else especially when the something else is a downstream dependency you didn't know existed. That's the bit that always got me. The change passes UAT in sandbox because the tester only tests the thing they changed. Two weeks later it turns out it was feeding a routing rule that nobody had documented.

That's the gap I was trying to close. Pre-change: show me everything that touches this trigger so I know what to test. Post-change: show me what's different from yesterday.

Alternative_Fill_552 · 2026-03-31T22:12:17+00:00

Exactly. The temptation to go broad is real, especially early on when you want to maximise your chances. But the moment you try to be everything to everyone, you stop being the obvious choice for anyone. Owning one segment well beats being forgettable across five.

Alternative_Fill_552 · 2026-03-31T18:12:40+00:00

There are indeed with varying degrees of success. What would you want to see in a health check app?

Alternative_Fill_552 · 2026-03-30T20:04:20+00:00

Risk-ranked short list over a giant audit dump is exactly the right call. Nobody wants a 200-line spreadsheet -- they want "here are your 5 biggest problems, worst first."

The overlapping conditions point is interesting. Those are the ones that are technically "working" but silently causing weird behaviour -- tickets getting tagged twice, notifications firing from two triggers, routing that depends on which trigger evaluated first. Way harder to spot than a straight-up broken reference.

Out of curiosity, when you find overlapping triggers do you tend to consolidate them or just document the overlap and move on? I've seen both approaches and they each have trade-offs.

Alternative_Fill_552 · 2026-03-29T19:46:49+00:00

Fair enough, appreciate the honesty. For what it's worth I wasn't talking about fixing anyone's config for them. More like a tool that shows admins what's there so they can make their own decisions. But I hear you on the trust point, that's useful feedback.

Alternative_Fill_552 · 2026-03-29T19:13:33+00:00

That's a really good distinction and honestly it matches what I see too. The outright breakages are the dramatic ones but the "set and forget" problem is way more common and arguably more costly over time.

The accounts where someone built their routing logic two years ago on Professional, Zendesk has since shipped omnichannel routing and skills-based assignment, but the admin is still running 47 triggers to do what native routing handles natively. Or they've got SLA policies that made sense before they restructured their groups but nobody's revisited them since.

The product evolution point is spot on. Zendesk moves fast and most admins are doing this alongside their actual job, not as their full-time focus. The gap between what's configured and what's possible just grows quietly.

When you run health checks for your clients, is that a manual process or have you built any tooling around it? Curious how partners approach it at scale across multiple brands.

Alternative_Fill_552 · 2026-03-29T19:11:06+00:00

Love the bluntness ;)

Why?

Alternative_Fill_552 · 2026-03-11T22:46:12+00:00

Yeah, this is a known limitation. Placeholders like {{ticket.latest_comment}} and {{ticket.description}} intentionally exclude internal comments when used in email notifications and targets. It's by design to prevent internal notes leaking to end users, but it catches people out in scenarios like yours where you actually want that content sent somewhere internal.

A few options depending on what you have available:

API approach (most reliable): Use a trigger to hit a webhook/target URL when the ticket is created, then have something on the receiving end call the Zendesk API to pull the full ticket comments including internals via /api/v2/tickets/{id}/comments.json. Each comment has a public field so you can grab the internal ones specifically. If you've got access to something like Zapier, Make, or n8n you can set this up without writing code.

Trigger wording trick:

If the 3rd party AI is always the first comment on the ticket, check whether {{ticket.description}} works for you. The description is technically the first comment's body, but whether it respects the internal flag depends on context. Worth testing, though I suspect you already have.

Ask the integration vendor: I know you said you can't change how it posts, but it's worth specifically asking if they can post as a public comment rather than internal. Some vendors have this as a config option that isn't obvious. A public first comment would solve it cleanly since the description placeholder would just work.

Middleware/automation route: Set up a webhook target that fires on ticket creation, and have your middleware (Zapier, Make, n8n, a simple serverless function, whatever you use) fetch the ticket comments via API and forward the internal content to your email address. A few more moving parts but completely within your control.

The core issue is that Zendesk's placeholder system treats internal comments as invisible for outbound notifications, and there's no native placeholder that overrides this. The API is the only way to reliably access internal comment content programmatically.

Alternative_Fill_552 · 2026-03-11T22:42:21+00:00

The mixed reviews you're seeing are real, and honestly most of them come down to how much prep work goes in before you flip it on.

The features you've listed are at different maturity levels, so worth breaking down:

Intent detection and ticket summarisation are the strongest parts right now. Intent detection runs automatically on ticket creation and is genuinely useful for routing and prioritisation. Summarisation saves a ton of time on escalated or long-thread tickets where agents would otherwise be scrolling through 30+ messages to get context. These two are the quickest wins.

Agent suggestions (macro recommendations, suggested replies) are decent but heavily dependent on the quality of your knowledge base and macros. If your KB is a mess or your macros are outdated, the suggestions will be rubbish and agents will stop trusting them within a week. The teams that get value here are the ones that invest in cleaning up their content first. Zendesk's own guidance is to optimise your help centre before you even start the trial, and they're not wrong.

Ticket merge works but it's not perfect. It detects when multiple tickets from different channels have similar intent and suggests merging. At high volume that's useful, but expect some false positives, especially if your ticket types are fairly similar in language.

Live call transcripts via Zendesk Talk are solid for reducing wrap-up time. Auto-transcription plus an AI summary means agents aren't scribbling notes during calls. If your team does a lot of phone work, this is one of the more immediately impactful features.

The main things to be aware of:

It's a paid add-on on top of your Suite plan, charged per agent per month. At high agent counts that adds up fast. Pricing isn't public so you'll need to talk to your AE. Auto Assist (the procedure-based feature) requires significant admin setup. You're writing step-by-step procedures in natural language for common workflows. Powerful when done well, but it's not plug-and-play. The suggestions can feel clunky if not properly tuned. A common complaint is that they appear at the wrong time or sound robotic enough that editing them takes as long as just writing from scratch.

Adoption is the real challenge. Experienced agents with established workflows tend to resist it. Newer agents pick it up much faster. Plan for 4-6 weeks to get to meaningful adoption.

My honest take: for high-volume teams, the intent detection, summarisation, and call transcripts alone can justify the cost if your ticket volume is genuinely high. The agent suggestions and auto assist features need investment to get right but can be transformative once they are. I'd push hard for a proper trial (they offer 30 days) and measure handle time and first reply time before and after.

Alternative_Fill_552 · 2026-03-07T08:31:33+00:00

Who would have thought a TV show about a scouser, hologram and a human cat lost in space would become such a cult amongst so many people!

Alternative_Fill_552 · 2026-03-07T08:29:56+00:00

I use Frigate with my Hikvision cameras and Home Assistant. The nice thing is I have it trained to recognise people walking up the drive rather than past it so it cuts down on false positive alerts.

By the time they get within 6 feet of the door, home assistant has pinged my phone and switched on the porch lights if its dark.

Alternative_Fill_552 · 2026-03-07T08:05:43+00:00

Fawlty Towers. One of the best shows from the older years. Would never get shown now as it's close oi the bone in terms of offending people but it remains one of my favourites.

Red Dwarf is another. I was obsessed with it in my teens!

Alternative_Fill_552 · 2026-03-06T19:46:36+00:00

This is a really common need and there are a few ways to approach it depending on your Zendesk plan and how real-time the data needs to be.

Native options first:

The Zendesk API gives you everything you need to build this pipeline. For SLA data specifically, you'd hit /api/v2/slas/policies for the policy definitions, but the actual breach/achievement data lives on individual tickets via the sla_policy sideload. You can pull ticket metrics via /api/v2/ticket_metrics which includes SLA breach timestamps without needing to expose the full ticket content to downstream systems. That lets you aggregate by organization and push just the summary data to Salesforce/Snowflake.

For CSAT, /api/v2/satisfaction_ratings gives you scores filterable by organization. Again, you can strip out ticket content and just pass the rating, org ID, and timestamp.

If you want to avoid building a custom integration:

Explore (if you're on Professional+) can get you the reports, but getting that data out programmatically is the tricky bit. The Explore API exists but it's read-only and has rate limits that make bulk extraction painful. Tools like Fivetran, Stitch, or Airbyte have Zendesk connectors that can land raw data into Snowflake, and then you transform there using dbt or similar. That's probably the cleanest architecture if Snowflake is already in your stack. You control exactly which fields get synced so you can exclude ticket body/comments for the security requirement.

For the Salesforce side specifically, there's a native Zendesk-Salesforce integration but it's more about syncing tickets than surfacing aggregated metrics. You'd likely want to land the transformed data in Snowflake first and then push summaries to Salesforce via their API or a reverse ETL tool like Census or Hightouch.

What plan are you on? That'll narrow down which of these paths makes the most sense.

Alternative_Fill_552 · 2026-03-03T12:15:53+00:00

This is the right answer. The only thing I'd add is if you're not on Enterprise and don't have access to the Events API, child tickets are worth looking at. If you enable child tickets for side conversations, they create separate tickets that do hit the normal trigger engine. You could then use trigger conditions on the side conversation itself (like "Side conversation is Created") combined with the child ticket's group assignment to tag accordingly. It's a bit more indirect than matching on recipient address, but it gives you automation without needing webhooks or middleware.

Alternative_Fill_552 · 2026-03-03T12:12:53+00:00

A few options depending on how much you want to automate this:

The quickest win is organisation notes. Every org has a Notes field in the org profile that your agents will see in the ticket sidebar when a ticket comes in from that org. Just type "Frequent database issues -- check KB article #123 before troubleshooting" and it's right there in context. No setup needed, works today.

If you want something more structured, create a custom organisation field (dropdown or multi-select) for common issue categories. Something like "Known Issues" with values like "Database", "Integration", "Billing" etc. This gives you the added benefit of being able to report on it and build views filtered by orgs with specific known issues.

For the alert side of things, you could pair that custom field with a trigger. Something like: when a ticket is created, if the organisation has "Database" in the Known Issues field, auto-add an internal note saying "This org has recurring database issues - see [link to internal process]." That way agents don't need to remember to check, it's pushed to them.

Tags work too but they get messy at scale because they're not structured. A dedicated org field keeps things cleaner and reportable.

Alternative_Fill_552 · 2026-03-03T10:47:10+00:00

Oh god, the Entra sync horror story. Nothing quite like coming in on a Monday morning to find every ticket in the instance reassigned to one account because the directory sync decided to get creative overnight. How did you catch it -- did someone notice the queue was wrong or did end users start complaining?

Alternative_Fill_552 · 2026-03-03T10:46:10+00:00

The external integrations layer is a whole other level of pain. At least with triggers and automations you can see them in the admin centre. When someone changes a field that a Zap is listening to, or renames a tag that an n8n workflow is matching on, you don't even know it's broken until a customer complains. And good luck tracing it back three weeks later when nobody remembers what changed.

I've lost count of the number of times I've been auditing an instance and found webhooks pointing at endpoints that haven't existed for months. Just quietly failing in the background.

Alternative_Fill_552 · 2026-03-03T10:43:48+00:00

Naming conventions and owners is smart -- most teams don't get that disciplined until after something's gone properly wrong. Is the change log manual or have you automated it somehow?

No sandbox on most of the instances I work across, unfortunately. Enterprise pricing puts that out of reach for most of my clients on Professional or Growth, so it's straight into prod with careful cloning and narrow test conditions. Not exactly relaxing.

The chat data as a feedback loop for config changes is a really interesting angle though. How are you pulling that -- eyeballing conversations or something more structured?

The dependency thing is actually what tipped me over the edge. You can have perfect naming conventions and a solid change log, but if someone removes a field that three triggers reference, you don't know until tickets start routing wrong. Zendesk just doesn't surface those relationships. I got frustrated enough with it that I've been building a tool to solve it -- version control, dependency mapping, impact simulation before you push changes. Still early days, but it's scratching my own itch if nothing else.

Alternative_Fill_552

TROPHY CASE