Build a Failure-Aware CRM Follow-Up

Build a Make workflow that routes CRM lead exceptions and preserves failures.

Introduction

30 Second Summary

A potential customer can share their details in seconds. One missing detail can leave that lead with the wrong follow-up.

In this project, you will build a browser-triggered failure-aware lead follow-up workflow in Make. The workflow uses a Custom webhook to give every HubSpot CRM run a defined outcome.

What You'll Build

Open a test URL in your browser to watch a lead become a HubSpot contact with a follow-up task that matches the data it supplied.

By the end of this project, you'll have:

Submit a complete test lead to see a matching HubSpot contact. A call task due the next day proves the follow-up is ready.
Submit a lead with no phone number to see a manual-review task. The workflow keeps that lead away from an unsuitable call task.
Reuse an email address to update its existing contact without creating a duplicate. Inspect documented routes to distinguish expected business exceptions from preserved technical failures.
Secret Mission: Add a controlled failure-injection route. Prove the failed bundle reaches Make's Incomplete Executions queue.

Are there any prerequisites?

This project requires a Windows computer with internet access plus an email address for account registration. No coding or local installation is required.

Before We Start

Before any modules exist, this is your moment to define the workflow's outcome. You will also distinguish expected business exceptions from unresolved technical failures.

Set Up Make and HubSpot CRM

Your workflow policy now defines what should happen to every lead. The automation still needs browser workspaces that can receive the request and store its outcome.

Make provides the visual Scenario Builder where the workflow runs. HubSpot CRM stores the contacts and follow-up tasks created by that workflow.

This setup removes both access blockers before your first workflow run. An account-owner login can approve the connection between the services later.

In this step, get ready to:

Create a Free-plan Make account with access to the Scenario Builder.
Create a free HubSpot CRM account as the account owner.
Verify the browser-only environment across both services.

Create your Make workspace

The Scenario Builder is the canvas where your lead workflow will live. Opening a blank canvas proves that your account can reach the feature needed in the next step.

The Free plan includes 1000 credits per month. That allowance covers the test runs in this project.

Your sign-in details stay inside Make's registration flow. The project never asks you to paste them into a workflow.

Open Make's pricing page in a new browser tab.
Select the registration option for the Free plan.
Complete the account registration with an email address you control.
Select Scenarios from the left navigation.
Select the option to create a new scenario.
Leave the blank Scenario Builder open in this browser tab.

You'll see a blank Scenario Builder canvas where modules can be added. That's the first access blocker cleared: Make is ready for your lead intake workflow.

Can't reach the Scenario Builder?

Confirm that you completed the account registration before returning to Scenarios.
Complete any pending email verification request from Make.
Reload the Make browser tab after finishing the verification process.

Help me diagnose why I cannot open Make's Scenario Builder after registering. Ask the Make Community for account setup help.

Create your HubSpot CRM workspace

HubSpot describes its free CRM as 100% free with no expiration date. No credit card is required.

The account owner controls the later Make authorization. Your password remains inside HubSpot's registration flow.

Open HubSpot's free CRM page in a new browser tab.
Register with an email address you control so you remain the account owner.
Complete the required account onboarding.
Skip optional product setup that does not block access to the dashboard.

Your HubSpot CRM account is now ready to hold the contacts and tasks created by the workflow.

Click CRM in the top navigation.
Select Contacts.
Confirm that the contacts list loads.
Return to CRM in the top navigation.
Click More if the CRM menu does not show Tasks.
Select CRM inside More if you used the expanded menu.
Select Tasks from the available CRM menu.
Confirm that the task list loads.

You can now reach both CRM areas needed to verify later workflow runs. The account is ready for contact and task outcomes.

Can't open Contacts or Tasks?

Confirm that you completed the required HubSpot onboarding.
Check More if the top navigation does not show every CRM option.
Reload the HubSpot browser tab after completing any pending account verification.

Help me troubleshoot why my free HubSpot CRM account cannot open Contacts or Tasks. Ask the HubSpot Community for account setup help.

Verify the browser-only environment

