HubSpot workflows are the difference between a CRM that records what happened and a CRM that does something about it. A record meets a condition, and HubSpot sets the property, creates the task, notifies the owner, waits three days, and branches based on what changed, all without anyone remembering to.
They are also where HubSpot instances go to become unmaintainable. Most portals past their first year have a workflows list nobody fully understands, with two automations quietly fighting over the same property. This guide covers what workflows actually are, the workflow types and why the choice is permanent, how they differ from sequences, how enrollment and re-enrollment really behave, how to build one, and the practices that keep the list readable a year from now.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
What are HubSpot workflows?
A workflow is two things bolted together: an enrollment trigger that decides which records come in, and a series of actions that run against each record once it does. Everything else is detail.
Enrollment triggers
The condition that pulls a record into the workflow. Filter criteria on properties, a form submission, list membership, or manual enrollment only. Records that match come in; records that stop matching do not automatically leave.
Actions
What HubSpot does once a record is enrolled. Set a property value, create a task, create a record, send an internal email or in-app notification, add to a list, rotate an owner, send a marketing email.
Delays
A pause between actions, either a fixed amount of time, a specific date, or a hold until a condition becomes true. Delays are what let a workflow model a process that happens over days instead of milliseconds.
Branches
If/then logic that splits the path based on a property value or a condition. Branching is the feature that separates a workflow from a glorified list of steps.
A sequence is a conversation. A workflow is a rule. If nobody is personally following up, it is a rule.
The critical behavioral detail: a workflow runs from HubSpot's backend, not from a person. It does not know or care whether a human replied, and it will happily keep executing until the record hits a goal, gets unenrolled, or runs out of actions.
HubSpot workflow types
Workflows are typed by the object they enroll, and this is the single most consequential decision in the whole build because you cannot change it later.
| Workflow type | Enrolls | Typical job |
|---|---|---|
| Contact-based | Contacts | Lead routing, lifecycle stage updates, nurture, form follow-up |
| Company-based | Companies | Account tiering, owner assignment, data hygiene on company records |
| Deal-based | Deals | Stage automation, task creation on stage change, stalled-deal alerts |
| Ticket-based | Tickets | Support routing, SLA escalation, status notifications |
| Quote-based | Quotes | Follow-up after a quote is sent, approval notifications |
| Custom object | Custom objects | Anything you have modeled outside HubSpot's standard objects (Enterprise) |
Contact-based workflows are also the only type that supports a goal, a condition that removes a record from the workflow the moment it becomes true. Goals are how you stop nurturing someone who already converted, and their absence on other object types is a real constraint worth planning around.
HubSpot workflows vs sequences
These get confused constantly, because both send email from HubSpot. They are not interchangeable.
One-to-many. Runs on HubSpot's backend, acts on contacts, companies, deals, tickets, and quotes, sets properties, branches on logic, and does not stop when a contact replies.
One-to-one. Sends from the rep's own connected inbox, enrolls contacts only, mixes emails with manual task steps, and automatically unenrolls the moment someone replies or books a meeting.
The failure mode is specific and common: running outreach through a workflow. Because a workflow does not stop on a reply, the prospect who answered your first email on Tuesday still gets the "just following up" email on Friday. That is precisely the behavior HubSpot sequences exist to prevent, and it is the reason the tools are separate rather than one flexible tool.
Going the other direction is just as broken. A sequence cannot touch a deal, so any automation that needs to move a deal stage, rotate an owner, or react to a property change belongs in a workflow no matter how one-to-one it feels.
What you need to use HubSpot workflows
Professional or Enterprise
The real workflow builder requires Professional or Enterprise on Marketing Hub, Sales Hub, Service Hub, or Operations Hub. The free CRM does not have it.
Starter is not the same thing
Starter tiers include simplified automation, things like basic follow-up after a form submission. That is not the workflow tool: no branching, no delays, no property actions, no object choice.
Operations Hub for the powerful actions
Webhooks, custom code actions, data formatting, and scheduled triggers sit behind Operations Hub Professional. If your plan for a workflow involves calling an external API, check this before you design around it.
Clean properties to trigger on
A workflow is only as reliable as the property it reads. Free-text fields and inconsistently filled dropdowns produce workflows that silently do nothing.
That last point is the one that quietly kills more automations than any tier limit. If you are building triggers on fields your reps fill in by hand, the guide to HubSpot contact properties is worth reading first.
How to create a HubSpot workflow
- 1
Pick the workflow type
Go to Automation, then Workflows, and click Create workflow. Choose the object the workflow acts on: contact, company, deal, ticket, or quote. This choice is permanent, so pick the object whose properties you actually need to read and write.
- 2
Set the enrollment trigger
Define what pulls a record in: filter criteria on properties, a form submission, a list membership, or manual enrollment only. Be specific here, because a loose trigger is how a workflow ends up acting on records you never intended.
- 3
Add your actions
Build the action sequence: set a property value, create a task, send an internal notification, rotate an owner, add to a list, or send an email. Order matters, since each action runs against the state left by the one before it.
- 4
Add branches and delays
Use if/then branches to split the path on a property value, and delays to space actions out in time or hold until a condition is met. This is where a flat list of actions becomes real logic.
- 5
Configure settings and suppression
Set the execution window if timing matters, add suppression lists for records that should never receive the actions, and decide whether re-enrollment is allowed and on which triggers.
- 6
Test with a single record, then turn it on
Use the test feature on one real record to preview exactly which actions would fire, review the enrollment count before publishing, then turn the workflow on and check the history after the first day.
Enrollment and re-enrollment
Enrollment behavior is where most workflow bugs actually live, and almost all of them come down to two defaults people do not know about.
Records enroll once by default
A record that meets the trigger criteria enrolls one time. If it stops matching and matches again later, nothing happens. This surprises people constantly.
Re-enrollment is opt-in and granular
You turn re-enrollment on per workflow, and you choose which specific triggers are allowed to re-enroll a record. Not every trigger type supports it, so verify rather than assume.
No longer matching does not mean unenrolled
A record that stops meeting the criteria mid-workflow generally keeps going through the remaining actions. Use a goal, a branch, or an explicit unenroll action if you need it to stop.
Suppression lists are the safety net
Suppression lists exclude records from the workflow regardless of the trigger. This is the cleanest way to protect customers, competitors, or internal addresses from automation meant for prospects.
HubSpot workflow examples worth copying
The workflows that earn their keep tend to be small and boring. These are the ones worth having on day one.
Lead routing on form submission
Contact-based. A form submission enrolls the contact, a branch on company size or country assigns the right owner, and a task gets created for that owner with a due date.
Stalled deal alert
Deal-based. Enroll deals whose last activity date is more than fourteen days ago and whose stage is not closed, then send an internal notification to the owner and create a follow-up task.
Lifecycle stage progression
Contact-based. Set the lifecycle stage automatically when the qualifying condition is met, so reporting stays honest without anyone maintaining it by hand.
Closed-won handoff
Deal-based. When a deal moves to closed won, create the onboarding tasks, notify customer success, and set the company properties the CS team needs on day one.
Data hygiene
Company-based. Normalize inconsistent values, fill defaults on empty required fields, and flag records that are missing the properties your reporting depends on.
Lifecycle automation in particular has a sharp edge worth understanding before you build it, since the stages only move forward by default: HubSpot lifecycle stages covers that behavior. The same goes for deal automation, where the stage model you choose determines what your workflows can even react to, covered in HubSpot deal stages.
HubSpot workflow best practices
Before you turn a workflow on
- The object type matches the record whose properties you need to read and write, because you cannot change it later.
- The enrollment trigger is specific enough that the current enrollment count matches what you expected.
- Re-enrollment is set deliberately, on for cyclical processes and off for one-time ones.
- No other active workflow writes to the same property, or you have checked which one wins.
- The name says what it does and who owns it, not "Workflow (copy) 3".
- You tested it against a single real record and reviewed the predicted actions.
The one that saves the most pain long-term is the property conflict check. Two workflows writing to the same property is the classic HubSpot bug: nothing errors, the value just flickers depending on which one ran last, and the reporting built on top of it is quietly wrong for months. Before adding a new set-property action, search the workflow list for the property name.
Name workflows so a person who did not build them can triage the list. A prefix by object and purpose beats a clever name every time, because in eighteen months the only question anyone asks is "which of these forty things touched this record".
Where workflows stop: they move data, not context
Workflows are excellent at moving structured values around. Property to property, stage to task, record to notification. Everything in that list is a field.
What they cannot do is carry the reason. A workflow can set deal_stage to Negotiation and create a task called "Follow up on pricing". It cannot tell the rep that the CFO pushed back on the annual commitment specifically, that the champion is leaving in March, or what the three objections from the discovery call actually were. That context is written down, but it is written down in prose, and prose does not live in a HubSpot property.
For a lot of Notion-native teams it lives in Notion: the meeting notes, the account plan, the deal doc the whole team actually reads. The workflow fires perfectly, the task appears on the record, and the rep opens the task with none of the information that would make the follow-up land, because that is one tab and a search away.
Put the Context Next to the Automation
Workflows move your data. NoteLinker brings the reasoning. Your Notion notes, meeting docs, and account plans render live on the matching HubSpot contact and deal, so when a workflow drops a task on a record, the detail behind it is already sitting right there. No copy-paste, no second tab, no sync to maintain.
Pulling it all together
HubSpot workflows are the backbone of a CRM that maintains itself. Get the object type right, keep the enrollment trigger tight, set re-enrollment on purpose, and check for property conflicts before you publish, and you end up with a portal where the routing, the stage hygiene, and the internal handoffs just happen.
Skip that discipline and you get the other version: forty workflows nobody can name, two of them arguing over the same field, and reporting built on values that flicker. Use a workflow for the rule and a sequence for the conversation, keep the list readable, and remember that the automation can deliver the task but not the reason it matters. That part still has to come from the notes.
Frequently Asked Questions
Get HubSpot and Notion tips delivered straight to your inbox
We'll email you 1-3 times per week, and never share your information.
