> ## Documentation Index
> Fetch the complete documentation index at: https://help.pipelime.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Find & Enrich blocks: Verify Email, Find Phone, Find Email, Company

> Blocks that go and get something before the flow continues, and the branches they hand back.

export const Screenshot = ({id, alt, caption, frame = 'browser', url, marks = [], lang = 'en', workspace = 'northwind-outbound'}) => {
  const src = `/images/screenshots/${lang}/${id}.png`;
  const chrome = url ? `app.pipelime.ai/${workspace}${url}` : 'app.pipelime.ai';
  return <figure className={`pl-shot pl-shot--${frame} not-prose`}>
      <div className="pl-shot__frame">
        {frame !== 'bare' && <div className="pl-shot__bar">
            <span className="pl-shot__dots">
              <span className="pl-shot__dot" />
              <span className="pl-shot__dot" />
              <span className="pl-shot__dot" />
            </span>
            <span className="pl-shot__url">{chrome}</span>
          </div>}
        <div className="pl-shot__media">
          <img src={src} alt={alt} loading="lazy" />
          {marks.map(mark => <span key={mark.n} className="pl-shot__mark" style={{
    left: `${mark.x}%`,
    top: `${mark.y}%`
  }} aria-hidden="true">
              {mark.n}
            </span>)}
        </div>
      </div>
      {caption && <figcaption className="pl-shot__caption">{caption}</figcaption>}
    </figure>;
};

Four blocks in the **Find & Enrich** category send a workflow out to look something up about the lead in front of it, then branch on what comes back: **Enrich Company**, **Find Email**, **Verify Email** and **Find Phone**.

<div className="pl-availability">
  <div className="pl-availability__row">
    <div className="pl-availability__label">Where</div>
    <div className="pl-availability__value"><span className="pl-path">Outreach<span className="pl-path__sep">→</span>Workflow Builder</span></div>
  </div>

  <div className="pl-availability__row">
    <div className="pl-availability__label">Your role needs</div>
    <div className="pl-availability__value">Create access to Workflow Builder <code>create-workflows</code>. Admin and Member have it by default.</div>
  </div>

  <div className="pl-availability__row">
    <div className="pl-availability__label">To create or change</div>
    <div className="pl-availability__value"><code>create-workflows</code> to add one, <code>update-workflows</code> to change one, on top of the permission above.</div>
  </div>

  <div className="pl-availability__note">Not listed in the sidebar today; reachable from the surfaces that link to it, and by URL. If you cannot find this in your sidebar, your workspace may have a custom menu configuration. Contact support and we will check it for you.</div>
</div>

## What each block does

| Block              | What it does                                                                                 | Branches                            |
| ------------------ | -------------------------------------------------------------------------------------------- | ----------------------------------- |
| **Enrich Company** | Scrape the lead's company website and extract emails, phones, socials, description and logo. | **Enriched** · **No data**          |
| **Find Email**     | Look up the lead's work email, job title, LinkedIn and phone.                                | **Found** · **Not found**           |
| **Verify Email**   | Check that the lead's email is deliverable before you send.                                  | **Valid** · **Risky** · **Invalid** |
| **Find Phone**     | Reveal the lead's phone number for WhatsApp or calling.                                      | **Found** · **Not found**           |

The category holds a fifth block, **Find Employees**, which adds other people at the lead's company as new leads instead of changing the lead in front of it. It is listed in [the full block catalog](/en/workflows/logic-timing-and-finish-blocks#the-full-block-catalog) and not covered on this page.

<Screenshot id="workflows/find-and-enrich-blocks--verify-email" url="/workflows/new" alt="The Verify Email block added to a blank workflow canvas, showing three branch rows down its right edge, Valid, Risky and Invalid, each with a coloured dot and a connection handle, with the block's settings panel open on the right of the screen" caption="Three branches, always, whether or not you touch anything on the block. Adding a block from the palette also opens its settings panel." />

