DEV Community: kingston-888

Make.com Tutorial: Build a Reliable Lead Enrichment Workflow with Error Handling

kingston-888 — Fri, 14 Aug 2026 06:39:26 +0000

A lead enrichment workflow looks simple on a whiteboard: capture a form submission, look up company data, score the lead, update the CRM, and notify sales. In production, however, one missing domain, a slow API, or a duplicate webhook can turn that clean diagram into unreliable data.

This Make.com tutorial shows how to design a practical lead enrichment scenario that stays readable, handles partial failures, and avoids sending the same lead to sales twice. The goal is not to build the largest possible scenario. It is to build a workflow your team can understand and maintain.

1. Design the scenario around one clear data contract

Start with a webhook or form module that receives a predictable payload. At minimum, collect:

email address
full name
company name
company website or domain
source campaign
submission timestamp

Before calling any enrichment service, normalize the input. Convert email addresses to lowercase, trim spaces, and extract the root domain from the website URL. This gives every later module a consistent data shape.

A useful Make scenario can follow this structure:

Custom webhook receives the lead.
Tools / Set variables normalizes fields.
CRM search checks whether the email already exists.
Router separates new leads from existing contacts.
HTTP request calls the enrichment API.
Scoring step calculates lead priority.
CRM create or update stores the final record.
Slack or email notification alerts sales only when needed.

The duplicate check should happen before enrichment. Otherwise, retries and repeated submissions may waste API credits and create conflicting CRM records. Use the normalized email as the primary key and the company domain as a secondary check.

If you build many workflows across different tools, keeping a small reference catalog of triggers, payloads, and reusable integration patterns is helpful. A related workflow resource I have been reviewing is CoreClaw, mainly as a way to compare automation use cases without turning the scenario itself into a tool-specific design.

2. Add error handling before adding more modules

Make.com makes it easy to add modules, but reliability comes from deciding what should happen when each module fails.

For the enrichment request, distinguish between three outcomes:

Successful response: parse and use the returned data.
Expected missing data: continue with the original form fields and mark enrichment as incomplete.
Temporary failure: retry later instead of dropping the lead.

Attach an error handler to the HTTP module. For rate limits and server errors, store the lead in a retry queue such as Airtable, a data store, or a dedicated CRM status. Include the original payload, error code, retry count, and next retry time.

Do not retry every error. A 429 response or a temporary 5xx failure may succeed later. A malformed domain or a 400 response usually requires corrected input, not another automated attempt.

It is also useful to preserve processing state in the CRM. Fields such as these make debugging much easier:

automation_status: enriched | partial | retry_pending | failed
enrichment_provider: provider_name
enrichment_checked_at: ISO timestamp
automation_run_id: unique scenario execution ID

The unique run ID provides traceability when a salesperson reports that a record looks wrong. Instead of guessing, you can search the Make execution history and inspect the exact payload used for that CRM update.

3. Score leads with transparent rules

Lead scoring does not need an AI model to be useful. Start with rules that a sales team can explain and adjust.

For example:

company domain present: +10
role contains founder, head, director, or VP: +20
company size matches target range: +20
business email rather than free email provider: +15
target region matches: +10
submission came from a high-intent page: +25

Use Make functions to calculate the total, then route leads into simple groups:

Hot: score 70 or higher
Warm: score 40 to 69
Low priority: score below 40

Only send immediate notifications for hot leads. Warm leads can enter a normal follow-up sequence, while low-priority records remain available for future segmentation. This reduces notification fatigue and gives the sales team a reason to trust the automation.

Keep scoring logic visible in one module or documented note. Spreading small calculations across many filters makes the workflow difficult to audit. If the rules become complex, move them into a dedicated function, database table, or configuration sheet rather than hiding them in router branches.

Testing the Make.com workflow

Before activating the scenario, test these cases separately:

a complete new lead with a valid company domain
an existing CRM contact
a personal email with no company website
an enrichment API timeout
a duplicate webhook delivered twice
a lead that qualifies as hot

Verify both the final CRM record and the execution path. A scenario is not reliable just because the happy path finishes successfully.

Also review what happens after a partial failure. The workflow should leave enough state for a human or scheduled retry process to continue without rebuilding the lead from scratch.

Conclusion

A reliable Make.com lead enrichment workflow is mostly about boundaries: normalize data early, prevent duplicates before paid API calls, treat missing enrichment as a valid outcome, and make retry behavior explicit.

The best scenario is not the one with the most modules. It is the one that produces predictable CRM records, gives sales useful context, and can be debugged quickly when an external service fails.

Build the smallest version first, test failure paths, and only then add more enrichment providers or scoring rules. That approach turns a fragile no-code automation into a workflow the business can actually depend on.

