# Demonstration incident report: duplicate CRM records

**Fictional example only. No customer test was run. Every observation, timestamp, identifier and result below is invented to show the reporting format. This is not a testimonial or evidence that the proposed stack works.**

## Summary

One synthetic form submission is shown producing two CRM records carrying the same run ID. The form's success message and the agreed inbox notification pass in this example; the one-record assertion fails. The agency would investigate the connector/feed boundary. Actual customer impact is unknown.

- Incident: DEMO-001
- Workflow: Quote request, branch A
- Proposed path: WordPress / Gravity Forms → HubSpot plus approved test inbox
- Environment: fictional customer-owned sandbox
- Run ID: LWC-QA-DEMO-001
- Fictional submission time: 2026-10-16 09:00:00 UTC
- Fictional observation cutoff: 2026-10-16 09:05:00 UTC
- Example rule: exactly one new CRM record and one test notification within five minutes
- Classification: confirmed duplicate within this fictional test; cause unconfirmed

## Expected versus observed

1. **Form submission — pass in this example.** Expected one accepted submission. A single fictional browser request and form entry DEMO-FORM-001 appear at 09:00:02. The successful page alone would not establish downstream delivery.
2. **CRM delivery/count — fail in this example.** Expected one new object matching the unique run ID. Fictional records DEMO-CRM-101 and DEMO-CRM-102 both contain that ID, with creation times 09:00:08 and 09:00:11. Count: two. No test retry is represented.
3. **Required fields/routing — pass on both fictional records.** The synthetic name, requested service and intended pipeline/owner match the agreed values. This does not cancel the duplicate failure.
4. **Inbox — pass for the approved test path only.** One fictional message, DEMO-MSG-001, arrives in the controlled test inbox at 09:00:14 and matches the agreed subject/body fields. Production inbox routing is not covered if tests are redirected.
5. **Delivery timing — pass for these observed objects.** Both records and the message appear before the five-minute threshold. This says nothing about other runs or branches.

## Evidence that a real report would attach privately

- Redacted submission receipt with run ID, form-entry ID and timestamp.
- Read-only CRM query definition, account/object scope, cutoff and both matched record identifiers. Include only the agreed test fields, creation times and routing values.
- Test-message receipt with destination, received time and assertion results; redact any unrelated content.
- Runner log proving a single attempt and recording tool/configuration version.
- Access/suppression status and cleanup ledger.

No evidence files are attached to this demonstration. Do not invent screenshot links or treat the example identifiers as real provider records.

## Confidence and limits

In a real run, two directly observed CRM objects with the same unique ID would support high confidence in duplication for that test. It would not by itself prove which component retried or whether real leads were duplicated. The hypothetical single-submit log narrows the investigation but does not exclude every source of a second event.

The first suspected boundary is between the accepted form entry and CRM record creation. Possible causes include duplicate active feeds or a retry without effective deduplication. These are hypotheses; inspect permitted configuration/log evidence before attributing a root cause.

Marketing enrollment, SMS/calls, billing and unrelated webhooks are assumed suppressed for this example and are **not tested**. No claim is made about all forms, client devices, production traffic, revenue loss or continuous availability.

## Agency action and safe retest

- Agency repair owner: [named person from accepted scope]
- Suggested first action: inspect the authorized connector/feed configuration and logs for the two record IDs and the single form entry. Do not edit configuration from this report alone.
- Monitoring action: pause this workflow if duplicates could trigger consequential downstream activity or cleanup is unsafe; inform the approved contact during the agreed response process.
- Retest: after the agency reports a fix and confirms it is safe, run one authorized synthetic submission. Check count, required fields/routing, inbox timing and cleanup again.
- Closure evidence: exact repaired configuration/version, retest ID and timestamp, all agreed assertion results, and agency acknowledgment of any remaining gap. A passing retest supports that run only.

## Cleanup and next update

For a real incident, first retain the approved minimal evidence. The authorized cleanup owner then removes or archives only the exact synthetic form entry, two CRM records and test message according to the agreed policy. Record counts and object IDs before/after; check cascade effects. No bulk matching-name deletion or irreversible purge is implied.

- Cleanup status in this demonstration: not performed; there are no real records.
- Next update: [next agreed business-day review time]
- Repair status: awaiting agency investigation in this fictional scenario.
- Owner triage minutes and automated cost: [record actual values in a real incident; no invented savings]

LeadOtter is a provisional name. The proposed $250 USD / 30-day pilot and WordPress / Gravity Forms → HubSpot coverage are unvalidated. Agency-led repairs, no automatic renewal and no outcome guarantee. Commercial and contact terms require owner approval before sales.