## Wire every branch, not just the happy path

These four are branch blocks: each has two or three separate output handles, and every one of them is a path a lead can take.

<Warning>
  Nothing checks that you wired them. The canvas only warns you when a whole block is disconnected from everything. Activation refuses a graph for plenty of other reasons, a missing trigger, a dangling edge, a loop that never ends, but never for an unwired branch. So a branch with nothing coming out of it raises no error and no warning at either point. Reach it and that lead's run through the workflow ends right there, with the enrollment marked complete as if the workflow had nothing left to do.
</Warning>

That is easiest to miss on **Verify Email**, because **Risky** is not a rare edge case. It covers two ordinary situations: a catch-all domain, where a check can never prove one specific mailbox exists, and a check that came back inconclusive for any other reason. Wire only **Valid** and **Invalid**, and every lead whose check comes back risky quietly stops at the block.

The built-in templates take a clear position on this. **Core Outbound Sequence** builds a deliverability gate in front of its first send, and that gate treats **Risky** as good enough to send:

| From             | Branch      | Goes to                           |
| ---------------- | ----------- | --------------------------------- |
| **Verify Email** | **Valid**   | **Send Email**                    |
| **Verify Email** | **Risky**   | **Send Email**, same as **Valid** |
| **Verify Email** | **Invalid** | **Stop / Exit**                   |

Several other built-in templates carry the same gate, wired the same way. [Templates reference](/en/workflows/templates-reference) says which. Wire your own workflow like that, or route **Risky** somewhere else on purpose. Either is fine. Leaving it unwired is the only choice you did not actually make.

## The lookup runs in the background

Each of these blocks hands its work to a background job rather than holding up the workflow engine while it runs: a deliverability check (**Verify Email**), a lookup against our data provider (**Find Email**, **Find Phone**), or a full site scrape (**Enrich Company**). The lead's enrollment waits at the block while the job works, the same way it waits at a **Wait / Delay** block, and resumes down whichever branch the job reports.

If the job never reports back in time, the lead does not stay there. The engine takes the safe branch itself: **Risky** for **Verify Email**, and **Not found** or **No data** for the other three.

**Find Email** and **Find Phone** are the two that draw on your credit balance, so they get one extra state. If the workspace has already spent its credit allowance, or the data provider is unreachable, the block suspends instead of reporting a false **Not found**. It re-checks periodically, picks up where it left off once credits or the provider come back, and only gives up to the safe branch if it has been stuck that way for too long. **Verify Email** and **Enrich Company** never suspend like this: running a verification is free, and the company scrape does not draw on the lookup pool at all.

## What each block needs before it can search

**Find Email** and **Find Phone** need at least one identifier: an existing match with our data provider, a LinkedIn URL on the lead, or a resolvable company domain. Missing all three sends the lead straight to **Not found** without attempting a lookup, and without spending anything.

**Enrich Company** needs a company. A lead with no company record and no domain to build one from goes straight to **No data**.

None of the three need the lead to already be attached to a company. All three resolve a domain the same way, in this order:

1. The website link on the lead's company.
2. A website link on the lead itself.
3. The domain half of the lead's own email address, skipped when it is a personal provider like Gmail, so a personal address can never get "enriched" against Gmail itself.

**Enrich Company** and **Find Phone** then make sure the lead is attached to a company for that domain, creating a bare one and linking the lead to it when there is none, so there is somewhere to attach results and something for the lookup to match on. **Find Email** works straight off the domain and creates nothing.

## What each block costs

**Enrich Company** never touches your credit balance. Neither does running **Verify Email**.

**Find Email** and **Find Phone** are the metered pair, and they are metered differently:

* **Find Email** does not bill per address. What counts against your balance is the lead: finding an address marks the lead chargeable, and a chargeable lead counts once, however many lookups you run on it. A lookup that comes back **Not found** does not make the lead chargeable.
* **Find Phone** bills per number, and per number the provider returns. One reveal can come back with a work number, a direct dial and a mobile, and this block charges for each of them. A revealed number costs more than a chargeable lead does.

