Approve every cold outbound list before a single email sends

Build me a staging desk for cold outbound where I approve a prospect list before a single email goes out. Bad rows in a cold sequence burn a sending domain and embarrass us in front of customers, so nothing reaches a sequence until I have looked at the batch and ticked the rows myself.

Batch intake, two ways. On a New batch screen I either pull people I already have or paste in a fresh list. Path one uses LeadsForge List Contacts with its tag and validation status filters, so I can stage, for example, every contact tagged saas-uk whose validation status is valid. Path two uses Google Sheets Get Values against a spreadsheet ID and an A1 range I supply, then lets me map the sheet columns onto email, first name, last name, company and job title before importing. Either path creates a named batch stored in the app with its rows, its source, and the filters or range it came from.

The review grid is the heart of the app. Every staged row shows the contact's validation status and tags from LeadsForge, using Get Contact to fill in detail on a row when I expand it. Alongside that, run a live check against our CRM: HubSpot Search Contacts by email address, and HubSpot Search Deals for deals associated with any contact that matches. Classify each row into one of three states and show it as a clear badge: Existing customer, Open deal, or Net new. When there is a match, show me which HubSpot record it hit and the deal name and stage, so the classification is never a mystery. Cache the CRM verdict on the row with the time it was checked, and give me a Recheck CRM action on both a single row and the whole batch.

Make the CRM conflict a hard block, not a soft warning. Rows classified as Existing customer or Open deal cannot be ticked for enrollment. Their checkbox is visibly disabled with the reason attached rather than hidden from the grid, because I still want to see who got caught. The only way past it is to change the blocking rule on a Settings page, which is deliberate friction. Never enroll a person who already has an open HubSpot deal or is an existing customer.

Give the grid a Screen this batch button that starts a background agent. The agent reads my written ICP definition, which lives as an editable block of text on a Settings page, and works down the staged rows one at a time. For each row it decides on profile or off profile and writes a one line reason back onto the row, things like wrong seniority, free mail domain, or an account someone is already working. It can call LeadsForge Get Contact for fuller detail on a person, and HubSpot Search Contacts and Search Deals to see whether a rep is already engaged with that account. Its verdict, reason and run time land on the row so the grid can display and sort by them. Rows it flags off profile get automatically unticked but stay visible, and I can always tick one back on if I disagree. Show progress while it runs, since a big batch takes a while.

Then I enroll. After I have unticked what I do not want, an Enroll approved rows action opens a confirmation step. I pick the destination sequence from a list built with LeadsForge List Sequences, and before I confirm you show me what that sequence already holds using Get Sequence Contact Count, how many rows I am about to add, and the resulting total, compared against a capacity ceiling I set per sequence. If the batch would push the sequence past that ceiling, say so plainly and make me acknowledge it, so I can see I am not oversubscribing a sequence beyond what my sending capacity can carry.

Route the enrollment by what each row actually is. Rows that already exist as LeadsForge contacts go in with Assign Contacts To Sequence. New people from a spreadsheet go in with Bulk Create Contacts in chunks of at most 100 per call, which is the documented cap, followed by Assign Contacts To Sequence. Use Create Contact for a one-off single addition, and Import Lead Into Sequence when I want create and enroll handled in a single step for an individual row. Show per chunk progress and finish with a summary of how many were enrolled, skipped and failed, keeping any failures on the batch so I can retry just those.

One important constraint to respect. LeadsForge exposes validation status only as a read filter on List Contacts. There is no documented operation to run a validation job or to add someone to a do-not-contact list, so the app displays and filters on validation status but must never claim to verify addresses itself and must not offer a do-not-contact action. Rows with no validation status stay visible and filterable rather than being silently dropped or shown as safe.

Persist batches with their name, source, creation date and status of staging, screened or enrolled. Persist each row with its contact fields, validation status, tags, CRM classification and matched record, the agent verdict and reason, and my approval tick. Persist the ICP text and the per sequence capacity ceilings. Keep a history of past batches so I can look back at exactly which rows I approved, which the agent flagged, and which sequence they went into.