How do I build SLA escalation workflows for HubSpot tickets?
Three things, in order. Set SLA targets on the ticket pipeline first, because the breach properties stay empty without them and the workflow then enrolls nothing, silently. Then build one alert per target, first response and time to close. Then a ladder that waits two hours and six hours before climbing to a manager and a director. Service Hub Professional or higher. The trap: delays count calendar hours, so an 18:00 breach escalates at 20:00.
The 12 specs, in build order
Each spec states its minimum tier. Free ones open in full; the others show their public preview and the date their full spec lands.
What a spec looks like
Every spec follows the same nine sections, so a team reads one and knows how to read all of them.
- Outcome, when to use it and when not to
- Prerequisites: properties, lists, tiers, with the JSON to create them
- Enrollment and re-enrollment, then every step with its parameters
- Known pitfalls, a test plan, variants, and the YAML build spec
What breaks, and how the specs prevent it
Every alert here branches on First response SLA status or Time to close SLA status. Those properties stay empty until SLA targets are configured on the pipeline, so a workflow built first simply never enrolls anything and never throws an error. The same silent failure happens when the escalation contact field is blank: the workflow history reads as a success while the notification went to nobody.
The two hour and six hour steps in the ladder are plain elapsed time. A ticket that breaches at 18:00 escalates at 20:00, and a Friday evening breach climbs to a director over the weekend. Native SLA targets do follow the pipeline business hours schedule, which is why the routing spec restricts its own enrollment window to match. Named holidays are still a gap.
The SLA status property updates on HubSpot's definition of a first response, which means the first outbound reply logged through the connected channel. A reply sent from a personal mailbox, or an internal note on the ticket, does not count and the clock keeps running. The rep gets a breach alert for a ticket they answered an hour ago.
What this bundle builds
A service desk that behaves like a service desk. A ticket arrives, it lands in the right queue with a priority already on it, somebody is told before the first response target is missed and again after, and the clock stops while the customer is the one who owes a reply.
Twelve specs cover that whole arc. Three at intake: rotation by queue, priority set from source and subject keywords, and routing by product line for teams split across products. One that restricts routing to the business hours window, so a ticket arriving at 2 a.m. does not make the morning SLA numbers look like a failure nobody caused. Two breach alerts, one on time to first response and one on time to close, each notifying a named escalation contact stored on the ticket rather than guessing who the manager is. A three level ladder for the High and Urgent tickets that stay open after a breach. Three specs on stopping the clock honestly: the waiting on contact pause with a round counter, an auto close for tickets the customer abandoned after a warning, and the holiday procedure. Two on what happens after the close: reopen on a customer reply, and the satisfaction survey.
Service Hub Professional or higher, on a pipeline with SLA targets already configured.
How the pieces fit together
SLA targets first. That is a pipeline setting, not a workflow. Every alert in this bundle branches on a status property that stays empty until the targets exist, and a workflow watching an empty property enrolls nothing while reporting no error at all. That single ordering mistake is the most common reason people believe escalation is broken in HubSpot.
Intake second: the queue property, the priority rules, the product line dropdown. Priority matters more than it looks, because SLA targets are usually set per priority level and the ladder only runs for High and Urgent.
Then the two breach alerts. Both read the same escalation contact property, a HubSpot user field you have to create by hand in settings, since the properties API cannot create that type.
The ladder sits on top of those two, and its first step is deliberately skippable so a portal running the first response alert does not send two level one notifications for the same breach. Pause, auto close and reopen run alongside and depend only on the status categories.
What you get
- 12 specs, from a 25 minute priority rule to a 45 minute three level ladder
- Each spec ships as PDF and Markdown
- Properties JSON: 16 ticket properties, including the two HubSpot user fields that have to be created in settings rather than through the API
- Workflow JSON in Automation API format, switched off on import
- Custom coded actions: none. Every spec is native Service Hub Professional
- A test plan per spec, with the records to create and the history tab to check
- Variants per spec, including wait until versions of the delay based escalations
- One click install for Full and Agency buyers
Who it is for, and who should skip it
For whoever owns the service pipeline in one portal and has been asked, in a meeting, why a ticket sat for two days. Also for an agency standing up a support desk on a new portal, since intake and breach alerts are the same four workflows every time, with the queue names changed.
Skip it if your pipeline has no SLA targets and nobody is going to configure them, because half the bundle has nothing to read. Skip the business hours and holiday specs if you run support around the clock. And if tickets are one of several problems rather than the loud one, the full library works out cheaper per spec.
Questions admins ask
Why does my HubSpot ticket escalation never fire?
Usually because the pipeline has no SLA targets, so the status property the workflow watches never gets a value and nothing ever enrolls. It fails silently, with no error surfaced anywhere. The next most common cause is an escalation contact property left blank on the ticket, which sends the alert nowhere while the workflow still records a successful run.
Can I pause the SLA timer while waiting on the customer?
The pause is native, but it comes from the pipeline stage being mapped to the Waiting on contact status category, not from any workflow. A stage that only looks like waiting on contact by name pauses nothing. The spec in this bundle adds what the native pause does not give you: a timestamp for each waiting round, a counter for tickets that bounce in and out, and a safeguard list for anything idle past thirty days.
Do escalation delays respect business hours and holidays?
Delay actions count calendar time, so a two hour rule on a ticket that breaches at 18:00 fires at 20:00. Native SLA targets do follow the business hours schedule set on the pipeline, and the routing spec restricts enrollment to the same window so the routed timestamp agrees with the clock. Named holidays are the honest gap, and the holiday spec documents the realistic answer, which is often pausing the escalation workflows for the day.
Can I build these on Service Hub Starter?
No. SLA targets and the workflows that read them are Service Hub Professional or higher, and tickets only exist where Service Hub is provisioned. The satisfaction survey spec is tagged Starter for its workflow shape, but the feedback survey tool it sends through is itself Professional and above. Treat Professional as the floor for the whole bundle.
What happens when a customer replies to a closed ticket?
If the pipeline setting that reopens on reply is on, the status changes and the reopen spec takes it from there. It increments a reopen counter, tells the original owner, creates a follow up task, and flags the ticket for review on its third bounce. If that setting is off, the reply sits in the conversation thread while the ticket stays formally closed, so check the setting before building the workflow that reacts to it.