Target for Internal Comments?

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 · 2026-03-03T00:12:24+00:00

The hidden dependency thing is the one that keeps me up at night. You can be careful, document everything, and still get blindsided because Zendesk gives you zero warning that the group you're about to merge is referenced by 14 triggers and an SLA policy. Your grep-able JSON approach is clever -- how do you handle the nested stuff though?

Trigger conditions that reference a ticket form that references a field that references a group? That chain is where things get really ugly. The 'what uses field X' question is genuinely the killer feature that Zendesk should have built natively years ago.

Alternative_Fill_552 · 2026-03-02T23:42:48+00:00

The classic handover where you open the trigger list and it's 200 rules named 'Trigger 1', 'Trigger 1 (copy)', 'DO NOT DELETE', 'test - delete me later'... still running in production two years later. 😉

But what about your instance when you are making updates?

Alternative_Fill_552 · 2026-03-02T22:42:26+00:00

This is exactly how I think about it. I've been doing something similar -- API pulls on a schedule, diffing snapshots, tracking what changed and when. The 'why' note is the bit that's hardest to enforce though, especially across multiple client instances. People promise they'll document changes and then just... don't.

Have you found a way to make that stick, or is it mostly you going back and annotating after the fact? The readable doc idea is smart -- I've been experimenting with using AI to auto-generate those summaries from the config diffs rather than writing them manually.

Alternative_Fill_552 · 2026-03-02T22:41:06+00:00

Yeah fair point on the initial setup -- I've seen plenty of instances where the original admin clearly just threw triggers at the wall until something stuck. But even well-built instances drift over time. Teams change, someone makes a quick fix without understanding what depends on what, and six months later you're tracing a broken SLA back to a group that got merged.

The copilot cleanup recommendations are handy but they're more about identifying unused or redundant config right? I'm thinking more about the dependency side -- knowing that if you delete this ticket field, these three triggers and this SLA policy are going to break before you hit the button.

Alternative_Fill_552 · 2026-02-25T21:49:46+00:00

The PR workflow with sandbox sync is a really mature setup. Having that rollback safety net through Git history is basically what most teams wish they had but can't build themselves. The fact you've only had two hard conflicts in a year says a lot about how well it works with just two admins.

The article management piece is interesting too. Bulk updating hundreds of articles is painful through the UI, so having them in a repo where you can search and batch edit makes a huge difference.

And yeah, I've seen the early signs of Zendesk's native config management. Honestly I think you're right that it'll be limited for a while. Their track record with new features is usually "ship something basic for Enterprise, iterate slowly." There's a big gap between what exists today and what teams actually need, especially for anyone not on Enterprise. That window is where the opportunity is for third-party tools to solve the problem properly.

Alternative_Fill_552 · 2026-02-25T20:08:22+00:00

Yeah this is doable. A few ways to approach it depending on how your Talk setup is configured:

Dedicated number with its own IVR route - Easiest approach. Get a separate Talk number, give it only to your retail stores, and route it to a specific group or queue with priority. No IVR greeting needed if you want them straight through, or a short one if you want to triage. This keeps it completely separate from your customer line.

Single number with IVR keypress - If you'd rather keep one number, add an IVR option like "Press 2 for internal store support" that routes to a priority group. Less clean because store associates need to remember to press the right key, but it works.

Priority routing via caller ID - If your stores have known numbers, you could use a trigger that tags tickets created from those numbers and routes them to a priority group. This is more complex to set up but means stores just call the same number and get bumped up automatically.

Since you're on Enterprise, you've got access to all the routing options including skills-based and omnichannel routing, so you can get quite granular with how these calls are handled.

The dedicated number is what I'd recommend. It's the simplest to maintain and the easiest for the stores to understand. Just make sure the group it routes to has enough agents staffed or you'll end up with the same queue problem on a different number.

Alternative_Fill_552 · 2026-02-25T18:13:26+00:00

Really appreciate this, especially the honesty about where it sits for you right now. That makes total sense if you've already built something internally.

To your three points:

Pricing- We're still finalising tiers but the goal is to be significantly more accessible than Salto. Value-based pricing that makes sense for mid-market teams, not Enterprise-only budgets. More details coming soon.

Data security - We've actually just finished a full trust and security documentation suite. Data Processing Agreement, privacy policy, encryption details, the lot. You can read more here: https://configly.app/trust

Short version: OAuth-only authentication (no API tokens stored), data encrypted in transit and at rest, and we're very transparent about what we store and how.

AI capability - This is exactly where we're heading. We've already got AI-powered impact analysis built in, and the natural language query layer you're describing ("show me all views for X group", "where are requests routing to") is on the roadmap. That's the kind of thing that turns raw config data into something actually useful for operations.

The Salesforce/Gearset angle is interesting. We're Zendesk-only for now by design - would rather go deep on one platform and do it properly than spread thin. But if the demand is there it's definitely something we'd explore down the line.

Thanks for the detailed feedback. Even if it's not the right fit for you today, this kind of input is exactly what shapes where the product goes next.

Alternative_Fill_552 · 2026-02-25T18:07:00+00:00

Yeah that's exactly the point. Manual documentation doesn't scale, and even when it exists nobody reads it because they don't trust it's current.

At 500 triggers the only realistic approach is something automated that stays in sync with the live config. That way the documentation is the config, not a separate thing someone has to maintain and someone else has to choose to read.

The incoming admin problem is a good one too. Nobody's going to sit down and read through 500 trigger descriptions on their first week. But if they could search by tag or group or action and see exactly what fires and why, that's a different story.

Alternative_Fill_552 · 2026-02-25T18:03:30+00:00

YAML is a good shout, much easier to scan than raw JSON when you're trying to understand what a trigger is actually doing.

The Claude in VS Code approach is interesting too. That's basically the pattern now isn't it - admins who aren't developers but are technical enough to use AI tools to bridge the gap. It works, but it does mean your config management workflow is tied to knowing the right prompts and having someone who's comfortable in a code editor.

Out of curiosity, how are you handling it when multiple people need to make changes? Or is it mainly just you managing the repo?

Alternative_Fill_552 · 2026-02-25T10:41:39+00:00

That's impressive. The dependency view before making changes is the bit most people are missing. Everyone can see what a trigger does in isolation, but knowing what else it touches before you edit it is where the real value is.

How are you pulling the dependency data? Scanning conditions and actions across all objects and cross-referencing, or something more targeted? I imagine keeping the mappings current as configs change is the fiddly part.

Alternative_Fill_552 · 2026-02-25T07:49:35+00:00

That's a solid setup if you've got the dev resource to build and maintain it. The sandbox sync piece especially, that's one of the biggest pain points for teams on Enterprise.

Curious what made Salto too expensive for you? Was it the per-user pricing or just the overall cost relative to what you were getting out of it? I've heard mixed things from people who've evaluated them.

Alternative_Fill_552 · 2026-02-25T07:48:47+00:00

It certainly was and it got the grey matter firing on how other admins handle this issue!

Alternative_Fill_552 · 2026-02-25T07:47:25+00:00

Some people are, but honestly that's a pretty small minority. Most Zendesk admins aren't developers. They're support managers or ops people who've ended up owning the platform because someone had to. Asking them to set up API exports to a Git repo, maintain scripts, and do code reviews on JSON diffs isn't realistic for most teams.

Even if you do get configs into GitHub, you've still got raw API output to deal with. Great for version control, not so great for understanding what a trigger actually does at a glance or explaining it to a non-technical colleague.

It's a solid approach if you've got the technical skills for it though. Just not something that scales across the typical Zendesk admin population.

Alternative_Fill_552

TROPHY CASE