Fictional proof sample · not a client claim

Sample rescue packet / R-001

Lost leads after a form field update.

This packet demonstrates the evidence, repair boundary, verification, and handoff a tightly scoped workflow rescue should produce.

Stack: Form → Webhook → CRMSeverity: HighTarget: 1–3 business days

Observed path

01Lead form200 submitted
02WebhookPayload received
03CRM create422 rejected
04Sales ownerNever notified

01 / Evidence

Prove the break before changing the system.

Last known good

June 18 · 14:31

Payload contained the required phone_number key.

First failure

June 18 · 15:04

Form update renamed the outgoing field to phone.

Visible symptom

CRM HTTP 422

Email confirmation succeeded, masking the failed CRM handoff.

ROOT CAUSE

Schema drift at the CRM mapping step

The form changed one outgoing key. The workflow treated the CRM rejection as a completed run, so no retry or human alert fired.

02 / Written repair boundary

Fix one path without turning it into an open-ended rebuild.

Included

  • Preserve the original workflow configuration
  • Accept current and legacy phone-field names
  • Normalize valid phone values before CRM submission
  • Route invalid payloads to a visible exception queue
  • Alert the workflow owner after a rejected CRM request

Explicitly excluded

  • Replacing the form or CRM
  • Rewriting unrelated nurture sequences
  • Enriching or purchasing lead data
  • Changing sales ownership rules
  • Repairing historical records without a separate scope

The agreed definition of done

“A new test submission using either supported phone-field name creates exactly one CRM contact, assigns the sales owner, and produces a visible alert if the CRM rejects the request.”

03 / Smallest safe repair

Change the mapping, add validation, expose failure.

Beforefragile mapping
{
  "phone_number": payload.phone_number,
  "email": payload.email
}
Aftercompatible + observable
const phone = normalize(
  payload.phone_number ?? payload.phone
)

if (!phone) routeToException(payload)
else createOrUpdate({ phone, email })

onReject(alertWorkflowOwner)

Example logic only. A real repair uses the client’s actual platform, node types, API contract, test data, and access controls.

04 / Verification packet

Pass the edge cases, not only the happy path.

TestInputExpected evidenceResult
T-01Valid phone_numberCRM contact created oncePASS
T-02Legacy phone fieldMapped, normalized, created oncePASS
T-03Missing phoneException queue; no bad CRM recordPASS
T-04Repeated webhook eventExisting contact updated; no duplicatePASS

Executable proof

Import the credential-free n8n workflow.

The downloadable JSON was imported and executed with n8n 2.31.7. The final node returned all_passed: true, four PASS results, one exception event, and one duplicate update. It performs no network requests.

6 nodes4 verified behaviorsNo credentialsSHA-256: E8F0ED47…D331B5A
Download n8n workflow

05 / Handoff

Leave the owner with control.

01

Change record

Exact nodes, mappings, and alerts changed.

02

Evidence

Test inputs, execution IDs, outputs, and timestamps.

03

Rollback

Restore the preserved configuration if a regression appears.

04

Owner checklist

Revoke temporary access and watch the next live executions.

Have a real failure?

Send one broken path.

You will get a fit answer before any paid diagnosis or repair begins.

Request a scoped rescue