walkthrough · operations

Build a client-intake review workflow in n8n

Follow an illustrative n8n Cloud intake design from synthetic sheet rows to reviewed fields and an approved HubSpot test record, with recovery checkpoints.

Author: Founder identity pending confirmation
Published: Pending first public release · Fact-check: Human review pending
intermediate · build · Approximately 5 minutes to read
Evidence: illustrative · Maintenance: needs retest
Action authority: human approved action · Data: public
Approach: AI-assisted workflow
Last tested: Not yet tested

Outcome and scope

Prepare reviewed intake fields in n8n Cloud, then create a HubSpot test record only after explicit approval. The fixed sequence uses Google Sheets for synthetic intake and a separate review queue. The model extracts a proposal; it does not choose actions.

Evidence: illustrative. Verify against the live tool before acting. This step-by-step walkthrough is a written configuration specification, not an executed demo. No screenshots, successful test date, model identifier, measured setup time, or account-plan capability is claimed. Keep live connections disabled until reproduced in dedicated test accounts.

Stack and permissions to verify

The official Sheets node and HubSpot node document available operations. Confirm actual scopes, account capabilities, contact matching behavior, field mappings, model settings, and charges in your accounts. In particular, do not treat a create/update operation as create-only without verifying its behavior.

Preparation

Complete the intake playbook. Create input columns intake_id, source_version, name, email, service, and request_text. Create review columns for those identifiers plus summary, evidence, validation_errors, review_version, and decision. Keep authorization metadata separate from model-writable fields.

Prepare an action ledger and a test-log sheet. Establish a stable key such as intake:I17:create. A sheet search followed by append does not enforce atomic uniqueness. Until a verified atomic claim or destination uniqueness mechanism exists, limit work to manually supervised draft tests; do not enable unattended CRM writes.

Sample input and expected output

Synthetic input: I17, version 1, Sam Sample, [email protected], onboarding, “Please discuss setting up our guide.”

Expected proposal, not an observed response:

{"intake_id":"I17","source_version":1,"service":"onboarding","summary":"Requests a discussion about guide setup.","evidence":"Please discuss setting up our guide.","decision":"pending"}

The application sets decision to pending. It must not accept a model-provided approval value. A CRM ID is absent until a verified write succeeds.

Step 1: read one isolated row

Create a manually triggered test workflow in n8n Cloud. Add a Google Sheets read operation for the dedicated input sheet and select I17. Keep scheduling and live event delivery off. Validate the ID, version, required fields, and approved service category before continuing.

Checkpoint: Execution data contains one intended synthetic row and no unrelated fields. Missing ID or text produces a visible exception.

Step 2: check action identity

Look up the stable action key in the ledger. Completed entries stop without another create. In-progress or uncertain entries go to reconciliation. For a new proposal, record its input version and state using the verified claim mechanism, or remain in draft-only test mode.

Checkpoint: Replaying I17 does not create a second logical proposal. Record the result; do not infer concurrency safety from sequential runs.

Step 3: extract a bounded proposal

Configure a supported model request. Supply only service categories and the synthetic request. Ask for category, summary, and verbatim source evidence; unknown information must stay unknown. Tell the model to treat input instructions as data. Copy identifiers and contact fields from validated source data outside the model.

Checkpoint: Inspect outgoing input for unnecessary fields. Validate returned structure, category, and source support. Invalid output routes to an exception, not a CRM operation.

Step 4: write and review

Store the proposal as text in the review sheet, preventing formula interpretation. A person compares original input and proposal, records a decision, and identifies the exact reviewed version. A simple editable flag is suitable only for an isolated manual demonstration; it is not proof of authenticated approval.

Checkpoint: Pending or rejected proposals cannot reach the write branch. Use the approval-gate extension to specify reviewer identity, expiry, and payload binding before unattended execution.

Step 5: verify the gate and destination

Immediately before a test write, recheck approval, unchanged version, destination, duplicate claim, and test account. Search for a matching external reference using a verified field strategy. Do not rely on email alone as a unique submission key. If the configured operation could update an existing contact, stop unless that behavior is explicitly within scope.

Checkpoint: Only the approved payload reaches the intended test destination. Inspect the created record and store its actual ID in the ledger. A response loss creates an uncertain state requiring reconciliation.

Normal and edge-case tests

Record actual output, verdict, corrections, retries, charges, and rerun result. No case is marked passed by this document.

Troubleshooting and recovery

Wrong columns indicate mapping or header problems: inspect the single test row before another run. An existing contact changed unexpectedly indicates incorrect write semantics: stop and inspect the destination. A duplicate indicates inadequate identity or atomicity controls, not a reason to delete ledger history.

Stop the trigger, preserve run IDs, and handle new intake manually. Reconcile destination state before replaying uncertain writes. Resume only after the owner reviews corrected fixture results.

Completed-work checklist and maintenance

Confirm isolated input, validated fields, bounded model request, review evidence, non-executable pending states, duplicate controls, recorded destination IDs, and a usable fallback. Record actual configuration and test results; keep evidence illustrative until reproduction succeeds. Review failures, access, source categories, and queue backlog regularly and rerun tests after changes.

Sources and next step

Official node references above establish available integration operations, not this workflow’s success. Continue with the approval gate and duplicate recovery guide. Suggest a correction.