Zendesk SLA policy filter conditions: A complete guide

Getting your SLA policies wrong in Zendesk means either drowning your team in unreachable targets or letting critical tickets slip through the cracks. Both scenarios end the same way: frustrated customers and stressed agents.

The filter conditions you set for each SLA policy determine which tickets get which service level agreements. Get this right, and your team has clear, achievable targets. Get it wrong, and you're either over-promising or under-delivering.

This guide walks you through everything you need to know about Zendesk SLA policy filter conditions. You'll learn the available condition types, how to structure them for different scenarios, and best practices that keep your SLAs working for you rather than against you.

What are Zendesk SLA policy filter conditions?

SLA policy filter conditions are the rules that determine which tickets a particular service level agreement applies to. Think of them as the gatekeepers: when a ticket matches the conditions, the SLA policy activates and starts tracking against its targets.

Every filter condition in Zendesk follows the same structure: a field to check, an operator to compare with, and a value to match against. Here's what that looks like:

{ "field": "type", "operator": "is", "value": "incident" }

Filters are organized into two logic arrays:

The order of your SLA policies matters. Zendesk evaluates them from top to bottom and applies the first policy whose conditions match. This means your most specific policies should sit at the top, with broader, catch-all policies at the bottom.

Policy metrics define what you're actually measuring: first reply time, next reply time, resolution time, and so on. Each metric can have different targets based on ticket priority. You can also choose whether to count business hours only or calendar hours around the clock.

Available Zendesk SLA policy filter condition types

Zendesk provides an extensive range of conditions for targeting tickets. These fall into two categories: conditions shared across business rules (triggers, automations, views, and SLAs) and conditions specific to SLA policies. For complete technical details, see the Zendesk Conditions Reference.

Shared conditions

These conditions work across SLA policies, triggers, automations, and views:

SLA-specific conditions

These conditions are only available in SLA policy filters:

The distinction between via_id and current_via_id is worth noting. The via_id condition checks how the ticket was originally created, while current_via_id checks how the most recent update was made. This matters if you want to differentiate between tickets that started as email versus those that moved to chat, for example.

How to create effective Zendesk SLA policy filter conditions

Building SLA policies that actually work requires planning. Here's a practical approach.

Step 1: Plan your policy structure

Before touching Zendesk, map out your support structure:

• What customer segments need different response times? (VIP, enterprise, free tier)
• Which channels have different expectations? (chat versus email)
• Do different ticket types warrant different treatments? (incidents versus questions)
• Which teams handle what kinds of work?

This mapping becomes your policy structure. Each unique combination gets its own policy.

Step 2: Navigate to the SLA policy builder

In your Zendesk Admin Center, go to Objects and rules > Business rules > Service level agreements. Click Create policy to start building. For detailed setup instructions, refer to the official Zendesk SLA policy documentation.

Step 3: Configure your filter conditions

Start with the "All" conditions. These are your mandatory criteria. For example, if this policy applies to VIP customers only, add: Organization is "VIP Customers".

Then add "Any" conditions for optional criteria. You might want the policy to apply if the ticket is tagged "urgent" OR comes from a specific organization.

Common condition combinations include organization-based filtering for customer tier SLAs, group-based filtering for team-specific internal SLAs, channel-based filtering for different response expectations, and tag-based filtering for flexible routing.

Step 4: Set up your policy metrics

Choose which metrics to track for this policy:

Set targets for each priority level. A common starting point is:

Choose business hours if your team doesn't provide 24/7 support. This ensures you're only counting time when agents are actually available to work.

Common Zendesk SLA policy filter condition examples

Theory is helpful, but concrete examples make implementation easier. Here are four common scenarios.

Example 1: VIP customer policy

For customers with premium support contracts:

All conditions:

• Organization is "VIP Customers" OR Tags include "premium-support"

Metrics:

Place this policy at the top of your list so VIP tickets get caught before your general policies.

Example 2: Channel-specific policies

Different channels have different expectations. A chat conversation demands faster response than an email.

Messaging policy (All conditions):

• Via is "Chat" OR Via is "Messaging"

Email policy (All conditions):

• Via is "Email"

Set your messaging targets more aggressively than email. Customers expect near-instant response in chat but are more patient with email.

Example 3: Internal team SLAs with Group SLAs

Group SLAs track internal team performance rather than customer-facing metrics. They're available on Enterprise plans only.

Group SLA filter:

• Group is "Tier 2 Support"

The only metric available for Group SLAs is Group Ownership Time, which measures how long a ticket stays with that group before being solved or reassigned.

Example 4: Escalation path for incidents

Critical incidents need strict tracking:

All conditions:

• Priority is "Urgent" AND Type is "Incident"

Add Periodic Update targets to ensure customers receive progress updates even before resolution.

Best practices and troubleshooting for Zendesk SLA policy filter conditions

Even well-planned SLA policies can run into issues. Here's how to avoid common pitfalls.

Policy ordering

The most common mistake is poor policy ordering. Remember: Zendesk applies the first matching policy and stops looking. If you have a specific policy for VIP customers, it must appear before your general "all tickets" policy.

Recommended order:

1. VIP/enterprise customer policies
2. Specific channel policies (chat, phone)
3. Specific ticket type policies (incidents)
4. General policies (catch-all)

Proper ordering ensures the right tickets get the right service levels.

Using triggers with SLAs

One effective pattern is using triggers to set ticket priority before SLA evaluation. This simplifies your SLA conditions.

For example, create a trigger that sets Priority to "Urgent" if:

• Subject contains "outage" OR
• Organization is "VIP Customers"

Then your SLA policies can simply filter by priority rather than managing complex condition combinations.

Testing before going live

Always test new SLA policies with sample tickets before activating them. Check that:

• The right tickets match the right policies
• Policies are applying in the correct order
• Targets are realistic based on historical data

Common issues and solutions

For additional troubleshooting tips, check out these SLA policy best practices.

Managing SLAs at scale with AI

As your support operation grows, manually managing SLA policies becomes harder. You need to monitor performance, spot trends, and adjust targets based on real data.

This is where AI-powered tools can help. At eesel AI, we specialize in making support operations more efficient through intelligent automation.

Our AI can analyze your ticket content and automatically suggest priority adjustments before SLA evaluation. Instead of relying solely on manual triggers, the AI reads ticket context to identify urgency signals that might be missed.

For teams struggling with SLA breaches, our platform provides proactive alerts before targets are missed, not after. This gives agents time to prioritize the right tickets rather than reacting to breaches.

We integrate directly with Zendesk, so your existing SLA policies continue working while the AI layer adds intelligence on top. If you're interested in exploring how AI can optimize your SLA management, you can learn more about our AI Agent capabilities.

Getting the most from your Zendesk SLAs

Well-configured SLA policies transform how your support team operates. They replace vague "respond quickly" instructions with clear, measurable targets. They give leadership visibility into performance. And they set customer expectations that your team can consistently meet.

The filter conditions you set are the foundation. Take time to plan them properly, test thoroughly, and review regularly based on performance data.

If you're looking to take your support operation further, consider how AI can augment your existing Zendesk setup. We built eesel AI to help teams handle growing support volumes without proportionally growing headcount. You can try eesel free or book a demo to see how it works with your specific workflow.