walkthrough · operations

Add an approval gate before creating a CRM record

Specify an illustrative n8n approval gate with pending, approved, rejected, and expired states, exact payload binding, and duplicate replay tests.

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

Extend the n8n intake design so a proposed CRM write requires a current, authorized decision tied to the exact record version. Rejection, silence, expiry, and stale approval all prevent a write.

Evidence: illustrative. Verify against the live tool before acting. This is an approval specification for n8n Cloud and HubSpot test records. It has not been executed, independently reproduced, or assigned a successful test date. No screenshot or invented UI label substitutes for a tested gate. Keep live writes disabled.

Stack and permissions to verify

The preceding workflow supplies a Google Sheets proposal, n8n Cloud orchestration, and a HubSpot test destination. The model connection prepares content only. The approval store must restrict decision writes to authorized reviewers and provide trustworthy reviewer identity. A broadly editable sheet checkbox is not sufficient for unattended authorization.

Verify the actual authentication, storage atomicity, expiry checks, and HubSpot write semantics available in your selected configuration. The HubSpot node reference documents contact operations; it does not certify this gate. If you cannot enforce these requirements, use manual execution after review and remain in test mode.

Preparation

Preserve the intake workflow’s validation and duplicate ledger. Define approval fields: action_key, payload_version, payload_reference, destination, state, reviewer_id, decided_at, and expires_at. Keep execution state separate: approved does not mean executed.

Define an allowlist of reviewers and a duration policy appropriate to the task. Bind the reviewed payload to an immutable snapshot or reliable content digest; a digest is a value calculated from content to detect changes. Include destination and action type in the binding. Model output cannot set any authorization field.

Sample states and expected output

Synthetic proposal: action intake:I17:create, payload version 3, destination test-contact, summary “Requests guide setup discussion.”

Synthetic stale case: Reviewer approves version 3. Someone changes the email in version 4. Expected output is a blocked write and a new pending review for version 4. No contact ID is produced. This is a target, not an observed test.

Step 1: create an immutable review proposal

At the end of extraction, capture the exact fields and destination a reviewer will approve. Assign a version and stable action key. Store a pending decision separately from writable model output.

Checkpoint: Modifying the proposal cannot preserve a valid approval for the old content. Confirm the model cannot write reviewer identity or state.

Step 2: capture the reviewer decision

Use a verified authenticated review mechanism, or a manually supervised test procedure while evaluating one. Show the original source, full proposed payload, destination, and action. Record reviewer identity, decision, time, expiry, and payload binding from trusted application data.

Checkpoint: A wrong reviewer, missing decision, or altered client-supplied identity cannot authorize the action. A plain approval flag is not evidence that this check passed.

Step 3: revalidate immediately before writing

Read the trusted decision and current proposal. Check state approved, authorized reviewer, current time before expiry, matching version and payload, permitted destination, and valid required fields. Reject any mismatch before the HubSpot operation.

Checkpoint: Pending, rejected, expired, and changed-payload cases all reach a non-writing outcome with a visible reason. The default branch must stop rather than write.

Step 4: claim the execution

Atomically claim the action key so two workers cannot execute the same approval. Confirm the payload cannot change between checking and executing by using the immutable approved snapshot and an execution transition that protects against races. A separate read followed by an unprotected update is not enough.

Checkpoint: Two simultaneous attempts yield at most one permitted execution. If storage cannot provide this guarantee, disable unattended execution and document the limitation.

Step 5: execute and reconcile

Map only approved snapshot fields to the verified test write operation. Store the resulting destination ID and completion state. If the response is lost, mark execution uncertain; check the destination before deciding whether to retry. Expired approval is not revived by retrying an old run.

Checkpoint: Replaying a completed approval performs no additional write. A recovery that discovers the existing test record records that fact instead of creating another.

Normal and edge-case tests

Record observations, not only workflow branch names. Inspect the test destination for unauthorized effects.

Troubleshooting and stop/recovery

If an old version writes, inspect the payload source and timing of the gate. If repeated approval creates duplicates, inspect the atomic execution claim and destination identity. Disable the write branch during investigation. Preserve decisions and run IDs, reconcile effects, and use the manual intake process until corrected tests pass.

Completed-work checklist and maintenance

Confirm authenticated reviewer, immutable payload binding, expiry, default stop behavior, atomic execution claim, destination reconciliation, and all negative tests. Review reviewer access and stale approvals routinely. Rerun the gate tests after changes to storage, permissions, fields, or destination operations.

Sources and next step

This is an original illustrative extension using the official n8n references for live verification. See approval principles and duplicate recovery. Suggest a correction.