Making changes directly to your live customer service environment is risky. One misconfigured trigger or broken automation can disrupt support operations and frustrate customers. That is why Zendesk offers sandbox environments, separate testing spaces where you can experiment safely before deploying to production.

This guide breaks down everything you need to know about Zendesk sandbox vs production environments. You will learn how each works, when to use them, their key differences, and best practices for managing both. We will also cover how tools like eesel AI let you test AI agents in sandbox before connecting them to your live help desk.
What is a Zendesk sandbox?
A Zendesk sandbox is a test environment that replicates your production configurations and data. Think of it as a safe playground where you can test changes without any risk to your live operations.
When you create a sandbox, Zendesk takes a point-in-time snapshot of your production instance. This includes your tickets, business rules, user data, and configuration settings. The replication process copies up to 10,000 tickets along with their associated end users, giving you realistic data to work with.
Here's what gets replicated into your sandbox:
- Tickets and conversations up to 10,000 tickets with the first 100 comments per ticket
- Business rules triggers, automations, views, and macros
- User data agents and end users (emails are anonymized to @example.com for privacy)
- Configuration brands, ticket fields, groups, custom roles, and organizations
- Templates and branding email templates, welcome emails, and brand colors
The key thing to remember: your sandbox is a static snapshot. It doesn't stay synchronized with production after creation. Changes you make in sandbox stay there, and changes in production don't flow back to sandbox automatically.
What is a Zendesk production environment?
Your Zendesk production environment is the live, customer-facing instance where real support happens. This is where your agents handle actual tickets, where customers submit requests, and where all your business-critical operations run.
Production contains live data, active integrations, and real customer communications. Every change here has immediate impact. Update a trigger, and it starts firing on real tickets immediately. Modify a webhook, and it starts calling live APIs. Change a business rule, and it affects actual customer experiences.
This makes production the source of truth for your support operations. It's also why you want to be careful about what changes you make directly here. Testing in production might seem faster, but when something goes wrong, your customers feel it immediately.
Key differences: Zendesk sandbox vs production
Understanding the differences between these environments helps you use each one appropriately. Here is how they compare:
| Aspect | Sandbox | Production |
|---|---|---|
| Data synchronization | Static snapshot at creation | Live, constantly updating |
| Risk level | Zero risk to customers | High risk, affects real users |
| Email handling | Anonymized (@example.com) | Real customer emails |
| Webhooks | Deactivated by default | Active and firing |
| API tokens | Must be recreated | Persist as configured |
| Ticket archiving | Auto-archive after 3 days | Persistent storage |
| SMS support | Not available | Full channel support |
| AI agents | Two auto-created for testing | Live AI agent interactions |
The email anonymization is particularly important. Zendesk automatically converts all user emails to @example.com domains in sandbox. This prevents accidental emails to real customers during testing. Administrators can reverse this for specific test accounts if needed, but the default protects you from embarrassing mistakes.
Webhooks present another key difference. They are replicated into sandbox but set to inactive by default. This prevents your sandbox from accidentally triggering live API calls to external systems. You can manually activate them for testing, but the default inactive state keeps you safe.
When to use sandbox vs production
Knowing which environment to use for different tasks keeps your operations smooth and your customers happy.
Use sandbox for:
- Testing new workflows and triggers before they go live
- Training new agents on realistic data without risking customer interactions
- Experimenting with integrations and custom apps
- Customizing Help Center themes and testing changes
- Validating AI agent configurations before customer-facing deployment
- Testing configuration changes during change management processes
Use production for:
- Day-to-day customer support operations
- Live agent interactions with real customers
- Real customer communications across all channels
- Active business processes that drive revenue
- Time-sensitive support requests requiring immediate attention
The rule of thumb is simple: if customers would see it or be affected by it, test it in sandbox first. Only deploy to production after you've verified everything works as expected.
Plan availability and limitations
Not every Zendesk plan includes sandbox access. Here is what is available:
| Plan | Sandbox Access | Details |
|---|---|---|
| Support Team ($19/agent/month) | Not included | No sandbox available |
| Suite Team ($55/agent/month) | Not included | No sandbox available |
| Suite Professional ($115/agent/month) | Add-on | Available for additional purchase |
| Suite Enterprise ($169/agent/month) | 2 sandboxes | Two sandboxes included |
| Support Enterprise | 1 sandbox | One sandbox included |
Source: Zendesk pricing page
Even with sandbox access, there are important limitations to understand:
- Maximum 10 replications per month you can only create or refresh sandboxes 10 times monthly
- 90-day inactivity deletion sandboxes are automatically deleted after 90 days without use
- No automatic sync data does not flow between sandbox and production after creation
- Manual deployment required changes in sandbox must be manually recreated or deployed to production
The replication limit matters if you are actively developing and testing. Plan your sandbox refreshes carefully, especially if you have multiple team members working in the environment.
Best practices for sandbox-to-production workflows
Managing the flow from sandbox to production smoothly requires some discipline. Here are practices that work:
Document everything you change. Keep a running log of configuration changes made in sandbox. When it is time to deploy to production, this documentation becomes your checklist.
Use Configuration Management for deployment. Zendesk now offers native configuration deployment through snapshots. Save a snapshot of your sandbox, create a deployment, select the configurations to move, and deploy with automatic backup. This is much safer than manual recreation.
Consider third-party tools for complex environments. For teams managing multiple Zendesk instances or complex configurations, tools like Salto offer advanced deployment and synchronization capabilities.
Refresh sandboxes regularly. Since sandboxes are point-in-time snapshots, they get stale quickly. Schedule regular refreshes to keep your testing environment current with production.
Export custom themes before deleting. If you are replacing an old sandbox with a new one, export any custom Help Center themes first. Themes are lost during sandbox replacement.
Test AI agents in sandbox first. Before connecting AI tools to your production help desk, verify their behavior in sandbox. This includes testing response quality, escalation rules, and integration points.
Testing AI agents safely with eesel AI
AI agents represent a significant change to how support teams operate. Testing them thoroughly before customer-facing deployment is essential.

eesel AI integrates with Zendesk to provide AI agents that handle frontline support. The platform learns from your past tickets, help center articles, and macros to respond in your brand voice. You can define escalation rules in plain English and connect to external systems via API.
This is why sandbox testing matters for AI agents:
Train on historical data safely. eesel AI learns from your ticket history to understand your tone and common issues. Testing this training in sandbox lets you verify the AI understands your business context before it interacts with real customers.
Run simulations before go-live. The platform can run simulations on past tickets to show how the AI would have responded. This gives you concrete metrics on response quality before deployment.
Progressive rollout control. You can start with the AI drafting replies for agent review, then gradually expand to autonomous responses as confidence builds. This "start supervised, level up to autonomous" approach minimizes risk.
Test integrations without risk. If your AI agent connects to external systems (like Shopify for order lookups), sandbox testing ensures these integrations work correctly before going live.
The combination of Zendesk sandbox and eesel AI gives you a complete testing environment. You can validate AI behavior, fine-tune responses, and verify integrations without any risk to your production support operations.
Frequently Asked Questions
Share this post

Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.