Before you check, do you expect either service to require a local installation?

Switch back to the Make browser tab.
Confirm that the Scenario Builder remains open.
Switch back to the HubSpot browser tab.
Use the CRM menu to return to Contacts.
Confirm that the contacts list opens.
Return to Tasks through the CRM navigation you verified earlier.
Keep both signed-in browser tabs open for the next step.
Confirm that every setup action happened inside your browser.

You'll have Make signed in with the Scenario Builder open. HubSpot will open both CRM Contacts and Tasks from its browser dashboard.

No local Windows software, command shell, or code editor was required.

You've cleared both access blockers. Next, you'll turn the blank Make scenario into a browser-triggered lead intake endpoint.

Capture a Lead with a Custom Webhook

Your Make workspace is ready. The workflow still lacks a visible entry point for a lead.

A Custom webhook turns a browser request into an inspectable data bundle. That bundle captures the before-state before any HubSpot CRM side effect exists.

In this step, get ready to:

Build an intake endpoint inside Failure-Aware Lead Intake.
Send a complete browser request to the webhook.
Verify the captured before-state in the output bundle.

Create the intake endpoint

Every Custom webhook receives requests through a generated URL. This URL becomes the entry point for your browser-submitted leads.

Switch back to the Make browser tab from earlier.
Click Create a new scenario in the Scenarios area.
Click the current scenario name in the top left of Scenario Builder.
Enter Failure-Aware Lead Intake in the scenario name field.
Press Enter to apply the scenario name.
Click the + button on the canvas to add the first module.
Search for Webhooks in the app list.
Select Webhooks from the results.

What is a Custom webhook?

A Custom webhook gives external events a unique URL for entering a Make scenario. Each request becomes a bundle that later modules can inspect.

This makes the incoming data visible before the workflow changes HubSpot CRM.

Select Custom webhook.
Click Add beside the Webhook dropdown.
Enter lead-intake in the Webhook name field.
Click Save.

You'll see a generated URL. Make also starts listening for a sample request.

Good progress. Your intake endpoint now has an address that Make can monitor.

The URL is safe to use in your own browser for this test. Anyone with the URL can trigger your scenario.

Copy the generated webhook URL to your clipboard.
Keep the generated webhook URL out of screenshots and public pages.

Define the complete-lead contract

Make learns a webhook's mappable fields from its sample call. Your first sample therefore carries email, firstname, lastname, and phone.

Select Run once in Scenario Builder.

You'll see the scenario wait for a request. The webhook is now ready to capture its first lead.

Open another browser tab.
Paste the generated webhook URL from your clipboard into the address bar.
Append ?email=complete1@example.com&firstname=Casey&lastname=Complete&phone=5550101 to the URL.

Before you submit the request, what response do you expect from an endpoint that has accepted the lead?

Press Enter to send the request.

You'll see Accepted in the browser. That is your first live lead crossing into Make.

What Does This Request Establish?

A query string carries named values after the ? in a URL. The & characters separate its fields.

The names email, firstname, lastname, and phone form the workflow's input contract.

Browser Does Not Show Accepted?

Return to the Make browser tab.
Confirm Run once is listening before you resend the request.
Check that the appended query string starts with ?.
Resend the complete webhook URL after Make begins listening.

Help me troubleshoot why my Make webhook did not accept the browser request.

Verify the captured lead

The output bundle is evidence of the workflow's before-state. It proves that Make received the expected lead fields before any CRM action runs.

Return to the Make browser tab from earlier.
Open the lead-intake webhook module's output bundle.

Before you compare the bundle, which four fields do you expect Make to have learned from the browser request?

Compare the output bundle with the complete browser request.

You should see email with complete1@example.com. You should also see firstname with Casey.

You should see lastname with Complete. You should also see phone with 5550101.

Click Save only after all four captured values match the request.

Before your final check, do you expect the captured fields to remain available after the scenario is saved?

Confirm the scenario title at the top of the canvas is Failure-Aware Lead Intake.
Open the lead-intake module's output bundle again.

You'll see the lead-intake module on the saved Failure-Aware Lead Intake canvas. The bundle still shows email as complete1@example.com.

