The Workflow Library

Library / Tickets and SLA / tickets-sla-042

Stamp an SLA-met/missed flag on the ticket at closure for downstream reporting

Tickets and SLATicketService Hub ProfessionalSimple~20 min to buildFull spec

Outcome. Every closed ticket carries a permanent, simple met-or-missed value, so a report built later does not have to reason about live SLA status fields that keep changing while the ticket is open.

Workflow map Enrollment, branches and actions at a glance tickets-sla-042
flowchart TD
    A[Ticket status becomes Closed] --> B{Native SLA status?}
    B -->|met| C[Set sla_outcome = met]
    B -->|missed| D[Set sla_outcome = missed]
    B -->|no target applied| E[Set sla_outcome = not_tracked]
    C --> F[Stamp sla_outcome_date]
    D --> F
    E --> F
action or delay branch public on every spec, paid or not

When to use it, when not to

  • UseUse it when your native SLA status properties are designed to reflect the current, live state of an open ticket and are not necessarily meant as a stable historical record once the ticket closes (check in your portal: confirm whether HubSpot's native SLA status properties freeze their value at closure automatically, or whether they can still reflect target changes after the fact, since pipeline SLA target edits could otherwise retroactively change what "met" meant for an old ticket).
  • UseUse it when a dashboard or export needs one clean, always-two-value field (met or missed) instead of parsing several native properties (hs_ticket_time_to_close__missed-style internal fields, priority-specific targets, and so on) (check in your portal: exact native property names for SLA met/missed status in the current API version).
  • SkipDo not use it if your native SLA status is already reportable directly and stable once a ticket closes; building a duplicate snapshot property adds maintenance for no real gain in that case.
  • SkipDo not use it as a substitute for actually investigating missed SLAs; this stamps a fact, it does not explain why the SLA was missed.
The preview ends here. Six sections are in the library. counted, not blurred
PrerequisitesEvery property with its label, internal name, type and options, plus the assets the workflow needs before you start.3 items
EnrollmentThe trigger, the criteria exactly as they are ticked in the UI, the re-enrollment rule and the suppression list.4 parts
StepsEach action in order with its parameters, its branches and its delays, written as you tick them.5 numbered actions
Known pitfallsTraps seen in production, each with what breaks and what to do instead.4 pitfalls
Test plan, variants and build specHow to prove it works in a test portal, where to look when it does not, the variants for other objects or tiers, and the YAML build spec.3 variants, 3 sections
FilesThe properties JSON creates the fields in one API call, the workflow JSON documents the build.PDF, Markdown, JSON
Install1 click. The installer creates the properties this spec declares and the workflow itself, switched off, then opens a task for the prerequisites that are assets rather than properties, such as a team, a static list or a marketing email. What it created is listed on the install page.1 click, switched off
Unlock the full library, 149 EUR

or the tickets and sla pack, 39 EUR

One-time, excl. VAT. 30-day refund, no questions asked. Founding prices until 31 October, then 199 and 59 EUR. Includes every spec added later, up to the full 500, and the one-click installer on the full library. Building on client portals? The agency licence at 449 EUR covers unlimited client portals.