Home → Users Manual → Filters → Example: Escalation Dashboard

6.21. Example: Escalation Dashboard

Updated: 3 Sep 2026, 10:04 PM EDT

Scenario

A manager wants one view of everything needing escalation. A request qualifies if it is urgent and the customer has waited more than 2 hours, or not urgent but has waited more than 8 hours and written more than once without a reply. Only open requests in Billing or Technical Support.

The shape of the problem

Every request has to clear the same 2-hour wait, urgent or not. A request that is not urgent then has to meet two further requirements: the customer must have been waiting more than 8 hours, and must have written more than once. Being urgent is what lets a request skip those two.

That is the idea to hold on to, because it is exactly how the filter gets built.

Setup

Click Create Filter in the left navigation. Everything below happens on the Filter tab unless noted.

1. Name it and share it

2. Leave the top-level match on all

The line above the conditions reads Match [all] of the following conditions. Leave it on all: every line and every group below has to pass.

3. Add the three conditions that apply to every request

Every condition is added the same way — click the + icon (Add condition) below the condition box. A blank row appears with a dropdown on the left; choose the condition there, and fill in the controls that appear beside it.

4. Add the category group

A Category condition holds one category, so covering two of them takes a group.

  1. Click the + below the condition box to add a row.
  2. In its dropdown, scroll to the Advanced heading and choose ANY of the following are true. The row turns into a group header with its own + icon beside it, and one blank condition appears inside the group.
  3. Set that inner condition to Category → Is → Billing.
  4. Click the group's own + to add a second inner condition: Category → Is → Technical Support.

The two + icons do different things, and this is the step that trips people up: the one on the group header adds a condition inside the group; the one below the whole condition box adds another top-level condition. (Inner conditions are inserted directly under the group header, so a group can end up listing them in the reverse of the order you entered them. Inside an ANY group, that makes no difference to the result.)

5. Add the first exemption group

  1. + → Advanced → ANY of the following are true.
  2. Set the inner condition to Is urgent (under Request Details). It takes no operator and no value — choosing it is the whole condition.
  3. Group's + → Customer wait time (minutes) → Greater than → 480.

6. Add the second exemption group

  1. + → Advanced → ANY of the following are true.
  2. Set the inner condition to Is urgent.
  3. Group's + → Number of public updates (under Other) → Greater than → 1.

What you should end up with

Match all of the following conditions:

7. Preview it

Click Run Filter to check the conditions before saving. It shows the first 10 matches unless you tick Show all results first. Spot-check a few rows: every result should be open, in one of the two categories, waiting on a reply from you, and either urgent or well past both non-urgent thresholds.

8. Set the Options tab

Then Save Filter.

Category and reporting tag names in this example are placeholders — substitute the ones your installation actually uses.

Why "Last public reply from → Customer" is in there

It is doing two jobs, and the filter is wrong without it.

It enforces the "without a reply" half of the rule. The scenario asks for customers who have written more than once and not been answered. Nothing else in the filter says that.

It keeps Customer wait time honest. That condition only measures a live wait while the customer's message is the most recent thing on the request. If a staff member has replied since, it returns the gap between the customer's last message and that reply instead — a historical figure that never changes. So without this condition the dashboard would also list requests where the last exchange happened to be slow but nobody is waiting on anything now.

One rough edge remains, and it is worth knowing about: Number of public updates counts every public note, staff replies included, so it is a proxy for "the customer wrote more than once" rather than an exact count of customer messages. With Last public reply from in place it behaves correctly in the ordinary case. The exception is a staff-initiated request — staff wrote first, the customer replied once — which counts as two.

Why "Is urgent" appears twice

This is the part that looks like a mistake, and isn't.

Each of the last two groups is an exemption.

An urgent request satisfies both groups just by being urgent, so neither extra requirement applies to it — it only has to clear the 2-hour floor at the top. A request that is not urgent fails the urgent half of both groups, so it has to satisfy the other half of each: more than 8 hours and more than one message.

There are two groups because there are two requirements to be excused from. If non-urgent requests had three extra requirements, there would be three groups, each starting with Is urgent. The repetition is doing real work: it is not the same condition entered twice, it is the same exemption applied to two different rules.

Why two waiting thresholds?

The other thing that looks like a duplicate: the filter asks for 2 hours at the top and 8 hours further down. If a request has already been caught by the 2-hour line, what is the 8-hour test adding?

Nothing after the first condition is catching anything. In a Match all filter every condition can only remove requests. The 8-hour group is not there to find requests — it is there to hold requests back.

Follow one through. A Billing request, not urgent, waiting 3 hours, customer has written twice:

So it does not appear. Without that group it would land on the dashboard at the two-hour mark, which is not what the rule asks for: a request that is not urgent is not supposed to escalate until 8 hours. The same request at 9 hours passes the group and shows up.

The two thresholds are the limits for two different populations. 2 hours is what an urgent request has to clear; 8 hours is what a non-urgent one has to clear.

Then why is the 2-hour line at the top rather than in its own group?

Because anything that has cleared 8 hours has necessarily cleared 2. Stating the 2-hour requirement for everyone costs nothing on the non-urgent side, and it saves a fourth group. The strictly equivalent version — ANY of the following are true: Is Not urgent; Customer wait time (minutes) Greater than 120 — is more to read and returns exactly the same requests.

Why it has to be built this way

The natural way to write this rule is two branches — "urgent and waited 2 hours" OR "not urgent and waited 8 hours and wrote twice". That needs a group inside a group, and HelpSpot allows only one level of grouping. See Sub-Condition Groups.

You cannot merge the last two groups into one, either. That would mean putting "waited 8 hours and wrote twice" inside a single ANY group — another nested group, and equally not allowed.

If you would rather write the branches out literally

The same filter can be built the long way, with no exemption logic to follow. Set the top level to Match any and add four groups, one per combination:

Each group is one complete escalation case, which some people find easier to check. The cost is repetition: Open, the reply condition and the category appear in every group, and adding a third category means adding two more groups rather than one line. Both versions return exactly the same requests — pick whichever you would rather come back to in six months.

Why the rest of it works

Grouping by category shows whether escalations are concentrated in one team. Urgent requests appear at the top of each group by default. Never Cache keeps the count honest on a filter people are watching.

Knowledge Tags
examples  /  Dashboards  /  Escalation  / 

Related Pages
This page was: Helpful | Not Helpful
← Example: Custom Team Inbox Example: Report on Tickets Opened or Worked On During a Month →