You'll see firstname as Casey. You'll see lastname as Complete.

You'll see phone as 5550101. Your saved scenario now has a tested input contract.

Missing a Field in the Bundle?

Return to the browser tab containing the complete webhook request.
Check that the URL includes the full ?email=complete1@example.com&firstname=Casey&lastname=Complete&phone=5550101 query string.
Select Run once before submitting the request again.
Send the complete request again.
Reopen the webhook output bundle to check all four fields.

Help me troubleshoot a missing field in my Make webhook output bundle.

Your saved webhook now turns a browser request into a visible lead bundle. Next, you'll use that tested contract to create or update the contact in HubSpot CRM.

Build the HubSpot Happy Path

Your webhook already captures a complete lead in Make. The next proof is whether that lead can become useful work in HubSpot CRM.

This step builds the smallest useful workflow from browser request to CRM outcome. It proves the promised before-state and after-state before you handle incomplete data or connector failures.

In this step, get ready to:

Authorize Make to access your HubSpot CRM account.
Map each webhook value into a contact upsert.
Create a call task for a complete lead.

Connect HubSpot and map the contact

A CRM upsert uses a stable identity to decide whether to create a record or update one. The Create or Update a Contact module uses email for that decision.

Return to the Failure-Aware Lead Intake scenario in the Scenario Builder from earlier.
Select the connection point immediately after the lead-intake webhook.
Search for HubSpot CRM in the module picker.
Select Create or Update a Contact.

You should see the contact module's configuration panel attached to the webhook.

What does the connection allow?

This permission step can feel weighty because it connects two accounts. The authorization screen grants the Make app access to the HubSpot account you choose.

The connection lets this scenario create or update contacts. Check the displayed HubSpot account before you approve access.

Select Create a connection in the module's connection field.
Click Save to begin authorization.
Complete the HubSpot authorization screen for the Make app.
Confirm that the authorized connection appears in the module's connection field.

The HubSpot connection is now ready for field mapping.

Map the webhook's email value to the corresponding HubSpot contact property.
Map the webhook's firstname value to the corresponding HubSpot contact property.

You should see mapped webhook tokens in the first two contact properties.

Map the webhook's lastname value to the corresponding HubSpot contact property.
Map the webhook's phone value to the corresponding HubSpot contact property.

All four contact properties should now contain values from the webhook output.

Click Save to keep the contact configuration.

Good progress. The contact module now uses email as the stable identity while carrying the lead's name and phone into HubSpot.

Why use email as the identity?

The contact action creates a record when the submitted email does not exist. It updates the matching contact when the email already exists.

This gives a replayed lead one continuing CRM record instead of a duplicate.

Connection not appearing?

Confirm that the authorization screen shows the HubSpot account owner you used during setup.
Repeat the connection flow if HubSpot returned you to Make without adding the connection.
Check that the Make app has been approved for the selected HubSpot account.

Help me troubleshoot my Make connection to HubSpot CRM.

Create the follow-up task

A saved contact proves the lead reached the CRM. A downstream task turns that record into a clear follow-up action.

Select the connection point immediately after the contact module.
Choose HubSpot CRM in the module picker.
Select Create a Task.

You should see a second HubSpot module attached after the contact action.

Insert the mapped firstname value at the start of the task title.
Insert the mapped lastname value after the first name.

The task title should now display two mapped name tokens.

Insert the mapped email value after the lead name.
Separate the mapped title values with spaces.

The title now carries enough information to identify the lead from the task list.

Set the task type to Call.
Choose the not-started option in the status field.

The task configuration should now describe an outstanding call.

Set the task due date by entering this formula:

addDays(now; 1)

What does this formula do?

The formula starts with the scenario's current run time.
It adds one day to produce the task deadline.
The mapped email keeps the task traceable from the HubSpot task list.

Click Save to keep the task configuration.

The scenario canvas should now show the webhook followed by two HubSpot modules.

Task fields not accepting your values?

