Shopify sent the webhook. n8n ran. So where is the CRM record?

First, distinguish three independent claims

Delivery: Shopify attempted to send a notification to an endpoint. Execution: your automation system recorded processing activity. Business outcome: a separate destination system has the intended customer, order or CRM object. These claims have different evidence owners; treating them as interchangeable is where incident reports become misleading.

Start with Shopify's official webhook troubleshooting and delivery logs, then use n8n's execution list. For the final claim, inspect the authorized CRM or database itself. Our little tools cannot log in to any of them.

One fictional incident, four tiny CSV excerpts

Imagine a shop whose order events trigger an n8n workflow that creates CRM entries. The team has a pseudonymous delivery CSV, a workflow execution CSV, a downstream receipt CSV and an optional expected-source CSV. The free incident chain loads an entirely synthetic four-file scenario when you press Load and run fictional example. You do not need to create a real account or supply your own data to reproduce it.

How the three existing tool blocks cooperate

Block 1 — Webhook Delivery ID Audit: checks the three-column delivery_id,event_id,topic observations for duplicate rows, reused delivery IDs and event relationships. Different delivery IDs can legitimately be associated with the same merchant action, so an event ID should not blindly be treated as the deduplication key for all subscriptions.

Block 2 — Outcome Reconciler: checks the event_id,execution_id,status, event_id,receipt_id and optional expected-event snapshots. In the fictional case it finds two success-status rows without matching receipts, one expected source event without execution, and several other reasons for review. These categories can concern different records or overlap; don't add them to claim a number of lost orders.

Block 3 — Workflow Investigation Handoff Pack: takes the two actual intermediate report objects through the versioned moruneva.block-input.v1 contract, validates both again and produces a count-only, identifier-redacted JSON handoff plus a readable plain-text checklist. The application never needs you to download the first two JSON files and paste them back into another page.

Raw CSVs → Webhook ID Audit ────────┐
          Outcome Reconciler ───────┼→ versioned report inputs
                                    ↓
                           Workflow Handoff Pack
                                    ↓
                      Redacted JSON + readable TXT

The report is only a composition of separate summaries, not a join of Shopify records to n8n and CRM identities. Alignment of store, topic, environment, timezone and export period remains a human responsibility.

What should the next operator check?

1. Verify the source scope. Compare the relevant merchant, subscription, topic, time window and logging delay. Shopify's delivery logs may not be current to the second.
2. Check delivery authenticity. For HTTPS deliveries, follow Shopify's HMAC verification guidance on the original request body. A CSV column is not a signature check.
3. Understand retries and deduplication. Decide whether repeated observations came from retries, duplicate exports or multiple subscriptions. Use the delivery identifier in the correct per-delivery idempotency scope; protect real side effects with durable server-side rules.
4. Inspect n8n executions. Look at the real execution status, filters, error branches, retry history and timing. A status label in a CSV is not an audit of the workflow engine.
5. Verify the CRM object. Look for the authorized destination record and inspect its business state, not only a matching receipt ID. Assign a human owner and document what was actually confirmed.

Privacy and limitations, by design

The chain executes in your browser with source CSVs provided by you. It does not upload them, persist them, contact Shopify or n8n, infer permissions, or call an AI model. Intermediate original reports may contain sensitive IDs inside local memory; only the allowlisted, aggregate handoff is offered for download. Browser extensions, the user's computer and anything pasted into the page remain outside the tool's guarantee. Use invented identifiers or authorized, pseudonymized data, and review even the redacted output before sharing.

There is intentionally no login, automated CRM fix, scheduled monitoring or paid plan here. For a team already using Shopify's native monitoring, n8n execution history and a spreadsheet, those tools may be a better choice. This prototype tests whether a unified explanation and export reduce the work of switching between three narrowly scoped analyses; it is not evidence of customer retention or willingness to pay.

Try the composed tool, then decide if it saved work

Open the local demo, press the fictional-example button and compare its investigation checklist with what you would otherwise write manually. Change one source row and watch the old downloads disable until you re-run. If it saves steps in a real permitted situation, tell us which manual step mattered most—without sending customer records or identifiers.

Open the free incident chain →

Primary documentation

• Shopify — Verify webhook deliveries: HMAC, duplicate delivery handling and reconciliation.
• Shopify — Troubleshoot webhooks: delivery metrics, retry information and recovery from outage.
• n8n — All executions: viewing, filtering and retrying workflow executions.

Sources checked 29 October 2026. The CSV case and reported counts are fictional and reproducible; no claim of a real merchant incident, customers, revenue recovered or ranking lift.