When a HubSpot workflow stops auto-creating deals from new contacts, the cause is almost always one of five things: the workflow is turned off, the enrollment triggers changed so new records no longer qualify, re-enrollment or unenrollment settings block the record, the "Create record" action lost a required setting (pipeline, deal name, or a required property), or the action is failing silently and logging errors only in the workflow's run history. Work the checklist in order: confirm the workflow is on, review enrollment triggers against a contact that should have qualified, check the action's configuration, then open the run history for the exact error. Most "the deal didn't get created" reports trace back to a trigger edit or a required-property change made days earlier.
Start in the workflow itself, not in the CRM record. Open the workflow and check its history: HubSpot logs every enrollment decision and every action outcome. A contact that never enrolled tells you the problem is upstream — triggers, filters, or suppression. A contact that enrolled but whose "Create record" action shows an error tells you the problem is the action configuration. This single distinction cuts debugging time dramatically, because the two failure families have completely different fixes.
The second stop is the workflow's settings panel. Confirm the workflow is actually on — paused and draft workflows look healthy in a list view until you open them. Then check the enrollment criteria against a specific contact that should have produced a deal. HubSpot lets you test a record against the triggers directly, which answers "would this contact enroll today?" without waiting for a real one.
This is the most common regression, and it usually follows an innocent edit. Someone adds a filter ("only contacts in these lists"), tightens a property condition, or changes an "is known" trigger to a specific value — and from that moment, new contacts created through a form, an integration, or manual entry no longer match. The workflow isn't broken; it's correctly doing what it was last told to do.
Three trigger patterns cause the most confusion:
Also check unenrollment criteria and suppression lists in workflow settings. A contact that qualifies for enrollment but also lands on a suppression list — or meets the unenrollment condition the moment a property changes — will be pulled out before the deal-creation action runs.
If contacts enroll successfully but no deal appears, the action configuration is the suspect. The "Create record" action for deals has its own failure modes:
Each of these leaves a trace. Open the action's error log in the workflow's history and read the exact message — HubSpot is usually specific about which property or pipeline rejected the write. Fix the configuration, then re-enroll a test contact to confirm the action completes.
Two account-level causes are easy to miss because nothing inside the workflow looks wrong. First, user permissions: if the workflow was built by an admin who has since been deactivated or downgraded, some actions that depended on their access can misbehave, and edits made under a limited seat can silently fail to save. Second, subscription or tool limits: hitting workflow or object limits on a downgraded plan can prevent new enrollments from processing the way the old setup did. If the regression coincides with a contract change or a seat reduction, that's the thread to pull.
There's also the human pattern worth naming: the person who notices is often the only person testing. "Deals aren't being created" sometimes means "my deals aren't being created" — because one user's contacts are entered without the qualifying property while everyone else's flow through a form that sets it. Comparing a working path against the broken path, field by field, usually exposes the difference in minutes.
Three habits keep this class of problem short-lived. First, assign every production workflow an owner — a named person who gets asked before triggers, pipelines, or required properties change, because those three edits account for most automation regressions. Second, check run history on a schedule, not just when someone complains; a weekly glance at action errors catches silent failures while they're still small. Third, keep a test contact that can be enrolled on demand after any configuration change, so "does it still work?" is a two-minute question instead of a user report two weeks later.
Teams running heavier automation should also document which workflows feed revenue-critical objects like deals, so those get extra scrutiny during any portal cleanup. Related troubleshooting patterns for sync errors and permission issues are covered in Troubleshooting Common HubSpot Admin Issues.
Vantage Point's HubSpot consulting and implementation team diagnoses workflow regressions like this one as part of normal support: reading run histories, untangling trigger edits, and rebuilding deal-creation automation so it survives future admin changes. For portals that have drifted through many hands, managed services and ongoing support adds the monitoring layer — workflow health checks, error-log reviews, and change control — so a broken deal automation is found by the team maintaining it, not by the salesperson who needed the deal.
Vantage Point is a HubSpot and Salesforce Solutions Partner and is employee-owned. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Usually because something around it changed, not because the workflow broke. The most common triggers are an edit to enrollment criteria, a pipeline change, a newly required deal property the action doesn't set, or the workflow being turned off. Check the workflow's run history for enrollments and per-action errors first — it almost always points at the exact cause.
Open the workflow and use the enrollment test or history view: HubSpot shows which criterion a specific record failed. Compare that against the contact's actual property values — a missing or unexpected value on a single qualifying field is the usual answer.
Only if re-enrollment is explicitly enabled in the workflow's enrollment settings, and only when the record meets the chosen re-enrollment criteria. Without it, a contact that enrolled once — even months ago — will never trigger the workflow again, which often looks like the automation stopped working.
The action writes a new deal using its configured pipeline and property values. If the target pipeline was changed or deleted, if a required deal property isn't set by the action, or if a copied value isn't valid for the target field type, the write fails and the error appears in the workflow's action history.
The workflow engine runs as the system, but the people maintaining it matter: a deactivated owner's edits, a downgraded seat, or plan limits after a subscription change can all interfere with how workflows are edited, saved, or processed. If the timing lines up with a staffing or contract change, check account-level causes.
Keep a dedicated test contact and enroll it manually after any configuration change. Watch each action's outcome in the run history, confirm the deal appears in the right pipeline with the right associations, then delete the test record. It's a two-minute check that prevents week-long silent failures.