Confirm that the task title contains mapped tokens from the webhook output.
Check that the due date field contains the complete formula shown above.
Reopen the contact module if the task mapper does not show the lead fields.

Help me troubleshoot my HubSpot task mapping in Make.

Run a complete lead end to end

The full scenario now has one input and two CRM side effects. This run checks whether all three modules carry the same complete lead.

Before you run the scenario, do you expect one or both HubSpot modules to receive the complete lead?

Select Run once in the Scenario Builder.
Return to the browser tab from your earlier webhook request.
Change the number in complete1@example.com to a number you have not used before.
Press Enter to send the updated browser request.

The browser should display Accepted. Make should show one completed execution across the webhook and both HubSpot modules.

Select each module's execution result on the Make canvas.

You should see the same complete-lead values carried from the webhook into the contact action and the task action.

Execution stopped at a HubSpot module?

Confirm that the HubSpot connection remains selected in the module that stopped.
Check that all four contact properties contain mapped values from the webhook.
Check that the task due date field contains a valid formula.

Help me diagnose where my complete lead stopped in Make.

Switch back to the HubSpot tab from earlier.
Select More in the HubSpot navigation.
Select CRM.
Select Contacts.
Use the contacts search to find the unique email from your latest request.

You should see one matching contact with the submitted first name, last name, email, and phone.

Select More in the HubSpot navigation.
Select CRM.
Select Tasks.
Find the task whose title contains your unique lead email.

You should see exactly one matching Call task with a not-started status. Its due date should be one day after the scenario run.

That is the happy path working from end to end. A browser-submitted lead now becomes one HubSpot contact and one visible follow-up task.

Your complete-lead workflow now produces a visible CRM outcome. Next, you will test whether technical success always produces the right business result.

Expose the Business Exception

Your complete lead has already moved through Make into HubSpot CRM. The matching contact plus follow-up task prove the basic workflow works.

A technically successful run can still violate the business goal when required lead data is absent. This step tests that gap before the workflow receives any protection.

In this step, get ready to:

Test the naive workflow with valid lead data that omits the phone value.
Compare the technical result with the business outcome.
Document the missing-phone exception plus its recovery owner.

Submit incomplete but valid data

A webhook request can remain valid when a business field is empty. This test preserves the lead's identity while omitting the phone value.

Switch back to the Failure-Aware Lead Intake scenario in Make.
Select Run once in the Scenario Builder toolbar.
Open a new browser tab.
Enter the generated lead-intake webhook URL followed by ?email=incomplete1@example.com&firstname=Riley&lastname=Review in the address bar.

Before you send the request, predict whether the missing phone value will stop the scenario or allow every module to succeed.

Press Enter to send the missing-phone lead.

Your browser displays Accepted. The request has entered the scenario as valid webhook data.

Browser Does Not Show Accepted?

Confirm that Run once is listening for a webhook request.
Check that the query string starts with ?email= immediately after the generated webhook URL.
Confirm that the generated webhook URL has not been shortened or edited.

Help me troubleshoot why my Make webhook request does not return Accepted.

Inspect the technical result

Return to the Scenario Builder after the execution finishes.
Inspect the output bubble on the lead-intake webhook module.
Inspect the output bubble on the Create or Update a Contact module.
Inspect the output bubble on the Create a Task module.

The webhook shows a successful bundle. The contact module reports success.

The task module also reports success. Make sees no technical failure in this run.

Before you check HubSpot, predict which follow-up task the current workflow created for Riley.

Switch back to the HubSpot browser tab.
Click More in the top navigation.
Select CRM.
Select Contacts.
Open the contact whose email is incomplete1@example.com.

HubSpot shows the Riley Review contact. Its phone property is empty.

Click More in the top navigation.
Select CRM.
Select Tasks.
Find Call Riley Review in the task list.

HubSpot shows Call Riley Review in the task list. The workflow created a call task for a lead it cannot call.

You found the exact gap this test was designed to expose. Every module ran successfully while the workflow produced the wrong business outcome.

Cannot Find Riley's Records?

