The HubSpot Intelligent Lead Routing & Response System is a four-workflow n8n package. This guide explains the decisions an operator must make around that package. The architecture blueprint describes the broader pattern; the package README has the exact import steps, credentials, SQL, and setup values.
Start with a sandbox. The default dry run blocks outbound email, but it still writes to HubSpot and calls paid ZeroBounce and OpenAI APIs. Nothing in the downloadable validation report establishes that your live account permissions, owner roster, concurrency, or delivery work.
1. Decide what the intake is allowed to accept
Put a trusted backend between your public form and n8n. The backend calls the authenticated intake webhook with a stable UUID submission_id and an email. Name, company, message, service interest, and page context are optional. The response_requested value must be a real JSON boolean from the trusted backend; the string "true" does not grant send permission. Keep the webhook secret out of browser code.
The intake stores the validated request in a dedicated PostgreSQL application database and returns HTTP 202. 202 means queued, not assigned, scored, or emailed. A repeat of the same UUID and identical payload is accepted as a duplicate; reusing that UUID with different data is rejected. The sample webhook payload shows the expected shape.
| Input decision | Operator check |
|---|---|
Stable submission ID | The form backend retries the same event with the same UUID instead of creating a new one. |
Email and permission | A syntactically valid address still needs validation; consent and suppression are separate checks. |
Service context | Replace sample offerings with your approved service catalog before interpreting a score. |
Acceptance response | Track the queued job and HubSpot contact rather than treating webhook success as the final result. |
2. Preserve ownership before assigning a new rep
The worker looks up the email in HubSpot. Existing contact owners, lifecycle stage, and nonempty contact fields are preserved. New, unowned contacts use an atomically advanced rotation among reps marked available in the configuration. That flag is not live calendar presence. An existing owner outside the configured roster stays assigned, but the first response is held for review.
For a fictional example, suppose [email protected] submits a request for an approved service. If the matching HubSpot contact already belongs to Rep A, the worker keeps Rep A; it must not rotate the inquiry to Rep B. If no matching contact or owner exists, the worker can create the contact and use the configured rotation. If every configured rep is unavailable, the job needs operator attention rather than a made-up owner.
Check the contact record and queue status together. HubSpot does not offer a transactional owner comparison across every outside edit here; the workflow makes a fresh owner check before sending, and a late outside edit still needs monitoring.
3. Treat classification and send permission as different decisions
ZeroBounce supplies an email-validation result. OpenAI returns bounded fit, intent, urgency, evidence, and a draft. Code validates that structure and assigns Hot, Warm, Cold, or Review using the configured rubric. A Hot or Warm label by itself does not permit an email.
The package holds Cold, low-confidence, malformed, unsupported, opted-out, stale, and excluded customer inquiries. Before sending it checks the current email, owner, suppression flags, validation result, lifecycle, response state, and the trusted response_requested boolean again. An optional Slack Hot-lead alert is a separate notification, not proof of delivery to the prospect. Review your labeled leads and false positives before turning on any live send switch.
In the fictional example, a high score may create a draft for Rep A. If the contact opts out while that draft waits, the fresh suppression check blocks the send. If the model returns malformed JSON or an unsupported service, the operator reviews the record and evidence; it does not become an automatic Hot lead by default.
4. Test the actual side effects before activation
Import the four .n8n.json files and bind their instance-specific credentials and workflow references. Run the supplied database setup and smoke test in the dedicated application database, not n8n's internal database. Workflow 03 creates HubSpot properties manually; workflow 04 handles errors and stalled jobs. Follow the package setup manual for the complete sequence.
Keep dry_run: true and auto_send_enabled: false while using a HubSpot sandbox or controlled test contacts. Dry run still changes CRM records and can incur validation and model costs. Test at least:
- A new valid inquiry, an existing owned contact, and an unavailable or unknown owner.
- An identical retry and a conflicting reuse of the same submission ID.
- Invalid or risky email, opt-out, unsupported service, Cold lead, low confidence, and malformed model output.
- A suppression or owner change while a draft is waiting.
- A provider response that is accepted but not yet confirmed as delivered, plus a HubSpot logging failure after acceptance.
Inspect the queue, contact, owner, score evidence, draft, and execution for each case. Do not infer production readiness from the sample preview. The supplied validation report covers local checks; it excludes live provider behavior and actual email delivery.
5. Recover without sending the same message twice
The package records a provider request and send reservation before attempting Resend. It uses an idempotency key and a per-email cooldown, but neither removes the need to reconcile uncertain outcomes. Provider acceptance is recorded separately from delivery. If HubSpot logging fails after provider acceptance, check the provider and CRM activity timeline before creating a missing log entry; do not replay the whole worker or resend the email.
Workflow 04 reports failures, stalled work, review holds, alert failures, and logging holds. An unresolved send stays blocked for operator reconciliation. The manual's recovery instructions distinguish a failure before any send attempt from an attempted send whose outcome is unknown. Preserve the queue and send-guard history because it is part of duplicate prevention.
Choose the next action
- Implement this package: Open the HubSpot routing template, download its ZIP, and use its full setup manual.
- Understand the wider system: Read the lead-routing architecture.
- Check your stack: Review n8n, HubSpot, and the package's other credentials before testing.
- Adapt it to your process: Review revenue-operations services or find a different workflow.
This is an implementation explanation based on the supplied package and its local validation. The scenario is fictional. It is not a customer result or evidence of a live n8n, HubSpot, PostgreSQL, Resend, or Slack deployment.