How to Audit HubSpot Workflows Without Breaking Anything

What does a HubSpot workflow audit check?

A HubSpot workflow audit checks whether each workflow enrolls the right records at the right moment, does what its name suggests, and doesn’t conflict with any other workflow. In practice that means building an inventory, mapping every enrollment trigger and every property each workflow writes, reading the error and enrollment history, then testing the workflows that matter most before changing anything.

The goal isn’t fewer workflows for its own sake. A portal with 200 well-named, documented workflows can be healthier than one with 30 that overwrite each other. What you want at the end is a portal where anyone on the team can answer “why did this contact get that email?” in a few minutes.

You’ll need Super Admin or Workflows permissions to see everything. Workflows themselves require a Professional or Enterprise subscription in at least one hub, so if you’re on Starter, most of this guide won’t apply yet.

Step 1: Build the inventory

Start in Automation > Workflows. The index page has three views that do much of the early work for you:

• Needs review lists workflows that hit errors in the past 7 days.
• Unused lists workflows that are turned off or haven’t run any actions in the last 90 days.
• Recently deleted keeps deleted workflows for 90 days, so you can restore one if a cleanup goes wrong.

Use Actions > Edit columns to add the columns you need, filter by On or Off, Type, Folder and Action type, and export or copy the list into a spreadsheet. For each workflow, record:

• name, object type and on/off status
• owner or creator, and whether that person still works with the portal
• the enrollment trigger, in plain words
• re-enrollment: off, or on with which criteria
• which properties it sets or clears
• what it sends (emails, notifications, tasks) and what other tools it touches
• a one-line statement of its purpose, which you may have to work out

That last column is the most useful one. If no one can write a purpose for a workflow, it’s a candidate for retirement, but don’t switch it off yet.

For dependencies, open a workflow and use More > View connections. It shows the assets the workflow uses, such as emails and forms, and other tools that use the workflow. This is how you find out that a “test” workflow is referenced by a form follow-up, or that a segment you planned to delete is an enrollment trigger.

Step 2: Check each enrollment trigger

Most workflow problems begin at enrollment. HubSpot’s trigger types at the time of writing are:

• When an event occurs: enrolls on an action, such as a form submission or a custom event.
• When filter criteria is met: enrolls any record that matches the filters.
• Based on a schedule: enrolls on a date, a recurring schedule, or a date property.
• Trigger manually: enrolled by hand, from another workflow, or from a bot.
• Webhook: enrolls when an external webhook is received (Data Hub Professional or Enterprise).

For each workflow, ask whether the trigger describes the moment you care about. Filter-based triggers are the usual suspect. Suppose a “demo follow-up” workflow enrolls contacts where Lifecycle stage is SQL. That catches demo requests, but it also catches every record a rep moves to SQL by hand, every import that sets SQL, and every contact synced from a company that just became SQL. If the purpose is “follow up after a demo request”, an event trigger on that specific form submission is more honest.

Look at the filters themselves too. Watch for “is any of” lists of form names that haven’t been updated since a website rebuild, segment membership triggers where the segment’s own filters have since changed, and property filters on fields that are no longer populated.

Also note how each workflow was switched on. When you turn a workflow on, HubSpot asks whether to enroll existing records that meet the trigger criteria now, or only records that meet them afterward. That choice isn’t visible later at a glance, so check the enrollment history (Step 4) if a workflow’s first-day enrollment count looks odd.

Step 3: Check re-enrollment, unenrollment and suppression

By default, a record enrolls in a workflow only the first time it meets the triggers. Re-enrollment is set in the workflow’s Settings tab inside the trigger editor. For filter-based triggers you choose which criteria can re-enroll a record; for event-based triggers you choose between enrolling once or each time the event happens.

Both directions cause trouble:

• Re-enrollment off when it should be on. A customer buys a second product and never gets that product’s onboarding, because they enrolled once a year ago.
• Re-enrollment on when it shouldn’t be. A property flips back and forth during a sync, and the contact receives the same welcome email four times in a week.

In the same Settings tab, check the unenrollment rules. For contact workflows you can unenroll records that no longer meet the enrollment criteria, that meet the workflow goal, or that join a suppression segment. Records meeting the unenrollment conditions also can’t enroll. For company, deal, ticket and quote workflows, the equivalent is a set of conditions that exclude or unenroll records.

