A customer submits a quote request. Their contact is in HubSpot, but the sales task, owner assignment or acknowledgement you expected never appears. The website seems to work; the follow-up does not.
Start with one affected enquiry and find where its route stopped. A contact failing to enter a workflow is a different problem from an enrolled contact waiting for an action, leaving early or encountering an error. Changing every trigger at once makes that distinction harder to see.
This guide focuses on HubSpot workflows used to handle website enquiries. The available tools depend on your subscription and permissions; HubSpot’s enrolment-trigger guidance lists the supported workflow subscriptions and explains the different trigger types.
Confirm the enquiry reached the right contact
Choose a recent example with a known submission time. Open the intended contact and look for evidence of that particular enquiry, not simply the existence of an old contact record.
Keep four things together while investigating:
- The website page and form used.
- The submission time and the time zone used to record it.
- The contact record that received the submission or integration update.
- The workflow and first business action you expected.
If the submission never reached HubSpot, investigate the form or integration before changing the workflow. If it reached the wrong person, fix the contact association first. Our guide to HubSpot forms overwriting contacts covers that separate problem.
Write the intended behaviour in plain English: “Each genuine quote request should reach the sales team, including a second request from an existing contact.” That gives you a useful test. “The automation should work” does not.
Check whether the contact entered the workflow
In Automation > Workflows, find the relevant workflow and open its details. Search the enrolment history for the contact, widening the date range if necessary. Then inspect the action logs around the expected handover.
HubSpot’s workflow-history documentation explains how to filter records, events and revisions. It states that action-log data is retained for 90 days and historical enrolments for six months. Investigate promptly rather than assuming the complete history will remain available indefinitely.
Use the evidence to choose your next step:
- No enrolment: investigate the starting trigger, activation and repeat-entry rules.
- Enrolled, then exited: inspect the reason for leaving and the applicable exclusions.
- Enrolled, with an unfinished action: investigate the action, its timing and any recorded error.
- Action completed: check its actual destination and whether the team received the intended handover.
Do not treat the current editor as a complete explanation of yesterday’s failure. The workflow may have changed since the enquiry arrived; compare the relevant historical revision where available.
If there was no enrolment, check the starting rules
Was the workflow active at the relevant time?
A correct-looking workflow cannot handle an enquiry while it is off. Also check what happened when it was activated or its criteria were changed: were records already matching the conditions included, or only records qualifying afterwards?
HubSpot’s enrolment troubleshooting guide identifies inactive workflows, existing records excluded at activation, unmet criteria and immediate unenrolment as possible causes. For supported property, list and form-submission filters, its Help > Troubleshoot enrollment tool lets you investigate a specific record and expected time range.
Does the rule describe the enquiry you actually received?
Read each condition aloud. A rule requiring a quote-form submission and a particular lifecycle stage will exclude someone who submitted the form but does not have that stage. An alternative group joined with OR can admit a different set of people.
Check the selected form against the one used on the live page. When a developer replaces a form, include a review of the workflows that depend on it in the handover. Keep a successful enquiry beside the failed one and compare only the fields your rules use; this is more useful than inspecting the entire CRM.
Event triggers depend on what was true at that moment
A filter-based trigger checks whether criteria are met. An event-based trigger responds to something happening. That difference matters when information arrives in several stages.
HubSpot’s event-trigger documentation says events must occur after the workflow is turned on. Additional filters are evaluated when the event occurs; a later property update does not cause those filters to be rechecked for the original event. A record must also exist before the triggering event occurs.
For example, imagine an integration creates a contact and adds a service-interest field afterwards. If an Object created trigger requires that field to contain a particular value, investigate whether it was populated at creation. Seeing the right value now does not establish that it was there then.
Discuss the intended sequence with whoever maintains the integration. The repair might involve updating the handover or choosing a trigger that reflects when the enquiry data is ready. Adding a delay after enrolment cannot help a contact that never entered.
There is also a testing limitation: HubSpot says enrolment testing cannot test the event itself and considers only the additional filters. A passing filter check therefore needs a controlled, genuinely new event to confirm the full route.
Repeat enquiries need an explicit plan
Compare a first-time enquirer with an existing contact who has submitted again. If the first works and the second does not, inspect re-enrolment before rebuilding the form.
According to HubSpot’s re-enrolment guidance, records normally enter once unless re-enrolment is configured. For filter-based workflows, select the eligible repeat-entry conditions deliberately. A record already active in the workflow cannot re-enter it at the same time.
This matters if a long follow-up workflow is expected to process every new quote request. Decide how your business will handle a second request while the first is still active, rather than assuming the same contact can begin another simultaneous run.
Re-enrolment also restarts the workflow from the beginning, including its actions and automated emails. Review those consequences before enabling it. Turning it on does not itself replay every missed enquiry.
A useful design discussion separates the immediate handling of a fresh request from any longer follow-up programme. Ask whether each should have its own rules, and what should happen when a customer makes another enquiry.
If the contact enrolled, follow its actual path
Once history confirms enrolment, stop adjusting the starting trigger. Inspect the first point where actual behaviour differs from the expected behaviour.
HubSpot’s workflow settings guidance distinguishes enrolment from action timing: permitted execution hours affect subsequent actions, not whether a record enters. User notification settings can also prevent someone receiving a workflow email notification even when the workflow runs.
Check the contact’s logged outcome, the action’s recipient or assigned owner, and any applicable timing restriction. If it left immediately, review the recorded exit reason and exclusions. If an email action reports an error, diagnose that error rather than trying to force another enrolment.
Keep the commercial question visible throughout: who is now responsible for answering this enquiry? A completed technical step is only useful if it produces a usable handover.
Test the repair before recovering missed enquiries
Use HubSpot’s workflow testing tools to check supported criteria and simulate a record’s route. The simulation does not execute the actual workflow actions. It evaluates the current version, and passing criteria alone does not override re-enrolment restrictions.
Then run a controlled end-to-end check using test contact details you manage. Include these cases:
- A new contact making a qualifying enquiry.
- An existing contact making another qualifying enquiry after completing the workflow.
- A contact who is still active when a second enquiry arrives.
- An enquiry that should be excluded.
For each, record the expected result first. Confirm the actual submission, contact, enrolment or exclusion, and first follow-up outcome. For an event-based workflow, create the event after activation; repeatedly inspecting an old submission will not demonstrate the repair.
Only then identify the real enquiries missed during the affected period. Ask the sales team which have already been answered, which still need action and which would receive an inappropriate message if replayed.
HubSpot’s manual-enrolment guidance explains that manual entry can bypass starting criteria, but other restrictions still apply. Previously enrolled records require re-enrolment to be configured, and manually enrolled records start at the beginning. Review every action before recovering a selected group.
Give the repaired route an owner and repeat the check after relevant form, integration or workflow changes. BuzzBoost’s email and CRM services and automation services connect that technical work with the follow-up your team needs. If enquiries are arriving without a dependable next step, talk to BuzzBoost about checking the route from submission to sales.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
