Varrowick is a fictional company, made up for this sample. It is not a client and did not ask for this. No real company's process, data or results appear here. The tools named are real products. The quote follows Omnitics' published prices as of 7 October 2026: simple workflows from $500, production workflows from $1,500, care plan $300 to $800 a month.
A Teardown has four parts, as promised on the Workflow Teardown offer: a diagram, build notes, whether it is a simple or a production build, and a fixed quote.
What Varrowick sent us (fictional)
Everything in this section is the fictional client's own description, sent by email after the short form, in the form a real request takes. No logins, credentials or client data were needed.
The company. Varrowick (fictional) sells scheduling software to mid-size logistics companies. About 140 people, with six SDRs and nine account executives. Their ideal customer: logistics and distribution companies with 200 to 5,000 employees in North America and Europe.
The process, in their words.
Every Monday our marketing-ops manager exports the leads our SDRs set to Unqualified or Bad timing the week before. SDRs pick a reason from a dropdown and add a note. Many pick Other, so the real reason is in the note. The manager reads each one and decides: back into marketing nurture, back to an SDR because someone else at the company is the right person or the timing has changed, or closed for good. Then they update the lead status and add the nurture ones to a static list in HubSpot by hand. In busy weeks it slips, and Bad timing leads sit in Unqualified with no follow-up.
The tools.
- HubSpot Sales Hub and Marketing Hub, both Professional. Lead statuses in use include Unqualified and Bad timing. The reason dropdown: Bad timing, No budget, Not the decision maker, Too small, Using a competitor, Student or job seeker, Vendor or spam, Other.
- The nurture already runs in HubSpot: a HubSpot workflow emails everyone on the Recycled leads static list.
- Slack, with a #revops channel.
- An OpenAI API account.
- Apollo, on a plan with API access.
- n8n Cloud on the Pro plan, already running two small workflows.
Weekly volume. 60 to 110 rejected leads a week.
Who does it today. The marketing-ops manager, about three hours every Monday.
1. The workflow diagram
The workflow, from trigger to summary. Two steps are human checkpoints: no lead's status changes until the marketing-ops owner approves, and every lead sent back to sales gets a decision from the SDR manager.
Text version of the diagram.
- Monday 07:00, the run starts (n8n). Every Monday at 07:00, Varrowick's time, an n8n Schedule Trigger starts the run.
- Pull last week's rejected leads (HubSpot). HubSpot is searched for contacts whose lead status is Unqualified or Bad timing, that were rejected since go-live, and whose review status is still empty, so each rejection is picked up once. A week with none is logged as Nothing to review.
- Check every record (n8n). Every record must have an email and a reason. Records missing either go to a person, not to the model.
- Rules before AI (n8n). Fixed rules, no AI: contacts with a deal, customers and contacts who unsubscribed from all email go to a person. Student or job seeker, and Vendor or spam, are closed. A reason of Other with a note under 10 words goes to a person.
- Refresh company data if stale (Apollo). Only where the reason is about fit (Too small or Other) and HubSpot's company size or industry is missing or more than 90 days old: Apollo is asked for the company's size and industry. At most 40 lookups a run. A lead whose company is not looked up carries on without it.
- Propose a decision (OpenAI). For the rest, an OpenAI model reads the dropdown reason, the SDR's note, job title, company size, industry and country, and proposes one decision with a one-line reason: back to nurture (with a month to check again), back to an SDR, close, or needs a person. Email addresses and phone numbers are removed from the note first.
- Stage proposals in HubSpot (HubSpot, n8n). Every lead's proposal, from the rules or from the model, is written to review fields on the contact, and the run is logged as waiting for approval. Lead status does not change yet.
- Ops owner approves (HubSpot, Slack). Human checkpoint 1. The marketing-ops owner opens a saved HubSpot view of this week's proposals, changes any they disagree with, decides the ones marked for a person, and approves in Slack. Declining, or no answer by Sunday evening, skips the week: those leads come back the next Monday.
- Apply approved decisions (HubSpot). After approval, the workflow reads the owner's final decisions back from HubSpot, not its own proposals, and applies them: nurture leads join the Recycled leads list with lead status Recycled; returned leads get lead status Returned to SDR; closed leads are marked as reviewed and keep their lead status.
- SDR manager decides (Slack, HubSpot). Human checkpoint 2. The SDR manager gets a Slack message listing the returned leads and decides each one in HubSpot: work it, reassign it or close it.
- Log the run, post a summary (n8n, Slack). The run's row in an n8n data table is completed and a short summary goes to #revops.
If anything fails: each call to HubSpot, Apollo, OpenAI and Slack is retried, then logged as failed; an error workflow alerts #revops-alerts; a run that finds more than 500 leads stops before changing anything; a heartbeat alerts if no run has been logged by 09:00 on Monday; a reminder goes out if the batch is not approved by Wednesday at noon; a batch with no answer by Sunday evening is released, and its leads come back the next Monday.
2. Build notes
Written so Varrowick's own team could build it, or we could. Node names are n8n's, checked against docs.n8n.io on 7 October 2026. In a free Teardown, the build notes are as detailed as the process needs. This sample writes out every part in full, including logging, testing and the person checks.
The shape
Three workflows in Varrowick's n8n:
- Lead recycling, weekly: the main workflow, steps 1 to 11.
- Lead recycling, errors: an Error Trigger workflow, set as the main workflow's error workflow.
- Lead recycling, heartbeat: a small scheduled check for a missing run or a waiting approval.
Set up in HubSpot first
In kickoff week, with Varrowick's HubSpot admin:
- Seven contact properties: Rejected on (date); Recycle proposal (dropdown: Nurture, Back to SDR, Close, Needs a person); Recycle decision (the same options, the owner's final say); Recycle reason (one line of text); Recheck month (date, set to the first day of the month); Recycle status (dropdown: Proposed, Applied, Closed); Recycle batch (the Monday date).
- Two new lead status options: Recycled, and Returned to SDR.
- Varrowick's existing Recycled leads static list, plus two saved views: This week's proposals, and Returned to SDR.
- One HubSpot workflow with two jobs: it stamps Rejected on when lead status becomes Unqualified or Bad timing, and it clears Rejected on and the Recycle fields when lead status goes back to New or Open, so a lead rejected again after re-engaging is reviewed again. A lead returned to an SDR and rejected again stays with the SDR manager's decision.
- Lifecycle stage is left alone. HubSpot's tools only move it forward unless the value is cleared first, and whether recycled leads should move back is Varrowick's call. It is outside this quote.
Step by step, in n8n nodes
| Step | n8n nodes | Notes |
|---|---|---|
| 1. Start | Schedule Trigger | Weeks mode, Monday, 07:00. The workflow's Timezone setting is set to Varrowick's, because the Schedule Trigger follows it. If Execution Is Missed is set to Run the Most Recent Missed Execution where the n8n instance supports it, which is checked at build time. The schedule only runs once the workflow is published. |
| 2. Pull | HubSpot (Contact: Search contacts); If; Data Table (Row: Upsert); Slack (Message: Send); Remove Duplicates; If; Stop And Error | Two filter groups, which the node joins with OR. Group 1: Lead status Equal Unqualified, Rejected on Is Known, Recycle status Is Unknown. Group 2: the same, with Lead status Equal Bad timing. Leads rejected before go-live have no Rejected on date, so the first run does not sweep up the old backlog. Only the properties the run needs are returned. Always Output Data is on for the search, so a week with no matches still reaches the next node: an If sends it to a short path that writes this Monday's row in recycle_runs as Nothing to review and posts one line to #revops. Remove Duplicates (Remove Items Repeated Within Current Input) on the record ID. If more than 500 contacts come back, Stop And Error ends the run before anything changes. HubSpot's search returns up to 200 records a page, so at Varrowick's volume this is one or two calls. |
| 3. Check | If | A validation gate as the first step after the pull: email and reason must not be empty. The false branch goes to Needs a person, with missing data as the reason. |
| 4. Rules | Switch | Switch in Rules mode, checked in order: Number of Associated Deals above 0, or lifecycle stage Customer, goes to Needs a person; Unsubscribed from all email goes to Needs a person; Student or job seeker, and Vendor or spam, go to Close; Other with a note under 10 words goes to Needs a person. The Fallback Output (Extra Output) carries everything else to the AI path. |
| 5. Refresh | If; Remove Duplicates; Limit; HTTP Request; Merge | If: fit reason and company data missing or older than 90 days. The leads that pass go straight to input 1 of a Merge. A copy goes through Remove Duplicates (Selected Fields: company domain), so each company is looked up once, then Limit (Max Items 40, Keep First Items), because Apollo charges one credit per company looked up. Then an HTTP Request: GET Apollo's organization enrichment endpoint by domain, with a Header Auth credential for the x-api-key header and the Batching option to space the calls. Its results go to input 2. Merge: Combine, Matching Fields on domain, Output Type Enrich Input 1, so every lead comes out whether or not its company was looked up. A second Merge (Append) rejoins the leads that skipped this step. The HTTP Request's On Error is set to Continue (using error output): a failed lookup is logged in recycle_failures and never blocks a lead. |
| 6. Propose | Edit Fields (Set); Code; Basic LLM Chain; OpenAI Chat Model; Structured Output Parser | Edit Fields with Keep Only Set Fields on keeps only the fields the model needs. A Code node then removes email addresses and phone numbers from the SDR's note. Basic LLM Chain with Require Specific Output Format on, an OpenAI Chat Model sub-node and a Structured Output Parser (Define using JSON Schema). Model chosen at kickoff from Varrowick's OpenAI account, with a low Sampling Temperature. Timeout and Max Retries on the chat model handle API errors. The chain itself has no Retry On Fail; its On Error is Continue (using error output), so a broken output becomes Needs a person instead of a failed run. |
| 7. Stage | Merge; Code; Loop Over Items; HTTP Request; Code; Data Table (Row: Upsert) | A Merge (Append, one input per bucket) brings the rule results, the model proposals and the ones for a person together, so every bucket is staged at once. A Code node counts each bucket for the run log and builds batches of 100 contacts, HubSpot's limit per batch call. Loop Over Items sends each batch through an HTTP Request (Authentication: Predefined Credential Type, the HubSpot credential) to HubSpot's contacts batch update endpoint. It writes Recycle proposal, Recycle decision (pre-filled with the proposal, left empty for Needs a person), Recycle reason, Recheck month, Recycle status Proposed and Recycle batch. A Code node checks each response against the IDs sent; a contact that was not updated goes to recycle_failures and is picked up again next Monday. The exact response shape is checked at build time. Then a Data Table (Row: Upsert) writes this Monday's row in recycle_runs with status Staged and the counts so far. |
| 8. Approve | Slack (Message: Send and Wait for Response); If; HTTP Request; Data Table (Row: Upsert) | Response Type Approval; Type of Approval: Approve and Disapprove; Capture Who Responded on; Restrict Who Can Approve: the marketing-ops owner and one named backup; Limit Wait Time: At Specified Time, 18:00 on the Sunday after the batch (an expression). No answer by then takes the Decline path; what the node outputs at the limit is tested at build time. The message gives the counts per decision (read from HubSpot for the whole batch, so a rerun's message covers everything staged that Monday), the link to the saved view and what Decline does. To approve inside Slack, Varrowick's Slack app needs Interactivity on, with n8n's waiting-webhook URL as the request URL and the app's signing secret in the credential. Without that setup the buttons show in Slack but clicking them does not resume the run, so the dry-run Monday tests the approval end to end. If declined or not answered, an HTTP Request batch update clears the batch's Recycle fields, so those leads come back next Monday with fresh data, and the run's row is set to Declined. |
| 9. Apply | HubSpot (Contact: Search contacts); Switch; HTTP Request; Code | Search for Recycle batch Equal this Monday and Recycle status Equal Proposed, returning only the properties this step needs, so the owner's final decisions are what gets applied. Switch on Recycle decision, with the Fallback Output for any still empty: those stay with the owner and are listed in the summary. Nurture: an HTTP Request to HubSpot's list memberships add endpoint for the Recycled leads list, then a batch update to lead status Recycled and Recycle status Applied. Back to SDR: a batch update to lead status Returned to SDR and Recycle status Applied. Close: Recycle status Closed; lead status is left as it is. A Code node checks each response against the IDs sent, before any status flips to Applied: a contact that was not added or not updated stays Proposed, goes to recycle_failures and is listed in the summary. |
| 10. Returns | Slack (Message: Send) | To the SDR manager: each returned lead with its one-line reason and a HubSpot link, plus the Returned to SDR view. |
| 11. Log | Data Table (Row: Upsert); Execution Data; Data Table (If Row Does Not Exist); Slack (Message: Send) | Upsert this Monday's row in recycle_runs with status Applied, who approved and the decisions applied. The Execution Data node saves the batch date on the execution, so it is easy to find in the executions list; Varrowick's Cloud Pro plan includes this node. Data Table (If Row Does Not Exist) looks for this Monday's row marked Summary posted, so the summary to #revops goes out once per batch, and the row is then marked. |
Why a schedule, not the HubSpot Trigger: the review is a weekly batch for one reviewer, so the run searches HubSpot on Monday morning. The HubSpot Trigger reacts to each change as it happens, and it needs a HubSpot developer app.
Adding to the list: HubSpot switched off its v1 contact lists API on 30 April 2026. The build adds contacts through HubSpot's current list memberships endpoint, using an HTTP Request node with the same HubSpot credential. At build time we check whether the n8n HubSpot node's list step uses the current API, and use the node if it does.
The AI step
- One structured call, not an agent. The step needs no tools: it reads one record and returns one decision. A Basic LLM Chain with a fixed output format is cheaper, faster and easier to test than an AI Agent.
- Why not the Text Classifier node: it routes each lead down a branch, but the owner needs a one-line reason beside each proposal to review the batch.
- Output format (JSON Schema): decision (nurture, back_to_sdr, close or needs_person); reason (at most 25 words, with no personal details); recheck_month (a year and month, only for nurture), written to Recheck month as the first day of that month.
- What it is sent: the dropdown reason, the SDR's note, job title, company size, industry, country, Varrowick's ideal customer in two sentences and what each decision means. What it is not sent: the contact's name, email address, phone number or any other field on the record. A Code node removes email addresses and phone numbers from the note first. A note can still mention a person, so the model is told not to repeat personal details.
- The prompt tells the model to answer needs_person whenever the note does not support a decision. We do not use a confidence score from the model: thin notes go to a person by rule before the model, and the owner sees every proposal anyway.
- Prompt and rules are tuned on Varrowick's last four weeks of hand-made decisions, from the manager's weekly sheets, run inside Varrowick's n8n. Disagreements are reviewed with the owner. We do not promise an agreement rate; the dry-run Monday shows how it does on live data.
- Model usage bills to Varrowick's OpenAI account: one call per lead that reaches this step, so at most about 110 a week at the stated volume.
- If Varrowick's policy rules out sending SDR notes to an AI provider, the rules-only version in section 3 is the alternative.
Errors and retries
The validation gate, duplicate protection, the error workflow and the heartbeat are explained in our post on why n8n workflows break in production.
- Retry On Fail on every node that calls HubSpot, Apollo or Slack: Max Tries 3, with a wait between tries. The OpenAI call retries through the chat model's own Max Retries, so a failing lead is not retried twice over.
- Rate limits: HubSpot writes go in batches through Loop Over Items, and Apollo calls are spaced with the HTTP Request node's Batching option (Items per Batch, Batch Interval). At this volume a run makes about a dozen HubSpot calls at most, so HubSpot's rate limits are not a concern; the writes are batched and spaced anyway.
- Items that still fail take the error output (On Error: Continue (using error output)) and are written to a recycle_failures data table (record ID, step, error, time; no note text). A lead whose AI step fails goes to Needs a person; a failed Apollo lookup only means the lead carries on without fresh company data. One bad record never stops the other hundred.
- Whole-run failures go to the error workflow: an Error Trigger, then a Slack message to #revops-alerts with the workflow, the failed node, the error and the execution link, then a row in recycle_failures. The error workflow does not need publishing, and it only fires on automatic runs, so it is tested on a scheduled run.
- Circuit breaker: more than 500 contacts at step 2, about five times the top of Varrowick's range, means Stop And Error before anything changes. A bulk status change or a broken filter must not flood the nurture list.
- Heartbeat workflow: one Schedule Trigger with two rules. Monday 09:00: if recycle_runs has no row for this Monday, in any status, it alerts #revops-alerts. Wednesday 12:00: if this Monday's row is still Staged, it reminds the owner. A schedule that fails to fire raises no error, which is why the heartbeat exists. It runs in the same n8n, so an outage of the whole n8n account needs a check from outside n8n, which is outside this quote.
Duplicates and reruns
- The processing state lives on the contact in HubSpot: empty, then Proposed, then Applied or Closed. Step 2 only picks up empty ones and step 9 only touches this batch's Proposed ones, so rerunning a failed run processes no one twice. A batch that is declined, or not answered by Sunday evening, is cleared back to empty, so its leads are reviewed again the next Monday instead of waiting for good.
- In the apply step, the list add runs before the status flips to Applied. If a run stops between the two, the contact is still Proposed and the next attempt finishes it.
- Remove Duplicates drops repeated record IDs across search pages and repeated company domains before Apollo, so no lead is proposed twice and no company is paid for twice in a run.
- The run log has one row per Monday, written by upsert, so a rerun updates it instead of adding a second. The Slack summary is posted once per batch, checked against that row first.
- The state is kept in HubSpot rather than in n8n's own dedupe history, so Varrowick's team can see it in their CRM and it survives a rebuild of the workflow.
Credentials and access
- Built in Varrowick's own n8n Cloud account. Every credential sits in Varrowick's n8n credential store, and n8n stores credentials encrypted in its database.
- HubSpot: a HubSpot service key, which n8n's docs recommend now that HubSpot has moved private apps made in its UI to legacy status. Service keys are in public beta (n8n's docs, read 7 October 2026), so at kickoff Varrowick's admin chooses between a service key and OAuth2. Varrowick's HubSpot admin creates the key and pastes it into the n8n credential, so it is never sent to us by email or chat. Scopes limited to what the run needs: crm.objects.contacts.read, crm.objects.contacts.write, crm.schemas.contacts.read and crm.lists.write, confirmed against HubSpot's endpoint docs at build time.
- Slack: an OAuth2 credential for a Varrowick Slack app, with scopes trimmed to posting and approvals (plus users:read and users:read.email for Capture Who Responded), Interactivity on, the signing secret in the credential, and token rotation off. n8n's docs warn that rotated tokens expire after 12 hours and that rotation cannot be turned off once on, so an existing app that has it is replaced with a new one.
- OpenAI: an API key used only by this workflow, so its usage can be watched and the key revoked on its own.
- Apollo: a Header Auth credential carrying the x-api-key header.
- No Varrowick records are copied to Omnitics systems: the test set, the past decisions and the logs stay in Varrowick's HubSpot and n8n. An NDA and a data processing agreement are available on request. Our build access is removed at handover. On the optional care plan, only the access its quote lists stays open.
- The exported workflow JSON names the credentials but holds no secrets. It is handed over and kept in Varrowick's own repository or drive.
Logging
- recycle_runs data table, one row per Monday: status (Staged, Applied, Declined or Nothing to review), leads found, closed by rule, sent to a person, proposed by the model, Apollo lookups, who approved and when (the responder's Slack user ID and name from Capture Who Responded, not their email), decisions applied, failures and whether the summary was posted.
- recycle_failures data table: record ID (or the company domain, for an Apollo lookup), step, error, time. No note text, names or email addresses, so the log holds as little personal data as it can.
- Data tables live inside Varrowick's n8n instance. n8n's default cap is 200 MiB across all tables; this workflow adds about 52 small rows a year, plus failures.
- The Execution Data node tags each execution with the batch date.
- Workflow settings: save failed and successful production executions, with Redact production execution data set to Redact, so node inputs and outputs, which include each lead's note, are hidden in the executions list. The run and failure tables carry what is needed to trace a problem within the 30-day fix window. If redaction is not available on Varrowick's plan, which is checked at build time, successful production executions are not saved, failed ones are, and Varrowick decides how long they are kept.
Testing
- Build on pinned data: 25 made-up records covering every reason and edge case: a thin note, an unsubscribed contact, a contact with a deal, a missing domain, two leads at one company, a failed Apollo lookup, a run past the 40-lookup cap and a week with no rejected leads. n8n uses pinned data only in manual runs, never in production.
- A broken model output is tested with a real call, using a test prompt that asks for the wrong shape, because pinned output would skip the parser.
- End to end against 10 test contacts in Varrowick's HubSpot, set as non-marketing contacts, marked as tests and deleted afterwards.
- The past-decision set: steps 3 to 6 run over Varrowick's last four weeks of decisions; the proposals are compared with what the manager decided, and rules and prompt are adjusted with the owner.
- Failure drills: a wrong HubSpot key on a copy of the credential, an Apollo timeout, a broken model output, a declined approval, an approval left to time out (with a short test limit), and a manual run fed 600 made-up leads as pinned data, so nothing is created in HubSpot. Each must alert or stop as designed and change nothing it should not.
- Dry-run Monday: the first real run stages proposals with the apply step switched off. The owner reviews, we fix what they flag, and the workflow goes live when they sign off.
- After handover: any change to lead statuses, the reason dropdown or the list means rerunning the past-decision set before the next Monday.
What a person checks, and when
| When | Who | What |
|---|---|---|
| Monday, after 07:00 | Marketing-ops owner | Review this week's proposals in the HubSpot view, change any that are wrong, decide the ones marked Needs a person, then approve or decline in Slack. |
| Within a day of the owner's approval | SDR manager | Each lead returned to sales: work it, reassign it or close it. |
| Wednesday 12:00, only if not yet approved | Marketing-ops owner | The reminder: approve or decline this week's batch. With no answer by Sunday evening, the batch is released and its leads come back the next Monday. |
| Any alert in #revops-alerts | Whoever owns the channel, or Omnitics on a care plan | Read the alert, open the execution, fix or rerun. |
| First Monday of the month | Marketing-ops owner, or Omnitics on a care plan | Spot-check 10 applied decisions against their notes, read the run and failure tables, filter recycled leads by Recheck month to see who is due, and see whether Other is still the most common reason. |
| Before changing lead statuses, reasons or the list | Marketing-ops owner | Rerun the past-decision set. |
What it will not do
- Send any email or message to a lead. HubSpot's existing nurture does that, under Varrowick's existing subscription settings.
- Change lifecycle stage, marketing contact status or contact owner, or delete anything.
- Decide on a contact with a deal, a customer, or a contact who unsubscribed from all email. Those go to a person.
3. Simple or production build
A production build. Omnitics' simple build is one trigger, up to two apps and no AI step. This workflow has one trigger but four apps (HubSpot, Slack, OpenAI and Apollo) and an AI step. It changes lead records the pipeline depends on, and it needs a human approval, duplicate protection, an error workflow and a heartbeat: the production guards.
The cheaper path, and why we do not recommend it. A rules-only version would map the dropdown reason straight to a lead status and the list, with a Slack summary. That fits the simple scope (one trigger, HubSpot and Slack, no AI step), from $500, with a failure alert and a one-page doc. It has no approval step, circuit breaker or heartbeat, so a wrong rule changes lead statuses before anyone checks. HubSpot's own workflows could also do it, since Varrowick already uses them for the nurture. We do not recommend either here: many SDRs pick Other, so the reason that matters is in the note, and only the AI step reads notes.
4. Fixed quote (sample)
$2,000, fixed. A production workflow, one price agreed before work starts. Prices in US dollars.
What it covers
- A 45-minute kickoff to confirm the decision rules, the reviewer, the SDR manager and the HubSpot changes.
- The HubSpot setup in section 2, done with Varrowick's HubSpot admin.
- One production workflow, built as three n8n workflows: the weekly run, plus its error workflow and heartbeat. Those two are part of the production guards and are not priced separately.
- The AI step, with prompt and rules tuned on Varrowick's last four weeks of decisions.
- The production guards: the validation gate, retries, duplicate protection, the circuit breaker and the failure table.
- The monitoring hook: the error workflow and the heartbeat, both alerting #revops-alerts.
- The tests, including the failure drills and the dry-run Monday.
- A runbook (what each step does, how to pause the run, how to add a reason, how to rotate a key) and a recorded walkthrough.
- A 30-day fix window from handover, which is go-live at the end of week 2: if the workflow does not do what this Teardown and the runbook say, we fix it at no charge.
Not included
- n8n, HubSpot, Slack, OpenAI and Apollo subscriptions and usage, which bill to Varrowick's own accounts.
- Writing or changing the nurture emails or the HubSpot nurture workflow.
- Moving lifecycle stage backwards, changing marketing contact status or reassigning owners.
- A pass over leads rejected before go-live. A one-off backlog run can be quoted separately.
- Acting on Recheck month. It is written so Varrowick's team can build a HubSpot view or a later workflow on it. A monthly recheck run can be quoted separately.
- Monitoring from outside n8n, for an outage of the whole n8n account.
- A Salesforce version.
- Changes after the fix window, which go to a care plan or a new fixed quote.
What the price assumes
- Up to 150 rejected leads a week; Varrowick says 60 to 110. Well above that, the weekly review needs a different shape, and any change is agreed in writing first.
- The SDR reason and note are already two contact properties in HubSpot.
- Varrowick's HubSpot admin creates the service key (or sets up OAuth2) and approves the HubSpot changes; Varrowick's Slack admin approves the Slack app.
- n8n Cloud stays on the Pro plan. On a plan without the Execution Data node, the batch date goes in the run table instead, at the same price.
- No workflow timeout on Varrowick's n8n plan cancels the week-long approval wait. This is confirmed at kickoff.
- Apollo API access, with credits for up to 40 lookups a week.
- One named reviewer, one named backup approver and one SDR manager, with the reviewer and the SDR manager each giving about 30 minutes on the dry-run Monday.
- For the build only: an n8n member account and a HubSpot user for Omnitics, removed at handover.
Delivery. We plan for it to go live within two weeks of kickoff, once access is in place. Week 1: the HubSpot setup, the build and the tests. Week 2: the dry-run Monday, fixes, sign-off and switch-on. The 30-day fix window starts at handover.
Optional care plan: $400 a month for this workflow, inside Omnitics' published $300 to $800 range. In a real quote, this part sets out the access we keep, the response window, what counts as a fix and the changes included each month.
Sources, read on 7 October 2026
- n8n documentation: every n8n node and setting named in the build notes.
- n8n: HubSpot credentials: service keys are recommended and in public beta; HubSpot has moved private apps made in its UI to legacy status; the HubSpot Trigger needs a developer app; the scopes.
- n8n: Slack approvals: Capture Who Responded, Restrict Who Can Approve, the users:read scopes and the Slack app setup.
- n8n send-and-wait options in the node source: Type of Approval (Approve Only or Approve and Disapprove) and Limit Wait Time.
- n8n: Slack credentials: rotated tokens expire after 12 hours, and rotation cannot be turned off once on.
- n8n: workflow settings: timezone, error workflow, saving production executions and Redact production execution data.
- n8n: Schedule Trigger: If Execution Is Missed, which needs the durable scheduler.
- n8n: Merge node: Append with several inputs, and the Enrich Input 1 output type.
- n8n: OpenAI Chat Model: Sampling Temperature, Timeout and Max Retries.
- n8n: data tables: the default 200 MiB cap across all tables.
- n8n: Execution Data node: available on n8n Cloud Pro and Enterprise.
- HubSpot: v1 lists migration guide: the v1 contact lists API was sunset on 30 April 2026.
- HubSpot: search the CRM: 200 records a page, and filter groups joined with OR.
- HubSpot: contacts API guide: batch operations take up to 100 records at a time.
- HubSpot: lifecycle stages: HubSpot's tools only move lifecycle stage forward unless the value is cleared first.
- HubSpot: default contact properties: Number of Associated Deals, Unsubscribed from all email and Marketing contact status.
- Apollo: organization enrichment: GET by domain, the x-api-key header, one credit per organization.