---
title: HubSpot Workflow Automation Review & Troubleshooting
type: knowledge
created: '2026-04-05'
updated: '2026-04-05'
source_docs:
- raw/2025-12-10-cai-hubspot-discussion-proposed-time-107864376.md
tags:
- hubspot
- automation
- workflows
- crm
- troubleshooting
layer: 2
client_source: null
industry_context: null
transferable: true
---

# HubSpot Workflow Automation Review & Troubleshooting

A repeatable framework for auditing active HubSpot workflows, surfacing errors, and deciding which automations to keep, fix, enable, disable, or add. Developed through hands-on troubleshooting with the CAI account.

## Why This Matters

HubSpot workflows silently fail. Errors accumulate in the "Needs Review" queue without alerting anyone, and the root causes — deactivated users, unsubscribed contacts, missing fields — are often simple to fix once identified. A structured review prevents automation debt from compounding and ensures the CRM is actually doing what the team thinks it's doing.

---

## Step 1: Surface All Active Workflows

Navigate to **Automation > Workflows** and sort by status (On/Off). For each workflow, note:

- **Name and purpose** — what trigger fires it, what actions it takes
- **Status** — On, Off, or Needs Review
- **Enrollment count** — how many contacts are currently in it, and historical enrollment
- **Last activity date** — workflows with no recent activity may be stale or broken

> **CAI example:** Sorting by status revealed four workflows flagged as "Needs Review." Three had the same root cause (deactivated user); one had only benign errors (unsubscribed contacts, non-marketing contacts) that could be marked as fixed.

---

## Step 2: Triage "Needs Review" Errors

Open each flagged workflow and inspect the error log. Common error types and their resolutions:

| Error | Cause | Resolution |
|---|---|---|
| `User was invalid` | Workflow sends notification to a deactivated user | Edit the workflow action to remove or replace the deactivated user |
| `Contact is unsubscribed` | Workflow attempted to email an unsubscribed contact | Expected behavior — mark as fixed, no action needed |
| `Non-marketing contact` | Contact type doesn't allow marketing emails | Expected behavior — mark as fixed, no action needed |
| `Email failed to send to N recipients` | Multiple recipients configured; one or more are invalid | Review the "Send to" list in the action step; remove invalid users |

**How to edit a workflow action:**
1. Turn the workflow **Off** (required to edit)
2. Click into the failing action step
3. Update the recipient list or user assignment
4. Turn the workflow back **On**

> **CAI example:** The "Unsubscribed Lead" workflow was sending internal notifications to both Brian and the contact owner. The contact owner was Jay Gardner, a deactivated user. Removing Jay and routing notifications only to Brian resolved the error.

---

## Step 3: Identify and Reassign Deactivated Contact Owners

When a user is deactivated before their contacts are reassigned, those contacts become orphaned — still owned by the deactivated user, but invisible in standard owner filters. This breaks any workflow that sends to "contact owner."

**How to find contacts owned by a deactivated user:**

1. Go to **Contacts**
2. Add a filter: **Contact Owner > is any of**
3. In the owner search dropdown, check **"Show deactivated owners"** (checkbox at the bottom of the dropdown)
4. Select the deactivated user — they will now appear
5. Select all filtered contacts
6. Use **Actions > Assign** to bulk reassign to an active user

> **CAI example:** Jay Gardner had 3,260 contacts still assigned to him after deactivation. The "show deactivated owners" checkbox was the key to surfacing them. Reassignment was deferred pending client direction on the new owner.

**Best practice:** Always bulk reassign a departing user's contacts *before* deactivating their account.

---

## Step 4: Review Each Workflow's Logic and Goals

For each active workflow, confirm:

- **Trigger is correct** — does the enrollment criteria match the intended audience?
- **Actions are still valid** — are all referenced users, lists, and properties still active?
- **Goal is defined** — what does success look like, and is it measurable?
- **It's still needed** — is the workflow serving a current business need, or is it a relic?

Use this as a structured agenda item when reviewing workflows with a client:

> *"Here are all the automations currently on. For each one: Is this doing what you expect? Is there anything on that you want off? Anything off that you want on? Anything missing that we should build?"*

### Common Workflow Types to Review

| Workflow | Purpose | Watch For |
|---|---|---|
| **Awareness Drip** | Nurture leads not yet MQL | May be manually triggered if list quality is uncertain; check enrollment history |
| **BANT Qualification** | Promote contacts to SQL when Budget, Authority, Need, Timing criteria are met | Often inactive early on; confirm deal creation action is wired correctly |
| **SQL → Deal Creation** | Auto-create a deal when a contact reaches Sales Qualified Lead stage | Verify it doesn't fire too early in the lifecycle |
| **Unsubscribe Notification** | Alert internal team when a contact unsubscribes | Check that notification recipients are all active users |
| **Survey/Form Submission** | Trigger follow-up actions on form completions | Confirm the form name in the trigger matches the live form |

---

## Step 5: Confirm Field Visibility for Trigger Properties

Workflow triggers often depend on contact properties (e.g., Lifecycle Stage) that users must be able to see and edit. If a user can't see a field, they can't trigger the workflow manually — and they may not realize the automation isn't firing.

**How to make a property visible in the default card view:**

1. Open any contact record
2. Click the **gear icon** on the card section
3. Select **"Edit the card"**
4. Click **"Add properties"** and search for the missing field
5. Check the field to add it, then drag it to the desired position
6. Click **Save** — this updates the default view for all users

> **CAI example:** Miriam could not see the "Lifecycle Stage" field, which is the trigger for the lead lifecycle workflows. The field existed in HubSpot but was absent from the default card view. Adding it via "Edit the card" unblocked her immediately.

**Note:** Individual users can customize their own views via the gear icon, but admins control the *default* card that most users see. Changes made through "Edit the card" apply to the shared default.

---

## Recommended Pre-Call Checklist

Before a workflow review call with a client, prepare:

- [ ] List of all workflows sorted by status (On / Off / Needs Review)
- [ ] For each "Needs Review" workflow: root cause identified and fix ready or proposed
- [ ] List of deactivated users who still own contacts; count of affected contacts
- [ ] Confirmation that key trigger fields (e.g., Lifecycle Stage) are visible in the default card view
- [ ] Draft on/off/add/remove recommendations to present for client approval

---

## Related

- [[clients/cai/_index]] — Account where this framework was developed
- [[knowledge/hubspot/contact-properties-and-views]] — Managing field visibility in HubSpot
- [[knowledge/hubspot/lifecycle-stages]] — How lifecycle stages trigger automations