n8n Tutorial: How to Build a Reliable Content Approval Workflow

kingston-888 — Fri, 14 Aug 2026 06:05:49 +0000

A lot of teams adopt workflow automation to save time, but the first version of an automation often creates a different problem: it moves faster than the review process.

That is especially common in content operations. One person writes, another reviews, a third checks links or SEO fields, and someone else finally publishes. If you automate too early, you can accidentally ship incomplete drafts. If you automate too late, the workflow stays manual and slow.

A better approach is to use n8n to automate the boring transitions between stages while keeping the human approval points visible and explicit.

Why n8n works well for approval workflows

If you are searching for an n8n tutorial because you want something more flexible than a simple Zap, approval workflows are a good place to start.

n8n is strong here for three reasons:

it supports visual branching without hiding the logic
it lets you mix app integrations with custom code when needed
it works well for workflows that need both automation and human decisions

A typical content approval flow has more conditions than people expect. You may need to check whether a draft has a title, whether the SEO description exists, whether a reviewer has approved the content, and whether publishing is allowed for that channel.

With n8n, that can all live in one workflow instead of being spread across email, chat, and spreadsheets.

A simple content approval flow you can actually use

Here is a practical pattern that works for small teams.

Step 1: Trigger when a draft is ready

The workflow starts when a draft changes status in Airtable, Notion, Google Sheets, or your CMS.

For example:

status = ready_for_review
channel = blog
owner is not empty

That gives you a clean entry point instead of polling every record blindly.

Step 2: Validate the required fields

Before sending anything to a reviewer, run a validation step.

Check for:

title
summary
target keyword
slug
main body content
canonical link or reference links if required

This prevents the annoying situation where reviewers waste time opening half-finished drafts.

In n8n, this is usually one IF node plus a small code node for custom validation rules.

Step 3: Route to the right reviewer

Once the draft is valid, route it based on content type.

Examples:

technical tutorial -> developer reviewer
landing page copy -> marketing reviewer
case study -> operations reviewer

This is where many teams overcomplicate things. You do not need a huge rules engine on day one. Even a simple mapping table is enough.

Step 4: Send approval tasks instead of full documents

One useful lesson from real automation projects is this: do not send the whole payload everywhere unless people truly need it.

Instead, send a concise approval task with:

title
target keyword
author
current status
direct edit link
approve / reject action

That keeps the workflow fast and reduces noise in Slack or email.

Step 5: Publish only after explicit approval

After approval, the workflow can:

update the record status
notify the owner
push the draft into a publishing queue
create a publish task for the final channel

The important part is not the automation itself. It is the fact that the approval state becomes structured and searchable.

Common mistakes in n8n workflow automation

The most common problem is trying to automate every edge case too early.

People often build huge workflows with too many branches, too many retries, and too many notifications. The result is technically impressive but hard to maintain.

A better rule is:

automate the handoff
automate the validation
automate the status update
keep the approval decision human

That gets most of the value without making the workflow fragile.

Another mistake is ignoring observability. If an approval workflow fails, you need to know where it stopped.

At minimum, log:

workflow start time
content ID
current stage
reviewer assigned
approval result
failure reason

That makes debugging much easier when someone asks, "Why was this draft never published?"

Final takeaway

The best workflow automation setups are not the ones that remove humans from the process.

They are the ones that remove uncertainty.

If you are building your first serious approval flow, n8n is a strong choice because it lets you automate structure without hiding logic. Start with one content path, make the review states explicit, and keep the first version boring enough to maintain.

If you want to compare how different workflow tools and orchestration patterns handle these kinds of approval chains, this related resource is a useful reference: https://www.coreclaw.com/?utm_source=forum&utm_medium=referral&utm_campaign=devp&utm_term=&utm_id=devp

Ship Faster by Removing Hidden Friction from Browser Automation

kingston-888 — Fri, 14 Aug 2026 03:59:37 +0000

Most automation failures are not caused by a broken click or a missing selector. They come from hidden friction: slow content generation, repeated verification, and workflows that type into a browser one tiny action at a time.

When people say an automation is unreliable, what they often mean is that it is doing too much work before the real task even begins.

The first bottleneck is usually over-generation

A lot of content automations start with an overly ambitious prompt. The system is asked to create a long article, multiple sections, several tags, and extra polish before anything reaches the editor.

That sounds impressive, but it slows the entire pipeline.

A faster approach is to set tighter constraints from the beginning:

keep the article short and publishable
reduce the number of sections
limit tags to the most relevant few
optimize for clarity instead of completeness

For a developer platform like dev.to, a focused 700-word post often performs better operationally than a bloated draft that takes much longer to produce and write.