Refresh the HubSpot Contacts page before searching for incomplete1@example.com again.
Refresh the HubSpot Tasks page before looking for Call Riley Review again.
Compare the mapped email in Make with the email shown in the webhook output bundle.

Help me trace why Riley's HubSpot contact or task is missing.

Document the exception decision

A scenario note preserves the reasoning behind this failed business test. It gives the next workflow owner enough context to understand the recovery decision.

What Should the Note Capture?

The Before-state entry records a valid Riley Review lead with no phone value.
The Technical result entry records that every module reported success.
The Business result entry records the inappropriate Call Riley Review task.
The Expected exception entry identifies missing phone data as an expected input condition.
The Desired recovery entry defines a manual-review task for the lead.
The Recovery owner entry assigns the workflow owner to review the lead.
The Completion evidence entry defines a review task containing the lead email as proof of recovery.

Switch back to the Make Scenario Builder.
Right-click the downstream Create a Task module.
Select Add a note.
Enter the seven entries from the checklist above.
State that a missing phone is an expected business exception requiring manual review.
State that technical Retry handling applies to unexpected connector or validation failures.
Click OK.
Save the scenario.

Before you inspect the saved note, consider whether it explains the original input plus the person responsible for recovery.

Inspect the note attached to the Create a Task module.

You should see all seven decision fields plus the manual-review policy. The note now separates this expected business exception from an unexpected technical failure.

Your test has proved that module success alone cannot guarantee a useful business outcome. Next, you will create separate routes for complete leads plus missing-phone leads while preserving unexpected failures for investigation.

Route Exceptions and Preserve Failed Work

Your missing-phone test exposed a workflow that completed technically while producing the wrong business outcome.

A Router in Make gives each expected lead state its own route. Retry handlers preserve unresolved HubSpot CRM writes for review.

In this step, get ready to:

Split complete leads from missing-phone leads.
Document the operational policy for each route.
Preserve unresolved HubSpot writes for intentional review.

Split leads by phone availability

The Router evaluates the lead after the contact has been created or updated. A filter sends complete leads toward the existing call task.

Switch back to the Make tab containing your Failure-Aware Lead Intake scenario.
Right-click the connection line after Create or Update a Contact.
Select Add a router.

You should see the Router between the contact module and the existing task module.

Place the existing Create a Task module on the Router's first route.
Click the connection line leading to the existing task module.
Enter Complete lead as the route label.
Map the webhook's phone value into the filter condition.
Set the condition to pass only when the mapped value has content.
Click Save.

The first route now has a visible Complete lead filter before the existing call-task module.

A fallback route catches any lead that does not pass an earlier route. In this workflow, that means a contact whose webhook bundle has no phone value.

Add a second route using the Router's route control.
Click the second route's connection line.
Select Yes for the fallback option.
Click Save.

You should see the second path marked as the fallback route.

Add a HubSpot CRM Create a Task module to the empty end of the fallback route.
Select the HubSpot connection you authorized earlier.
Configure the task title as Review missing phone followed by the mapped lead name plus email.
Save the task module.

You should now see one filtered route ending in the existing call task. The fallback route should end in the new manual-review task.

Why use a fallback route?

The fallback route defines a valid business outcome for incomplete data. It keeps a missing phone number out of the technical failure queue.

Leads taking the wrong route?

Check that the Complete lead filter evaluates the webhook's phone value.
Confirm the second route is marked as the fallback route.
Confirm the existing call-task module remains on the filtered route.

Ask for help with fixing a Make Router that sends leads down the wrong route.

Document and preserve recovery decisions

Route notes explain why each branch exists before someone has to investigate an incident. Incomplete Executions retain unresolved technical failures instead of discarding the affected bundle.

What belongs in each route note?

Use Before to record the data state entering the route.
Use Success to name the task that proves the route completed.
Use Expected exception to explain how missing phone data is handled.
Use Unexpected failure to identify a failed HubSpot write.
Use Recovery to record the review decision.
Use Owner to identify the workflow owner.
Use Evidence to record the output that proves completion.

Right-click the Complete lead route.
Select Add a note.
Record the seven note fields shown above for the complete-lead outcome.
Click OK.

