This recipe creates an internal lead-review queue for a low-volume website form. A trusted service sends each submission to a protected Make webhook, then a filter and data-store key control what is stored. A repeated ID produces an error for an operator to review; this tutorial does not configure automatic duplicate recovery. Someone must reconcile the source submissions with the queue and run history. No customer message is sent. Module behavior comes from Make documentation; the sample payload and checks are editorial examples, not a claim of live account testing.
An internal queue stores valid submissions once per source ID. A named operator reviews duplicate errors and reconciles failed or filtered events; the recipe does not provide unattended recovery.
Before you start
- A Make account with enough scenario, credit, and data-store capacity for the workload.
- A form service or server that can send a webhook with a secret header; keep that secret out of public browser code.
- A stable submission ID generated by the source system, plus only the lead fields you need.
- A controlled test payload and an owner who can inspect failed runs after testing and at an agreed interval during use. If nobody can review the queue and resolve exceptions, do not use this manually supervised recipe for live intake.
Expected queue record
Illustrative sample: adapt the business details before using it.
Start with this input
Send the controlled JSON payload through the authenticated source connection, then send the same event ID again.
What a useful result looks like
The Lead review store has key demo-1001 with email demo@example.com, requested_service portrait session, source website inquiry form, and review_status New. The second identical event produces an existing-key error. An operator compares it with the original source submission and records Reviewed duplicate in the review log. One record remains; the scenario has not automatically resolved the error.
Inside the software
- Data stores → add a store and define the queue fields.
- Scenario Builder → Webhooks → Custom webhook; add authentication and an explicit data structure.
- Add Data store → Add/Replace a Record, select Lead review, and map event_id to Key.
- Disable overwriting existing records and click the module connection to add required-field filters.
Interface labels and feature availability can vary by account and plan. Official setup guide ↗ Official setup guide ↗ Official setup guide ↗ Official setup guide ↗
Create the internal lead-review data store
Open Data stores and add a store named Lead review. Define fields for email, requested_service, source, and review_status. Keep identifiers and email addresses as text. The data-store key will hold the form's stable submission ID; it should not be a changing timestamp or a row position. Decide who can inspect these records and when they are deleted. This is an internal queue, so include only information needed to respond.
Add a custom webhook with authentication
Create a scenario and add Webhooks → Custom webhook. Name the webhook Lead intake. Configure its API-key option and supply the key only through your form provider or server using the documented x-make-apikey header. Keep the key and webhook URL out of public screenshots and templates. Create an explicit input data structure for the expected fields; simply detecting fields from a sample does not provide the same validation.
Send a sample and inspect the actual fields
Use the sample JSON below through your form provider's test function or a controlled API client. The example.com address is placeholder data, not a recipient to contact. Inspect the incoming bundle and confirm the submission ID and email arrive as text. Do not add query-string copies of the same fields, since overlapping input formats can change which value wins. Resolve missing or renamed fields before adding the storage action.
Filter and map the storage action
Add Data store → Add/Replace a Record and select Lead review. Map event_id to Key, map the allowed fields, and set review_status to New inside the workflow. Keep replacement of existing keys disabled. Add a filter on the connection to require the ID and email to be present. Presence does not establish a deliverable address or marketing permission; the form provider must validate input and record any relevant permission separately.
Test duplicates and follow the manual review procedure
Send the valid payload twice, then test a missing email and missing ID. A repeated key with replacement disabled produces an error, preserving the original record. For each duplicate, inspect the failed run, locate the stored record by event_id, and compare the payload with the source submission. If the same submission was retried unchanged, record the run ID as Reviewed duplicate in an operator log; do not create another record or replay it blindly. If the same ID carries different details, hold it for source-system correction. Record other failures separately and keep the original payload for authorized recovery. This review is manual; the workflow has no duplicate-resolution branch.
Activate only with an owner and a reconciliation routine
Confirm the webhook schedule and enable the scenario for the source service only after the controlled tests pass. Compare each source event with the stored key or an explained exception. Review the webhook queue and scenario history on the agreed schedule, and check that scheduling remains enabled after errors. An acceptance response can mean the request was queued, not stored. When credits, access, or a storage action fails, correct the cause and deliberately recover the affected source event after checking whether its key already exists. The owner must resolve these exceptions; unattended recovery and external customer actions require a separately designed and tested workflow.
The example setup, field by field
These settings belong to the example in this guide. Adapt them to your own workflow.
| Field | Example setting | Why it matters |
|---|---|---|
| Webhook module | Webhooks → Custom webhook | Receives a server-side form submission. |
| Authentication header | x-make-apikey: [your secret value] | Used by the trusted sender; never paste a real key into public code or examples. |
| Input fields | event_id, email, requested_service, source | A small, explicit structure is easier to validate and maintain. |
| Data store | Lead review | Provides a visible internal processing queue. |
| Record key | Map the source event_id | Keeps the same submission recognizable on retry. |
| Overwrite existing record | Disabled | Preserves an existing key and exposes duplicate attempts. |
| review_status | New, set inside the workflow | Prevents untrusted input from declaring a lead already approved. |
Controlled test payload
{
"event_id": "demo-1001",
"email": "demo@example.com",
"requested_service": "portrait session",
"source": "website inquiry form"
}Acceptance test cases
1. New valid event_id: exactly one new queue record. 2. Repeat demo-1001 unchanged: existing-key error; original preserved; operator logs Reviewed duplicate. 3. Repeat demo-1001 with changed details: original preserved; operator holds an ID-conflict exception. 4. Missing email or event_id: no valid lead record; inspect history and source validation. 5. Invalid authentication: request rejected. 6. Storage or credit failure: visible exception, source event identified, owner assigned. 7. Verify the scenario remains enabled after the tests. 8. No external customer messages are part of this recipe.
Manual exception-review log
Review date and owner: Source event_id: Source submission reference: Make run reference: Stored record found? yes / no Comparison: identical retry / conflicting details / storage failure / invalid input Decision: Reviewed duplicate / hold for correction / recover after fixing cause Reason and supporting check: Next action and owner: Scenario status checked after review:
Module controls and queue behavior are drawn from Make's official documentation. The composed recipe is an editorial design; use the sample acceptance tests before processing real submissions.
Troubleshooting
The webhook returned Accepted but there is no lead record.
Inspect the webhook queue and scenario history. Acceptance can confirm queuing rather than successful storage; check the filter and data-store step.
A duplicate creates another record.
Confirm that Key is mapped to the stable source event_id. Leaving it empty generates a new key and defeats this recipe's duplicate protection.
Sample fields appear, but malformed requests still pass.
Define an explicit webhook data structure. Make distinguishes sample-based field detection from schema validation; then test the required-field rules.
A real submission fails with an existing-key error.
Open the failed run and compare its event_id and fields with the stored record and source submission. Log an identical retry as Reviewed duplicate. Hold changed data under the same ID for correction. Do not turn on overwrite or repeatedly replay the same event to hide the error; also check the scenario remains enabled.
Common mistakes to avoid
- Leaving the record key blank, which generates a new key for each retry.
- Exposing a webhook authentication key in a public webpage.
- Treating a queued request as proof that downstream storage completed.
- Treating a visible duplicate error as automatic recovery, or leaving a manually supervised intake queue without an owner.
How to know it helped
- A valid source event produces one recognizable review record.
- Repeated submissions preserve the first record and have a documented manual review outcome.
- Each source event reconciles to a stored record, a reviewed retry, or an open exception assigned to the operator.
Sources & research notes
Researched from official product documentation. This is an instructional guide, not a hands-on product test. Use the linked sources to check plan-dependent features and current limits.