Set ticket form, group, and custom fields dynamically on AI-agent-only (native_messaging) tickets

Related products:AI

Forum|Forum|2 months ago
June 12, 2026
2 replies
80 views

Please give a quick overview of your product feature request or feedback, and note who in your organisation is affected by this issue [e.g. agents, admins, customers, etc.]

Provide a supported way to set ticket form, group, and custom fields on AI-agent-only messaging tickets (native_messaging) that resolve without escalating to a human, scoped dynamically per bot, procedure, or tag. This affects admins (who can't configure workflows for these tickets), agent teams and team leads (who rely on correct form and group routing), and operations/reporting staff (who need accurate Explore data). In our large, multi-brand instance, it touches every team we put on AI messaging.

What problem do you see this solving?

It would let bot-resolved conversations carry the correct form, owning group, and source field so they can be routed and reported on accurately, instead of landing as read-only tickets we can't classify. It would also let AI messaging scale to multiple teams that each require a different form.

When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur, and how does this impact your business?

This affects us daily, on every chat our bots fully resolve, which is a large and growing share of our messaging volume. Most recently, when a team asked us to log their AI-resolved chats to a dedicated form with the right group and a "Ticket source" field, we found no supported path: triggers and automations don't run on these tickets, and the AI agent's Update ticket info action can't set the form. The only lever, reordering the account-level forms list, would force one form onto all AI tickets and break the triggers and automations built on our current default, so it's unusable for us. The impact is that an extensive and increasing volume of AI-resolved tickets can't be classified into the correct form, and because the tickets are read-only, they can't be corrected afterwards either, leaving a significant blind spot in our volume and CSAT reporting.

Are you currently using a workaround to solve this problem? (If yes, please explain)

For group and custom fields, yes: the AI agent's Update ticket info CRM action can set them during the conversation. For the ticket form, there is no workaround at all, because these tickets are fully read-only: not even an admin can change the form (or anything else) after the fact, so the form stays permanently incorrect on every AI-resolved ticket.

What would be your ideal solution to this problem? How would it work or function?

Add "ticket form" as a settable field in the AI agent's Update ticket info CRM action, alongside the existing group and custom-field support, scoped per bot, procedure, or tag, and applied at ticket creation without requiring escalation. Reusing the mechanism that already sets group and fields keeps it consistent and avoids depending on triggers, which don't run on these read-only tickets.

PanKe

I'd treat this as a classification and reporting gap, not just a routing gap.

The hard part here is that once a ticket is resolved by the AI agent, admins can't correct the form afterwards. If triggers and automations don't run at that point, using the global default form is really only a temporary workaround and can have knock-on effects for existing routing and reporting.

A cleaner fix would be to let the AI agent set the ticket form alongside group and custom fields, scoped by bot, procedure, or tag, before the ticket is finalized. That keeps the ticket classification close to the source and avoids forcing every AI workflow to share one account-wide default.

Until then, I'd keep a separate audit or export of bot-resolved tickets by bot, procedure, brand, and entry point. It won't fix the ticket form itself, but at least it gives the reporting team something to reconcile against.

Panke | Founder, RuleScope | https://rulescope.offshoot-labs.com

Claudiu-TudorAuthor

Contributor

Thanks, PanKe, and I agree on all points. ‘Classification and reporting gap’ is the better framing, and the read-only aspect is the part I'd underline: it's not that the form is awkward to set up, it's that it's permanently uncorrectable. Even as an admin, I can't touch the ticket afterwards, so whatever is wrong at creation stays wrong forever.

Your point about the global default form matches our situation exactly. We already have a default form with a substantial layer of triggers, automations, and workflows built around it, so promoting a chat-specific form to the top of the list would disrupt existing logic across the instance. And it doesn't scale: the moment a second team is onboarded onto chat and needs a different form, there's no lever left.

On the separate audit as an interim measure, I went and tested it, and unfortunately it doesn't appear to be available either. These tickets don't surface in the Support - Tickets dataset in Explore at all: the only channel values returned are NULL, API, Email, Side Conversation and Web. There is no native_messaging (or messaging) value, so the AI-agent-only tickets simply aren't there to report on. The AI agents datasets don't fill the gap either, since AI agents - Essential is conversation-level (Conversations, Generative answers, Satisfaction) with no ticket-level metrics or attributes to join on, and the other two are legacy Flow Builder datasets rather than AI Agents Advanced.

So the picture is a bit worse than a routing or classification gap: we can't set the form at creation, we can't correct it afterwards because the ticket is read-only, and we can't reconcile it later because the tickets don't reach standard ticket reporting. There's nothing to reconcile against.

That makes your proposed fix even more the right shape: let the AI agent set the ticket form alongside group and custom fields, scoped by bot, procedure, or tag, before the ticket is finalised. Getting classification right at the source is the only point at which it can be got right at all. Appreciate you adding your use case.

Claudiu-Tudor Jude | Zendesk Certified Administrator, Expert

Sign up

Login with SSO

Login to the community

Login with SSO