Outcome. A high-priority ticket cannot look finished to the team without a manager's explicit sign-off recorded on the record, using a property gate rather than a native approval mechanism that does not exist for tickets.
Workflow map
Enrollment, branches and actions at a glance
tickets-sla-047
flowchart TD
A[Ticket reaches Ready to close, High/Urgent priority] --> B[Set manager_approval = requested]
B --> C[Notify manager, create review task]
C --> D[Manager manually reviews]
D -->|approves| E[Sets manager_approval = approved]
E --> F{Native stage requirement configured?}
F -->|yes| G[Ticket can now move to Closed]
F -->|no, VERIFY| H[Nothing actually stops manual closure without this, workaround only]
D -->|rejects| I[Sets manager_approval = rejected]
I --> J[Notify owner, move ticket back to active work]
When to use it, when not to
- UseUse it when a manager wants to review high-stakes ticket resolutions before they close, but HubSpot has no native approval workflow for the ticket object; native approval workflows (the kind used for deal or quote approvals) live in a different part of the product and are not available for tickets at all (check in your portal: confirm current product scope for approval workflows, this fiche assumes there is no ticket-object equivalent).
- UseUse it as a discipline layered on top of pipeline configuration: if your pipeline supports requiring specific properties to be set before a record can move into a given stage, that native stage requirement is the actual mechanism enforcing the gate, this workflow's job is to make requesting and recording that approval simple, not to invent the enforcement itself. Stage-specific required properties are configured per pipeline stage with the Required checkbox, on deal and ticket pipelines alike, with no separate tier gate beyond the pipeline itself (https://knowledge.hubspot.com/object-settings/set-up-and-customize-pipelines).
- SkipDo not use it expecting this workflow alone to block a rep from manually closing the ticket if no native stage requirement is configured; without that native enforcement, a rep can still close the ticket while this workflow's property sits unanswered, this is a workaround, not a hard block, say so plainly to the team before relying on it.
- SkipDo not use it for every ticket regardless of priority; reserve it for the priority levels where a manager's review before closure is genuinely worth the extra step, most teams will not want this friction on Low or Medium tickets.
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.4 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.3 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.