The complete-lead route now carries its business outcome plus its recovery policy on the canvas.

Right-click the fallback route.
Select Add a note.
Record the seven note fields shown above for the missing-phone outcome.
Click OK.

The fallback route now identifies missing phone data as an expected exception owned by manual review.

Right-click the Create or Update a Contact module.
Select Add an error handler.
Choose Retry.
Set automatic completion to No.
Confirm the error handler.

You should see a dotted Retry route attached to the contact module.

Apply the same Retry configuration to the Complete lead task module.
Apply the same Retry configuration to the missing-phone task module.

All three HubSpot write modules should now show dotted Retry routes. Each handler should have automatic completion set to No.

Click the gear icon in the Scenario Builder.
Enable Store incomplete executions.
Save the scenario settings.
Save the Failure-Aware Lead Intake scenario.

Make can now retain unresolved HubSpot write failures for an intentional review.

Why normal routes and Retry handlers?

A missing phone number is expected input with a defined manual-review outcome. The Router handles that outcome during the normal scenario run.

Retry stores a failing bundle's error details plus its remaining steps as an incomplete execution. Automatic completion set to No keeps the recovery decision with the workflow owner.

Retry handler not available?

Enable Store incomplete executions in Scenario settings if Retry cannot be selected.
Return to the affected HubSpot module after saving the setting.
Confirm automatic completion shows No on every Retry handler.

Ask for help with configuring Retry handlers and incomplete executions in Make.

Re-run the outcome matrix

The final check sends one lead through each normal route. The resulting HubSpot tasks become the evidence recorded in your route notes.

Choose a unique email for the complete-lead run: your unique complete-lead email.
Select Run once in Make.

Before you send the complete lead, which Router path do you expect to process its task?

Open a new browser tab.
Paste the complete-lead webhook URL from earlier into the address bar.
Replace its email value with your unique complete-lead email.
Press Enter to send the request.

Your browser should display Accepted. Make should show the bundle passing only through the Complete lead route.

Inspect the complete-lead execution path in Make.
Return to the HubSpot Contacts view from earlier.
Find the contact matching your unique complete-lead email.
Return to the HubSpot Tasks view from earlier.
Find the Call task containing your unique complete-lead email.
Switch back to the Make Scenario Builder.
Update the Evidence entry in the Complete lead route note with the observed outputs.
Save the scenario.

The complete lead now has a matching contact plus a Call task due one day after the run.

Choose a unique email for the missing-phone run: your unique missing-phone email.
Select Run once in Make.

Before you send the missing-phone lead, which route do you expect to create its follow-up task?

Open a new browser tab.
Paste the missing-phone webhook URL from the previous test into the address bar.
Replace its email value with your unique missing-phone email.
Press Enter to send the request.

Your browser should display Accepted. Make should show the bundle passing only through the fallback route.

Inspect the fallback execution path in Make.
Return to the HubSpot Contacts view from earlier.
Find the contact matching your unique missing-phone email.
Return to the HubSpot Tasks view from earlier.
Find the Review missing phone task containing your unique missing-phone email.
Switch back to the Make Scenario Builder.
Update the Evidence entry in the fallback route note with the observed outputs.
Save the scenario.

That is the operational split working. Complete leads receive call tasks while missing-phone leads receive manual-review tasks.

Your canvas should also show dotted Retry routes on the contact module plus both task modules. This proves unexpected HubSpot write failures have a separate recovery policy.

Secret mission

Inject a Controlled Technical Failure

Your recovery path is still unproven until it handles a real failure. You will inject invalid JSON before the HubSpot contact write. Make will preserve the failed bundle for review before you disable the test branch.

Clean Up Your Resources

Choose whether to keep the automation available, pause it for later, or remove its project data. The project costs $0 on the verified free plans within Make's 1000 credits per month allowance.

Resources you used:

The Make scenario Failure-Aware Lead Intake with its routers, notes, Retry error handlers, and settings.
The Custom webhook named lead-intake with its private generated URL.
The stored Incomplete Execution for fail1@example.com.
The HubSpot CRM contacts created during the complete-lead, missing-phone, and naive-flow tests.
The HubSpot CRM tasks created during the complete-lead, missing-phone, and naive-flow tests.

