Turn a website enquiry into a useful CRM record.

Start with the handoff, not the connector.

A useful CRM record should tell someone what the enquiry is about and what they need to do next. Before opening an automation builder, write down the person who will own new requests and the action that should follow.

For this example, a new service enquiry needs a source, a short description, an assigned owner, and a follow-up task. Decide whether it belongs in your lead inbox or is qualified enough to become a deal. Your answer should follow your sales process.

A small set of acceptance rules

• A complete request reaches the intended destination with its source intact.
• An incomplete request has a visible route to review.
• A repeated delivery of the same submission does not create an unintended second request.
• A new enquiry from an existing person is handled according to an explicit business rule.
• A failure is visible to someone who can resolve it.

Choose the shortest suitable route.

If you already use Pipedrive and can replace your form, evaluate its native Web Forms first. Pipedrive documents embeddable forms that create leads or deals; the feature belongs to the LeadBooster add-on and requires deals-admin permission. Check availability and required fields for your account. Some plans already include LeadBooster; verify your plan before adding a separate charge. Pipedrive Web Forms documentation (updated 3 September 2026; checked 4 October 2026).

If your existing form needs to stay, or the enquiry must pass through other applications, evaluate Make as a separate integration layer. Its Pipedrive catalogue includes record actions. Make also documents HTTPS webhook triggers (checked 4 October 2026). Whether your form can trigger the workflow depends on the form provider and the connection you choose. Make’s Pipedrive app documentation (checked 4 October 2026).

At low volume, a clear manual process may be enough. A tool is useful when it solves a recurring handoff problem you can describe.

Map information before mapping modules.

Agree on the meaning and destination of each field. Keep the original submission identifier where your form provides one. Avoid using a person’s identity as a substitute for an enquiry identifier: the same person may contact you about two different projects.

This field map is an example to adapt. There is no account-specific mapping file to download.

Build one controlled test route.

This proposed route creates one deal and one follow-up activity for each new enquiry. Use one test scenario and one test pipeline. Other writers and live customer traffic are outside this test boundary.

1. Use the current connection. Choose Pipedrive CRM v2 modules in Make and create a Pipedrive OAuth connection. Sign in and confirm the requested access. Make’s API v1 module transition ended on 31 July 2026; do not start a new route with deprecated modules or API-token connections. This does not mean every Pipedrive API v1 endpoint is retired: Make documents exceptions for Leads and Projects. Check your actual modules in the current Pipedrive app documentation and migration guidance.
2. Prepare the destination. Record the test owner, pipeline, stage and activity type. Create a text deal field for the submission key and another for the selected service. Get their actual field codes from the account. Map the key in the original deal-creation request, so it can survive a lost response.
3. Receive and validate. Preserve the form’s stable submission key. For the synthetic kit, map each symbolic contact key to your owned test contact. A missing key or contact identity goes to review before any CRM write.
4. Read the event record. Keep the submission key, relevant payload fields, state and confirmed destination IDs in persistent storage. A Make data store is one option. For this small example, compare the contact key and service exactly; document any normalization before extending it to a real form. A changed payload under an existing submission key needs review. Do not overwrite its earlier result.
5. Reconcile the deal. Search the submission key before creating a new deal. Pipedrive supports exact searches across searchable custom fields. Inspect the configured submission field on each candidate as well. Zero confirmed matches can proceed; one can be reconciled; more than one needs review. Search is case-insensitive and is not a uniqueness constraint. Pipedrive deal API.
6. Resolve the person. For an email-based contact rule, use exact email search and inspect every candidate. Reuse one unambiguous match, create only after no match, and retain multiple matches for review. An email match is a business rule, not identity verification. Pipedrive person API.
7. Write and checkpoint. Use current v2 person, deal and activity modules available in your account. Map the actual v2 output: related record IDs, the custom_fields object and owner_id need explicit handling; person email and phone values are arrays. Save each confirmed ID before advancing. Include the owner, destination and custom-field values in the intended write. Keep automatic recovery from repeating an uncertain create operation.
8. Verify the next action. List activities for the known deal and match the intended follow-up using a stable marker such as the submission key in its subject. An unrelated or completed activity is not sufficient. Check pagination, assignment and due date before deciding whether the action exists. Verify all required outputs before recording completion. Pipedrive activity API.

The Make Pipedrive module catalogue documents actions such as searching deals and persons, creating records, and listing activities. Confirm the actual module fields and connection permissions in your test account. This page does not provide unverified module identifiers or an importable blueprint.

Treat a repeated event and a repeat customer differently.

Write two rules. One determines whether the contact already exists. The other determines whether this particular enquiry has already been processed. A repeat customer can still have a new enquiry.

A simple search-then-create sequence can still race when two runs overlap. Make documents parallel processing for instant webhooks and the Process data in order setting. That setting alone is not a guarantee against every duplicate. Verify the behaviour of your actual route. Make webhook processing.

Use the nine duplicate and recovery cases for explicit baselines, expected outcomes and a blank result log.

Give failures somewhere to go.

Decide who sees a failed run and how it gets resolved. Make documents incomplete executions and a Retry error handler. Check the relevant settings: incomplete executions are disabled by default and must be enabled in Scenario settings; automatic retry behaviour depends on the error and configuration. Incomplete executions (checked 4 October 2026) · Retry handler.

Consider a run where the contact was saved but creating the enquiry failed. Restarting the entire process without checking prior work can create another record. Your recovery procedure should inspect what exists, then safely resume or resolve the remaining action.

Make can automatically retry certain connection, rate-limit and timeout failures, beginning at the failed module. A create request whose response was lost therefore needs reconciliation before another attempt. For the initial controlled test, set the Retry handler’s automatic completion to No and confirm the fault remains held for review. Do not use a manual retry button to repeat an uncertain write blindly. Make’s automatic retry behaviour.

Verify the complete journey before launch.

Use synthetic records and owned test addresses. Record the actual output for each case. Do not mark a workflow complete because one module turned green.

1. Submit a complete enquiry and verify every mapped field at the destination.
2. Repeat the submission and check the expected record count.
3. Submit a new request from the same contact and check the intended outcome.
4. Omit a required field and confirm the review path.
5. Interrupt the destination step, recover it, and inspect the final records.
6. Confirm that the assigned owner can see and act on the next task.

Keep the form and CRM permissions, plan limits, and recovery instructions with your test record. Repeat affected checks when a connection or field mapping changes.

Measure the cost of each route.

Record the credits for a new contact, an existing contact, a rejected input and an extra retry. Use the credit estimator after those observations are available. Its example figures illustrate arithmetic; they do not describe this untested integration.

Ready to choose the tools?

Compare the route that fits your existing form and team. Check the provider’s current requirements before signing up.

These are ordinary links to official vendor pages. We do not earn a commission from them. How recommendations work.

Sources and evidence

• Pipedrive: Web Forms
• Make: Pipedrive connection and modules
• Make: webhooks and processing
• Make: incomplete executions
• Make: Retry error handler

Checked 3 October 2026. Product configuration and plan access can change. The proposed process and acceptance checks are editorial guidance.