Neither one bills when the skip toggle skips the lookup, because nothing is dispatched at all.

**Verify Email** is a special case worth knowing about. The check itself is always free, whatever it decides, but a **Valid** result quietly does one more thing: it marks the lead chargeable. A lead that arrived free, added by hand, imported, or captured through a web form or the API, can become chargeable this way. **Risky** and **Invalid** never do it. See [what consumes credits](/en/billing/what-consumes-credits) for the figures and for every other way a lead becomes chargeable.

## Verify Email

The block checks one address: the most recently added email on the lead. A lead with no email at all never gets checked, and takes the **Invalid** branch immediately.

The three branches are the same three outcomes the rest of the product shows you, under the workflow builder's own names: **Valid** is a verified address, **Invalid** is a failed one (which includes a throwaway address), and **Risky** is an inconclusive check. [Email verification](/en/email-accounts/email-verification) has the full verdict table behind those three words.

The block ships with one setting, `When the result is risky`, offering `Valid (send anyway)` and `Invalid (skip the send)`. It has no effect. The value is saved on the block, but nothing in the engine reads it, and the block always resumes down whichever of the three branches the check produced. Route a risky result by wiring the **Risky** handle, not with this setting.

## Find Email and Find Phone

Both default to skipping the lookup when the lead already carries that kind of data. `Skip if the lead already has an email` and `Skip if the lead already has a phone` are on out of the box, and they are the first thing either block looks at, before the identifier check above. Re-run one of these blocks on a lead that already has the answer and it takes the **Found** branch immediately: no credit spent, no fresh lookup, and no need for an identifier at all. Turn the toggle off to force a fresh check regardless.

<Screenshot id="workflows/find-and-enrich-blocks--find-phone-inspector" url="/workflows/new" alt="The Find Phone block's settings panel open on the right of the screen: the Find & Enrich category label, the Find Phone title and its description, and a single toggle reading Skip if the lead already has a phone, switched on" caption="One setting. Nothing on this panel mentions what a reveal costs." />

On the canvas, **Find Phone**'s **Not found** branch is a neutral gray while **Find Email**'s is red. That is a deliberate signal about how much each miss matters: plenty of leads have no findable phone number, but a work email that cannot be found leaves the flow with nothing to send to.

## Enrich Company

`Data to fetch` reads like it controls what the scrape pulls off the site. It does not. The scrape always extracts everything it can find, and the field decides the branch instead: which kinds of data have to be present for the result to count as **Enriched**. Leave it empty, the default, and any single kind of data found is enough. Narrow it and only the types you picked decide, so the block can come back with an email and a phone number and still take **No data** if neither of those was on your list.

`Overwrite existing company values` does nothing. The block stores whatever you set, and the value is never passed to the scrape.

A company that has already been fully analyzed is not scraped again. The block branches on whatever is already stored against it, so running **Enrich Company** twice on the same lead does not scrape the site twice.

## Related

<CardGroup cols={2}>
  <Card title="Email verification" icon="mail-check" href="/en/email-accounts/email-verification">
    The five verdicts behind Valid, Risky and Invalid, and how each one is reached.
  </Card>

  <Card title="Get a phone number for a lead" icon="phone" href="/en/leads/get-a-phone-number">
    The same reveal Find Phone runs, from one lead's own page, without building a workflow.
  </Card>

  <Card title="Verify a lead's email address" icon="shield-check" href="/en/leads/verify-an-email-address">
    The same check Verify Email runs, on demand, from one lead's own page.
  </Card>

  <Card title="What consumes credits" icon="coins" href="/en/billing/what-consumes-credits">
    What a revealed phone number costs, and every way a lead becomes chargeable.
  </Card>
</CardGroup>