Protect Your Webhook URL

The generated Make webhook URL can trigger scenario runs. Anyone with it can consume your monthly credits, so keep it private in every cleanup choice.

Keep everything running

Choose this option while you still want to demonstrate the workflow. The free plans keep the project available without an ongoing charge.

Keep Failure-Aware Lead Intake active in Make.
Keep the generated lead-intake webhook URL private.
Retain the HubSpot CRM contacts and tasks as demonstration evidence.
Retain the stored execution for fail1@example.com as incident evidence.
Monitor your Make usage against the 1000 credits per month Free plan allowance.
Keep the authorized HubSpot connection available for future scenario runs.

Pause - I'll come back to this later

Pause the scenario when you want to preserve the workflow without processing new leads. Your canvas and CRM evidence stay available for later.

Switch back to the Make browser tab from earlier.
Return to the Scenarios area.
Locate Failure-Aware Lead Intake.
Use the scenario's on/off control to turn it off.
Leave the HubSpot CRM test contacts and tasks unchanged.
Keep the generated lead-intake webhook URL private.

The scenario now shows an off state. Its modules, notes, error handlers, and stored incident evidence remain available.

Delete - I don't want to use this again

Deleting these resources permanently removes the project workflow and its test data. This choice cannot be undone.

Delete the stored failure evidence:

Switch back to the Make browser tab from earlier.
Return to Failure-Aware Lead Intake in the Scenario Builder.
Select Incomplete Executions.
Select the stored execution for fail1@example.com.
Choose Delete.
Confirm the deletion.

The controlled-failure record should no longer appear in Incomplete Executions.

Delete the webhook:

Return to the scenario canvas.
Select the Webhooks > Custom webhook module.
Select lead-intake from the Webhook dropdown.
Use the delete control beside the selected webhook.
Confirm the webhook deletion.

The generated webhook URL can no longer serve as the project's intake endpoint.

Delete the scenario:

Return to the Scenarios area.
Open the action menu for Failure-Aware Lead Intake.
Select Delete.
Confirm the scenario deletion.

The project scenario should no longer appear in your Make scenario list.

Delete the HubSpot test tasks:

Switch back to the HubSpot browser tab from earlier.
Select More in the navigation.
Select CRM.
Select Tasks.
Select every task whose title contains one of your project test emails.
Select the historical Call Riley Review task.
Use the task list's Delete control.
Confirm the task deletion.

The complete-lead, missing-phone, and naive-flow tasks should no longer appear in the task list.

Delete the HubSpot test contacts:

Select More in the navigation.
Select CRM.
Select Contacts.
Search for each complete-lead or missing-phone email used during the project.
Add the contact for incomplete1@example.com to your selection.
Select every matching project contact.
Use the contact list's Delete control.
Confirm the contact deletion.

You should no longer see contacts for the project test addresses. No deletion is needed for fail1@example.com because the controlled failure never created that contact.

What Stays Behind?

Your free Make and HubSpot accounts remain open. The authorized HubSpot connection also remains available in Make.

Nice Work!

You did it! Your Make scenario now turns browser-submitted leads into HubSpot CRM contacts with the right follow-up task. It also preserves unresolved technical failures for intentional review.

What you learned:

Built a browser-triggered lead intake with a Custom webhook. Mapped each lead into HubSpot CRM through a contact upsert keyed by email. Replaying an address updates its matching contact without creating a duplicate.
Used a Router to give each lead the correct business outcome. Complete leads receive a Call task due the next day. Missing-phone leads receive a manual-review task.
Protected every HubSpot write with Retry handlers. Stored unresolved failures in Incomplete Executions for workflow-owner review. Documented each route with its recovery policy plus completion evidence.
Secret Mission: Injected a controlled technical failure through invalid JSON. Confirmed the failed bundle reached Incomplete Executions. Verified that no HubSpot contact was created for fail1@example.com.

Ready to quiz yourself?