Zendesk ticket requesters vs submitters: What's the difference?

If you have ever looked at a Zendesk ticket and wondered why there are two different fields that seem to mean the same thing, you are not alone. The requester and submitter fields confuse a lot of support teams, and the distinction matters more than you might think.

Let's break it down. The requester is who the ticket is for. The submitter is who created the ticket. Most of the time these are the same person, but when they're different, understanding why can save you from reporting headaches and workflow mishaps.

Here's what you need to know about each field, when they diverge, and how to use them effectively in your support operations.

What Is a Ticket Requester in Zendesk?

The requester is the person asking for support. They're the one with the problem that needs solving.

For most businesses using Zendesk, the requester is a customer. But requesters can also be agents in your organization. Maybe an internal employee submitted a ticket to your IT help desk, or an agent escalated something on behalf of a colleague.

The requester field matters because:

• They receive all ticket communications Every public comment, status update, and resolution notification goes to the requester
• They determine ticket visibility In Zendesk's customer portal, users can only see tickets where they're listed as the requester (unless they're in a shared organization)
• They drive business rules Your triggers, automations, and views often filter or act based on the requester
• They can be changed If a ticket was created for the wrong person, agents with proper permissions can update the requester field

The key thing to remember is that the requester defines who the support interaction is for, not necessarily who initiated it.

What Is a Ticket Submitter in Zendesk?

The submitter is the user who actually created the ticket. This is the person who clicked "Submit" or sent the email that became a ticket.

By default, the submitter of a ticket is the same as the requester. When a customer emails your support address or fills out your web form, they are both asking for help and creating the ticket. So both fields get populated with their user record.

But here's the critical difference: the submitter cannot be changed after the ticket is created. Once that ticket exists in your system, the submitter field is locked.

The submitter field matters for:

• Internal accountability Knowing which agent created a ticket on behalf of someone else
• API and integration tracking Identifying which system or user account created tickets programmatically
• Audit trails Understanding the true origin of a support request
• Workflow routing Some organizations use submitter data to route or categorize tickets

Think of the submitter as the "paper trail" field. It tells you who (or what) actually opened the ticket, regardless of who it's for.

When Requester and Submitter Are Different

So when do these fields actually diverge? Here are the most common scenarios:

Call center agents creating tickets from phone calls

A customer calls your support line. The agent helps them and creates a ticket to document the interaction. The customer is the requester (they needed help), but the agent is the submitter (they created the ticket).

Executive assistants submitting on behalf of executives

An assistant fills out a support form for their manager. The executive is the requester, but the assistant's user account is the submitter.

Internal IT help desks

An employee walks over to the IT desk and asks for help. The IT staffer creates a ticket. The employee is the requester, the IT staffer is the submitter.

API and integration scenarios

Your CRM, chatbot, or form integration creates tickets automatically. The end user is the requester, but the integration's service account or OAuth client is the submitter.

This last scenario is where a lot of confusion happens. Developers building integrations sometimes expect to set the submitter to the end user's ID, but Zendesk assigns the submitter based on the authentication credentials making the API call. If your integration uses a service account, that account becomes the submitter for every ticket it creates.

How to View and Change the Requester

You can find the requester field in the ticket properties panel on the right side of any ticket in the agent workspace. It's one of the primary fields displayed near the top.

To change the requester:

1. Open the ticket in Zendesk
2. Click on the requester field (it may show as a dropdown or editable field depending on your permissions)
3. Search for and select the correct user
4. Save your changes

Not all agents can change requesters by default. Administrators need to enable this permission in Admin Center:

1. Go to Objects and rules > Tickets > Settings
2. Click CCs and followers on tickets to expand
3. Check Allow agents to change requester
4. Save

Changing the requester affects who receives notifications and who can see the ticket in their customer portal. It does not affect the submitter field, which remains locked.

How to Identify the Submitter for Reporting

Unlike the requester, you cannot change the submitter. But you can use this field for reporting and filtering.

In Zendesk Explore, the Tickets, Updates history, and SLAs datasets all include attributes about the submitter. You can create reports showing:

• Which agents create the most tickets on behalf of customers
• What percentage of tickets are submitted by end users vs. agents
• Trends in ticket creation sources over time

To filter tickets by submitter role in Explore:

1. Create a new query in the Tickets dataset
2. Add a filter for Submitter role
3. Select the roles you want to include or exclude

This is particularly useful for internal help desks that want to track how many tickets are created by agents versus submitted directly by employees through self-service channels.

Common Mistakes and How to Avoid Them

Assuming requester and submitter are always the same

This leads to confusion when tickets appear to come from agents but are actually for customers. Always check both fields if you're unsure who a ticket belongs to.

Not tracking submitter for internal accountability

If your agents frequently create tickets on behalf of customers, you might want to track this. Consider creating a custom field or using tags to identify tickets created by agents versus customers, especially if you need this data for performance metrics.

API integrations using the wrong field

Developers sometimes try to set the submitter ID when creating tickets via API. This doesn't work the submitter is determined by the authentication credentials. To set who a ticket is for, use the requester field instead.

Confusion in business rules

Make sure your triggers and automations reference the right field. A trigger that fires based on "current user is requester" behaves very differently from one based on "current user is submitter."

Best practice: When in doubt, use requester for customer-facing logic and submitter for internal tracking or audit purposes.

Streamlining Your Ticket Workflow With eesel AI

Understanding the difference between requester and submitter is just one piece of managing an efficient support operation. The bigger challenge is handling all those tickets efficiently once they hit your queue.

That's where we come in. At eesel AI, we've built an AI teammate that integrates directly with Zendesk to handle the heavy lifting of ticket management.

Here's how we help:

• Autonomous ticket resolution Our AI Agent can handle frontline support tickets end-to-end, from reading the request to sending the response. Mature deployments achieve up to 81% autonomous resolution.
• Intelligent triage AI Triage automatically tags, routes, and prioritizes tickets based on content, not just keywords. It understands what customers actually need.
• Consistent handling The AI learns from your past tickets, help center, and macros to respond in your voice and follow your policies.
• Progressive rollout Start with the AI drafting replies for review, then expand to full autonomy as it proves itself.

The best part? eesel learns your business in minutes, not weeks. Connect us to your Zendesk instance and we immediately understand your tone, common issues, and workflows from your existing data.

If you're looking to reduce ticket volume, speed up response times, and free your human agents for the complex issues that actually need them, try eesel AI for Zendesk.