Ask, for every nurture or follow-up workflow: what should stop this? A contact who books a meeting halfway through a sales nurture shouldn’t get the next “still interested?” email. If there’s no goal or unenrollment rule, they will.

Step 4: Read the history and the errors

Open a workflow’s details (More > View details) and you’ll find:

• Action logs: every event in the workflow, newest first, filterable by date, revision, action type and event type, including Errors. HubSpot keeps action log data for 90 days.
• Enrollment history: every enrollment over the past six months and what happened to each record.
• Performance: enrollment trends, plus email metrics if you have Marketing Hub Professional or Enterprise.
• Review workflow issues: a list of issues HubSpot thinks you should fix or can ignore.

Because of the retention windows, if you’re investigating something that happened eight months ago, the workflow’s own history won’t help. Check the record’s property history instead. It shows which workflow (or form, import or integration) changed each value and when.

Errors to look for: emails skipped because the contact is unsubscribed or bounced (expected, but worth knowing the volume), owner assignments failing because the user no longer has a paid seat, webhooks returning errors, and actions referencing deleted properties or archived emails.

Step 5: Find workflows that fight each other

This is where most of the real problems live. Sort your inventory by the property each workflow writes, and look at every property set by more than one workflow. The usual suspects are Lifecycle stage, Lead status, Contact owner, any lead source or “original source” field you’ve built yourself, and score properties.

A typical find: workflow A sets lead status to Connected when a call is logged. Workflow B, written a year earlier, sets lead status to Attempted to Contact whenever Last contacted changes and the status isn’t Open Deal. Each call now sets Connected and then, a moment later, Attempted to Contact. The rep sees the wrong value and stops trusting the field.

The fix is to give each important property a single owning workflow, and have other workflows request a change through it (for example, by setting a flag property it listens for) rather than writing directly. It’s slightly more structure, but it means there’s one place to read when someone asks why a value changed.

Also check for loops: workflow A sets a property that enrolls the record in workflow B, which sets a property that re-enrolls it in A. Even when a loop eventually stops, it wastes actions, fills your logs and leaves values changing for no visible reason.

Step 6: Test before you change anything

Pick the workflows that touch revenue or customers first: routing, lifecycle updates, onboarding, renewal and anything that sends email to customers. For each one:

1. Create a test contact (and company or deal if needed) using an address you control, clearly named as a test record.
2. Push it through the trigger the way a real record would, such as submitting the actual form.
3. Watch the enrollment and action logs, then check every property the workflow should have changed.
4. Push it through the edge cases: re-enrollment, the unenrollment conditions, a record with an existing owner.

Write down what happened against what was supposed to happen. Our HubSpot workflow checklist gives you a structure for this, and the general workflow QA checklist works for other platforms too.

Step 7: Clean up safely

Once you know what each workflow does, cleanup is mostly mechanical:

• Retire in stages. Turn a workflow off and leave it for a few weeks before deleting it. If nobody notices, delete it. If someone does, you’ve learned what it was for.
• Consolidate. Five workflows that each send one internal notification for different forms can often become one workflow with branches. HubSpot’s if/then branches let you split by one property value or by AND/OR criteria, with records that match nothing following the “None met” path.
• Rename to a convention. Something like “Object | Purpose | Trigger”, for example “Contact | Demo follow-up | Form: Demo request”. No “v2”, no “FINAL”, no initials.
• Fill in descriptions. The workflows index search matches against names and descriptions, so a short description makes workflows findable.
• Use folders by function: routing, lifecycle, nurture, customer, internal alerts, integrations.

Keep the inventory spreadsheet. It’s the documentation for the next person, and the starting point for the next audit.

How often should you audit HubSpot workflows?

Run a full audit once a year, and a lighter review whenever something big changes: a new form set, a website rebuild, a new integration, a sales process change, or a new hub. The lighter review is just Steps 1, 4 and 5: check Needs review and Unused, scan the errors, and look again at properties written by more than one workflow.

Between audits, a simple rule prevents most drift: no one turns on a new workflow without adding it to the inventory and naming the properties it writes.

For a platform-neutral version of this process, see our CRM automation audit guide.