The second bottleneck is slow browser writing

Even after content is ready, many automations waste time by filling the page in fragments. They type a little, verify a little, pause, then continue.

That pattern makes the run longer and increases the chance of interruption.

It is usually better to:

attach to the real visible browser window
confirm the editor once
write title and body in one pass
add only the necessary tags
publish immediately if the page is healthy

The more an automation behaves like a hesitant human, the slower it becomes. Good automation should be decisive.

Reliability often comes from subtraction

People often try to speed up automation by adding more logic. In reality, the biggest gains often come from removing steps that no longer earn their cost.

That includes:

repeated page checks
unnecessary formatting rules
extra retries before failure
too many fallback branches

A lean workflow is easier to debug, easier to trust, and much faster to run.

Final takeaway

If you want browser automation to move faster, do not only optimize the code. Optimize the workflow.

Shorter content, fewer checks, and one-pass writing can remove most of the delay without reducing the value of the result.

Fast automation is rarely about doing more in parallel.

It is usually about doing less on purpose.

From Detached Automation to Same-Window Control: A Practical Lesson in Browser Reliability

kingston-888 — Fri, 14 Aug 2026 03:42:33 +0000

When people talk about browser automation, the conversation usually starts with selectors, scripts, and speed.

In practice, the real challenge often shows up somewhere less glamorous: session fidelity.

I recently worked through a publishing workflow where the browser automation looked correct on paper. It could open the right URL, navigate to the post editor, inspect page structure, and take screenshots. But the first few runs kept reporting a login page, while the human operator was clearly looking at a fully authenticated editor window.

That mismatch turned out to be the entire story.

The real problem was not navigation

The task itself was simple:

open https://dev.to/new
confirm the editor is available
fill in the title, tags, and article body
publish

The automation did reach the correct URL. The problem was that it was doing so in a different browser context from the one the user was actively looking at.

That meant two seemingly contradictory things were both true at once:

the visible Chrome window showed the authenticated editor
the automation session still saw a login page

At first glance, this looks like flaky tooling. It usually is not. It is a context boundary problem.

Why this happens so often

A lot of browser automation is effectively "open another browser and do the same thing there." That approach works fine for public pages, test environments, and clean-room scripts.

It gets fragile when the workflow depends on:

existing login state
extensions
browser-specific storage
multiple user profiles
tabs the user already opened manually

In those cases, the browser is not the important thing.

The session is.

If your automation launches a fresh controlled browser, even with the same executable, you may still miss:

cookies
localStorage
extension state
profile-specific authentication
tab state that only exists in the user’s live window

So the script says "not logged in," while the user says "I am literally staring at the editor right now."

They can both be right.

The fix: bind to the same visible window

The reliable solution was to stop pretending that "same URL" means "same state."

Instead of opening a separate automation-only browser context, the better approach was:

connect to the user’s current visible Chrome window
verify the actual active tab
operate inside that exact browser session

Once the automation was attached to the same visible window, the page state finally lined up with reality.

The signals became unambiguous:

Create Post
Upload Cover Image
New post title here...
Write your post content here...

At that point there was no more guessing. The automation and the human were looking at the same thing.

What this changed in the workflow

After switching to same-window control, the workflow became much more trustworthy.

Instead of:

opening a fresh browser context
inferring state from a lookalike session
risking false negatives on login checks

we could:

attach to the user’s real window
confirm the real editor state
fill content directly where the user was already working
keep human review possible at every step

This matters more than convenience.

When a workflow includes external actions like publishing, sending, or submitting, trust in the execution context is part of correctness.

A script that acts on the wrong session is not just annoying. It is operationally unsafe.

Practical rules I will reuse

If I build similar browser automations again, these are the rules I would keep:

1. Treat authenticated state as a first-class requirement

Do not treat login as a side note. Make it part of the design.

2. Verify the visible page, not just the target URL

A correct URL does not prove you are in the correct state.

3. Prefer attaching to an existing session for real user workflows

Fresh browser launches are great for tests. Existing sessions are often better for production-like desktop tasks.

4. Capture evidence early

Screenshots and page snapshots prevent arguments with assumptions.

5. Separate "browser control" from "window truth"

If the user is watching one window and the automation is driving another, you do not yet have a reliable workflow.

Final takeaway

The hardest bugs in automation are often not code bugs.

They are assumption bugs.

In this case, the bad assumption was simple: if automation opens the same page, it must be seeing the same thing as the user.

It was not.

Once we changed the design from detached automation to same-window control, the workflow became understandable, inspectable, and trustworthy.

That is a good reminder for any automation project:

reliability starts with sharing the same reality as the user.