What Are HubSpot Workflows (and How to Build Them)

HubSpot workflows are automated sequences that trigger actions, sending an email, updating a property, creating a task, whenever a contact, company, deal or ticket meets a rule you define. No coding is required, but the tool itself is not universal: it needs Marketing, Sales, Service, Data, Smart CRM or Revenue Hub Professional or Enterprise, plus Super Admin or Workflows permissions, so a Starter portal has no execution window to configure at all.

Where workflows exist, three limits decide whether they behave the way a generic tutorial assumes on a portal that spans more than one language or more than one working week. This post covers what workflows are, how to build one, and the three places those limits actually bite.

What Are Workflows in HubSpot?

Workflows are HubSpot's automated tool for turning a predefined rule into a set of actions without anyone doing it by hand. A website visitor downloads a guide, and a workflow sends the follow-up email the same minute. A contact crosses a score threshold, and a workflow alerts the sales rep who owns the territory. The value is consistency: the same rule fires the same way every time, whether the team is watching or not.

How Do HubSpot Workflows Work?

Three parts make up every workflow, in order.

1. Triggers. The event that starts the workflow: a form submission, a property change, a website visit, or list membership.
2. Actions. What happens once the trigger fires: sending an email, creating a task, updating a property, or enrolling the record in another workflow.
3. Branching logic (optional). The workflow splits into separate paths based on a condition, so different records get different treatment from the same workflow rather than needing a second one built from scratch.

That third part is where a regional build earns its place, and it is where a generic workflow tutorial stops being useful for this market.

Where the Single-Timezone Window Breaks

The Timing setting under a workflow's settings lets you restrict when its actions run, by day of week and time. Read closely, though, it governs "your account's time zone", meaning one time zone for the whole portal, not the recipient's own. A portal serving a Riyadh office on a Sunday-to-Thursday week and a UAE public-sector contact on a Monday-to-Friday week cannot hold both weeks in one workflow's Timing setting; the split has to live in two separate workflows, or in a branch that routes each record down a path built for its own market.

Two scope details matter beyond that. The window governs actions only, not enrollment, so a record can still enrol on a Friday and simply queue until the window reopens rather than being blocked from entering. And if the account itself has no time zone configured, the default is Eastern Standard Time, which on a newly built regional portal can put every scheduled send hours out with no error raised anywhere. Confirm the account time zone before publishing the first timed workflow, not after the first complaint about a 3am send.

Why a Workflow Can Quietly Stop Firing

Every workflow ships with re-enrollment off by default: a record is only enrolled the first time it meets the trigger, or when enrolled manually. That default holds hard. Once re-enrollment is off, a record that already passed through cannot enter again, whether the second attempt is manual or automatic, which is why a scoring or nurture workflow can look like it is working for a quarter and then stop firing on repeat qualifying events with nothing announcing the change.

Fixing it is narrower than flipping a switch. Only properties of the same type as the trigger are eligible for re-enrollment, and activity-based triggers can never be made eligible at all, so an activity-triggered nurture cannot be repaired this way regardless of the setting. And turning re-enrollment on is forward-only: it does not retroactively enrol the records that qualified while it was off, so the gap has to be closed by hand. Decide the re-enrollment setting deliberately when the workflow is built, because discovering it later means finding every record the silence missed.

Branching on the Property That Decides the Language

Sending different content to Arabic and English contacts is the most common branch a regional workflow needs, and it depends entirely on a property existing before the workflow runs, not on the workflow itself. A branch condition checking preferred language only works if that property has already been set on the record; a contact with no value there falls through to whichever branch the workflow defaults to, silently, which is usually not the outcome anyone intended. Our own research on MENA CRM buyers finds that 43% require a bilingual interface before a platform is usable for their teams at all, so the language property is not an edge case to branch around later; it belongs on the record before the first workflow that reads it goes live. This is the same reason a HubSpot list built for a language segment needs the property set before it is built, not patched in afterward.

Building a Workflow Around a Calendar That Moves

HubSpot has no built-in awareness of the Islamic calendar, so a workflow keeps sending on schedule straight through Eid unless the build says otherwise. Eid dates are confirmed by moon sighting and commonly announced only days ahead, so the exact working days of a launch week are not known when the quarter's workflow calendar is signed off. Think with Google's 2022 Ramadan study found search interest for Ramadan and Eid Al-Fitr rising 45% year on year, so the volume moving through a workflow during that window is not a quiet period to schedule around casually. The Hijri year also runs roughly eleven days shorter than the Gregorian one, so a workflow calendar reused unchanged from last year drifts by more than a working fortnight within two cycles, enough to land a send inside the last ten days of Ramadan without anyone deciding to. Build the pause as a branch condition tied to a date range you update each year, not as a hardcoded delay.

How to Build a HubSpot Workflow in 5 Steps

1. Select the object and workflow type. Choose contacts, companies, deals or tickets, and the workflow type that matches what you are automating.
2. Define the enrollment trigger, and decide the re-enrollment setting at the same time, not afterward.
3. Add your actions, in the order records should experience them.
4. Add branching logic for anything that needs to behave differently by language, market or working week.
5. Review, test and publish, checking the account time zone and the calendar assumptions above before it goes live.

Workflows are also how a contact gets set as a marketing contact automatically once it meets criteria you define, and how a lead score updates as engagement changes, so the same enrollment and timing rules above apply there too.

Building workflows that hold up across two working weeks, two languages and a calendar that moves is what our RevOps work is built around. If your automation is silently missing records or firing at the wrong hour, get in touch and we will map where it is happening.