These twelve HubSpot workflow examples are built for support, customer success, and ops teams, not marketing. Each one lists the trigger, the actions, the re-enrollment setting that most often breaks it, and why it works. Property names are HubSpot's defaults unless an example names a custom property, and every workflow needs a Professional or Enterprise plan.
HubSpot Ticket Automation Examples
Examples 1 to 7 run on tickets. Together they cover the life of a ticket from arrival to the customer hearing that the fix shipped.
1. Route New Tickets by Category
Trigger: ticket-based. Ticket is created and Category is any of Billing, Product question, or Bug report.
Actions: a branch on Category. Billing tickets rotate to the billing team, product questions rotate to the frontline queue, and bug reports rotate to whoever owns technical triage. Each branch also sets the ticket's pipeline stage to the right starting stage.
Re-enrollment: off. A ticket is created once.
Why it works: the first five minutes of a ticket are usually spent working out whose it is. A routing workflow moves that decision to the moment the ticket is created, and the person who picks it up is already the right one. The rules for deciding categories in the first place are in the support ticket triage guide.
2. Escalate High-Priority Tickets Nobody Has Answered
Trigger: ticket-based. Priority is High or Urgent.
Actions: delay 30 minutes. Branch on whether the ticket has had a first response. If not, send an internal notification to the team lead and a Slack message to the support channel. Delay another 60 minutes, check again, and if there is still no response, notify the head of support.
Re-enrollment: on, for the Priority trigger. A ticket can be downgraded and raised again, and the second time matters as much as the first.
Why it works: response-time targets are kept by noticing misses while they are still small. This turns the escalation matrix from a document into something that fires on its own. Set the delays from the targets in your SLA, not from round numbers.
3. Chase Customers Who Have Gone Quiet, Then Close
Trigger: ticket-based. Ticket status is Waiting on contact.
Actions: delay 3 business days. If the status has not changed, email the associated contact asking whether they still need help. Delay 4 more business days. If the status still has not changed, set the ticket to Closed and add a note saying it was closed for inactivity.
Re-enrollment: on. A ticket can go to Waiting on contact many times in its life.
Why it works: waiting tickets pile up and distort every queue metric you report. The workflow handles the polite follow-up nobody remembers to send, and closes what is genuinely dead. Turn on the setting that unenrolls a ticket when it no longer meets the trigger, so a customer who replies on day two is not closed on day seven.
4. Send a Satisfaction Survey When a Ticket Closes
Trigger: ticket-based. Ticket status is Closed.
Actions: delay 1 hour. Branch to skip tickets closed for inactivity (the note or a property from example 3). Send the survey to the associated contact. The send survey action needs Service Hub Professional or Enterprise and is still labeled beta in HubSpot's documentation.
Re-enrollment: on, with a limit. Re-opened tickets will close again, and you probably do not want to survey the same customer twice in a week. Add a filter that excludes contacts surveyed in the last 30 days.
Why it works: a survey sent an hour after the fix lands is answered by someone who remembers the experience. Excluding inactivity closures keeps your CSAT from being dragged down by tickets nobody actually solved. The customer service metrics guide covers how to read the results.
5. Flag Tickets From Your Most Important Accounts
Trigger: ticket-based. Ticket is created and the associated company's tier property is Enterprise (a custom company property most teams already have in some form).
Actions: set Priority to at least High. Add the account's customer success manager as a follower, or create a task for them. Send an internal notification to the CSM with a link to the ticket.
Re-enrollment: off.
Why it works: support should not need to know which accounts are renewing next month. The workflow carries that context from the company record onto the ticket, and the CSM hears about a problem from you instead of from the customer on the renewal call.
6. Send Confirmed Bugs to Engineering
Sending confirmed bugs to engineering is the one workflow most support teams want and cannot build with HubSpot's built-in actions, because the work leaves HubSpot.
Trigger: ticket-based. A custom property such as "Escalate to engineering" is Yes, or Category is Bug report and the ticket has moved to a Confirmed stage.
Actions: create an issue in the engineering tracker from the ticket. Use the ticket subject as the issue title and the description as the body. Set the team, a Bug label, and a priority. Then send an internal notification to the ticket owner that includes the new issue's key and link.
Re-enrollment: off. One ticket should open one issue.
Why it works: the agent's job ends at "this is a confirmed bug". Creating the issue, copying the context across, and pasting the link back are steps that get skipped on a busy afternoon, and a skipped step means a customer waiting on a bug nobody filed.
HubSpot's built-in connected app actions include Slack, Asana, and Trello, but not Linear. So the issue-creating step has to come from an app. IssueLinker adds a Create Linear issue action to ticket-based workflows, with fields for the team, project, status, assignee, labels, and priority. It also returns the issue key and URL as outputs you can use in later actions, such as the internal notification. If the ticket is already linked to an issue, it uses that one instead of opening a duplicate.
7. Tell Support When Engineering Ships the Fix
Trigger: ticket-based. The linked issue's status, stored as a ticket property, changes to done.
Actions: create a task for the ticket owner titled "Fix shipped, reply to customer", due today. Move the ticket to a "Fix shipped" pipeline stage. Optionally, send an internal notification so the owner sees it immediately.
Re-enrollment: on. An issue can be reopened and closed again.
Why it works: this is the step that fails most often in support, and nobody notices it failing. The bug is fixed, the issue is closed, and the customer who reported it is never told, because nothing in HubSpot changed when engineering closed the issue. A workflow can only react to that if the issue's status exists on the ticket as a property.
With IssueLinker linked tickets, it does. The linked Linear issue's status is written to the ticket as Linear Issue Status, plus Linear Issue Status Type, which holds Linear's normalized bucket (backlog, unstarted, started, completed, or canceled). Trigger on Status Type is completed and the workflow works across every Linear team, however each one names its states.
The most expensive support workflow is the one nobody built: the customer reported the bug, engineering fixed it, and nobody told the customer.
Customer Success Workflow Examples
Examples 8 to 10 run on companies and deals. They are less about the queue and more about accounts.
8. Start Onboarding When a Deal Closes
Trigger: deal-based. Deal stage is Closed won.
Actions: create a ticket in an Onboarding pipeline, associated with the deal's company and contacts. Assign it to the CSM from the company record, or rotate it across the onboarding team. Create a task for the CSM to book the kickoff call within two business days.
Re-enrollment: off.
Why it works: the gap between sales closing a deal and anyone in post-sales hearing about it is where early churn starts. Creating the onboarding ticket automatically gives the handoff an owner and a due date.
9. Prepare for Renewals 90 Days Out
Trigger: company-based, scheduled. Enroll on a date property: 90 days before the company's renewal date.
Actions: create a task for the CSM to review the account. Send an internal notification with a link to the company's open tickets. At 60 days, create a second task for the renewal conversation.
Re-enrollment: on, since renewals come round every year.
Why it works: renewal problems are visible months ahead in the support history, open bugs especially, and invisible on the renewal call if nobody looked. The QBR template covers what to bring to that conversation.
10. Catch Accounts That Have Gone Quiet
Trigger: company-based. Last activity date is more than 45 days ago, and Lifecycle stage is Customer.
Actions: create a task for the CSM to check in. Add the company to a "Quiet accounts" list for the weekly review.
Re-enrollment: on. An account can go quiet more than once.
Why it works: silence is the cheapest churn signal you have and the easiest to miss, because nothing happens. The workflow makes nothing happening count as an event.
Sales and Ops Workflow Examples
Examples 11 and 12 run on contacts and companies, because a support team's workflows only work if the records feeding them are clean.
11. Assign Owners to New Demo Requests
Trigger: contact-based. Form submission on the demo request form.
Actions: rotate the contact to an owner on the sales team. Create a task for that owner to follow up within one business day. Set Lifecycle stage to Sales qualified lead.
Re-enrollment: on, for the form submission event. A returning contact who requests a demo again is a strong signal, not a duplicate.
Why it works: speed to first touch is the one lead metric almost everyone agrees on. Rotation removes the "who takes this one" message entirely.
12. Keep the Properties Other Workflows Depend On Clean
Trigger: contact-based or company-based. A key property is known, such as phone number or country.
Actions: use the format data or validate phone number actions to standardize the value. Copy the company's tier and CSM onto newly associated tickets so examples 5 and 9 have something to read.
Re-enrollment: on, for property changes.
Why it works: every other example is only as good as the properties it triggers on. This is the unglamorous workflow that keeps the rest of them honest.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
What Are HubSpot Workflows?
A HubSpot workflow is an automation that enrolls records when they meet a trigger and then runs actions on them, in order, without anyone clicking anything.
Every workflow has three parts:
An object type
The kind of record the workflow enrolls: contacts, companies, deals, tickets, and several others. A ticket-based workflow can still read and update the ticket's associated contact and company, but the ticket is what moves through it.
Enrollment triggers
The condition or event that puts a record into the workflow. "Ticket priority is High" is a condition. "Ticket was created" is an event. You can also enroll records on a schedule, from a webhook, or by hand.
Actions
What happens to each enrolled record. Edit a property, create a task, notify the owner, email the contact, rotate the owner, create an associated record, wait for a delay, or branch on if/then logic and do different things on each side.
The part people underestimate is the delay. A delay turns a workflow from "do this now" into "check back later", which is what makes most of the twelve examples work. "If nobody has replied in an hour, tell the team lead" is a trigger, a one-hour delay, and a branch.
What You Need to Build HubSpot Workflows
The workflows tool is a Professional and Enterprise feature. It comes with Marketing Hub, Sales Hub, Service Hub, Data Hub, Smart CRM, or Revenue Hub at those tiers, and the number you can build depends on the subscription. Plan details and limits are taken from HubSpot's knowledge base, checked on October 2, 2026.
| Subscription | Workflows you can create |
|---|---|
| Marketing, Sales, or Service Hub Professional | Up to 300 |
| Marketing, Sales, or Service Hub Enterprise | Up to 1,000 |
| Data Hub Professional | Up to 400 |
| Data Hub Enterprise | Up to 1,100 |
If you hold several subscriptions, the highest limit applies. A portal with Marketing Hub Professional and Service Hub Enterprise can build 1,000.
Three requirements matter for support teams specifically:
- Rotating ticket owners in a workflow needs Service Hub Professional or Enterprise.
- Emailing the customer from a workflow needs Marketing Hub or Service Hub Professional or Enterprise. Internal notifications to your own team work on any plan that has workflows.
- Custom code, the send a webhook action, and webhook triggers need Data Hub Professional or Enterprise.
HubSpot Workflow Triggers: Which One to Use
HubSpot offers five ways to enroll records, and picking the wrong one is the most common reason a workflow fires too often or never.
| Trigger type | Enrolls a record when | Good for | Watch out for |
|---|---|---|---|
| Filter criteria | A condition becomes true | Priority is High, status is Waiting on contact | Enrolls once by default. Turn on re-enrollment if the condition can come back |
| Event | Something happens | Ticket created, form submitted, property changed | Can enroll on every occurrence, which can flood a noisy workflow |
| Schedule | A calendar date or a date property arrives | Renewals, anniversaries, weekly reviews | Date property must be filled in, or the record never enrolls |
| Webhook | An external system sends a webhook | Events from your own product | Needs Data Hub Professional or Enterprise |
| Manual | You enroll records yourself | One-off clean-ups, backfills | Easy to forget it is not automatic |
The rule that saves the most debugging: if the thing you are reacting to can happen twice, the workflow needs re-enrollment. A record also cannot re-enroll while it is still inside the workflow, so a 30-day delay means a 30-day blind spot.
Common HubSpot Workflow Mistakes
Most broken workflows fail in one of five ways.
Before you turn a workflow on
- Decide on re-enrollment deliberately. If the trigger condition can become true again, turn it on.
- Turn on unenrollment when a record stops meeting the trigger, for any workflow with long delays. Otherwise a resolved ticket keeps getting chased.
- Add a branch for unknown or empty values. The last branch should not be a catch-all for bad data.
- Check for loops. Workflow A sets a property that triggers workflow B, which sets the property that triggers A.
- Test on a handful of real records before enrolling existing ones. Enrolling every existing ticket at once is hard to undo.
Where HubSpot Workflows Stop
Workflows are good at everything that happens inside HubSpot. They can route, wait, branch, notify, and update any record in the portal. Where they struggle is the moment work leaves HubSpot and has to come back.
For a support team that moment is the engineering handoff. A ticket becomes a bug, the bug is fixed in a tracker HubSpot cannot see, and the customer waits on news that never arrives in the CRM. Examples 6 and 7 are two halves of that one problem. A workflow can send the bug out, but it can only notice the fix if the fix comes back into HubSpot as data.
There are three common ways to wire it:
An internal notification to an engineer plus a manual link pasted into the ticket. Free and fine for a few bugs a month. Nothing tells support when the fix ships.
A webhook or a Zap creates the issue. It is one-way, so comments and status do not come back without a second automation, and the two can trigger each other. The Zapier HubSpot Linear guide covers the build and its limits.
The app creates the issue, keeps it linked to the ticket, and writes status back as properties workflows can trigger on. Both halves of the handoff become workflow examples you can build.
IssueLinker is the third option. Support creates a Linear issue from the ticket sidebar in one click, or a workflow does it with the Create Linear issue action. Comments sync both ways, and the issue's status lands on the ticket as properties, so example 7 is a ten-minute build. IssueLinker also connects HubSpot to Jira and GitHub from the ticket sidebar. The workflow action is Linear only today. Setup for the Linear side is in the Linear HubSpot integration guide.
Build the workflow that tells customers the fix shipped
IssueLinker links HubSpot tickets to Linear issues, adds a Create Linear issue workflow action, and writes issue status back to the ticket so your workflows can act on it. Flat monthly price, unlimited users, setup in about fifteen minutes.
Where to Start
If you build only three of these, build 1, 2, and 7. Routing gets each ticket to the right person, escalation catches the misses while they are still small, and the fix-shipped workflow closes the loop that support most often leaves open. The rest are refinements. Those three change what your customers notice.
