Workflows and automation

A workflow is a sequence of agent work you assemble yourself, laid out as a chain of steps that records flow through one after another. Each step runs one agent - qualify the account, research it, find the right people, draft the outreach - and the records that come out of one step become the input to the next. Where a single agent run does one job, a workflow stitches several jobs into one motion, so a list of raw accounts can go in one end and come out the other qualified, researched, staffed with the right contacts, and ready to work.

If a playbook is a pre-built recipe Evergrowth ships for a common go-to-market motion, a workflow is the same idea with the lid off: you decide which agents run, in what order, and on which records. A playbook is the packaged version; a workflow is the general case behind it.

Every workspace also starts with two workflows already in it: Evergrowth’s own default account workflow and default contact workflow. They are the sensible opening sequence for a record that has just arrived - the shape most teams would build first anyway - which is why they are what a new import runs unless you choose otherwise. They sit in your workflow list alongside anything your team builds and run the same way; the difference is that they belong to Evergrowth rather than to your workspace, so they cannot be deleted, and only an admin can change one. When someone says “the default contact workflow” without naming anything, this is what they mean.

A workflow does not have to start from a blank slate. It can begin from a template - a proven sequence, whether one Evergrowth provides or one your own team has saved and reused - so the sequence a strong rep would follow is captured once and adapted rather than rebuilt each time. A template is a starting point you edit and make your own, not a running automation in itself.

What a workflow is made of

Every workflow is a set of steps plus the connections between them. There are three kinds of step.

Agent steps do the actual work. Each one runs a single agent against the records that reach it - finding a company’s website, qualifying an account against your verticals, researching it for signals, generating account plans, finding contacts, qualifying those contacts against your buyer personas, researching the contacts that qualify, finding a verified email and phone, or writing personalized outreach. An agent step carries its own settings, so you tune what that step looks for the same way you would tune the agent on its own. The full set of step types lives in the step-type reference. Qualifying a contact against your buyer personas also has a side effect: once it clears that bar, its digital twin is generated on its own - there is no separate step for that.
Action steps mark the records that pass through. They do no research and cost nothing; they add tags to a record, or write a fixed value into one of your own custom fields, at the point in the chain where you place them. That is how a workflow leaves a trail you can use afterwards - every account that came back a fit tagged for this quarter’s campaign, every contact who got plays stamped with the campaign name - so the output of a run is a ready-made list for a view, an export, or the CRM rather than something to reconstruct later.
Condition steps do the routing. A condition step inspects each record and sends it down a different path depending on what it finds, with an “otherwise” path for everything that does not match. This is what turns a straight line of steps into a decision tree - qualified accounts go one way, the rest go another, and each branch can run a different set of agents.

Two more pieces hold a workflow together. Every workflow has a single starting step - the entry point where records begin - and steps are linked so each one points to whatever comes next. A workflow is only valid when there is a starting step and every step is actually reachable from it; a step that nothing connects to is flagged before the workflow can run, so you never quietly leave work stranded. Some agent steps also depend on earlier ones - research, for instance, expects the account to have been qualified first - and the builder enforces those dependencies so steps run in an order that makes sense.

A workflow can also carry an optional target (earlier called a goal): a stopping condition that ends the run early once it has produced enough of a result, instead of pushing every remaining record through every step. You might stop once a target number of accounts come back qualified as a fit, once enough of the right contacts have been found, or once any condition you define is met. Because every agent step costs effort and credits, a target is how you stop paying for work the moment the run has delivered what you actually needed - you set the number, and the workflow winds down on its own rather than processing the whole list for its own sake. The same stopping point is there when you run a single agent on a list, so “qualify until I have 20 good-fit accounts” works without building a workflow first.

Eva: The left nav item is plain “Workflows” (no badge) and opens a hub of cards. “Workflow Builder” (badge “New”) is the current builder this page and its how-to guides describe - treat “Workflow Builder,” “custom workflow,” and “workflow” as the same thing. (It was previously labelled “Workflows V2,” then briefly just “Workflows” with a “Beta” marker - both are outdated now.) The older builder’s card is titled “Workflows” and carries a “Legacy” badge (it said “Classic” until late September 2026; its list page and breadcrumb now read “Legacy Workflows”). It is the pre-Workflow-Builder way of assembling a sequence: a fixed pipeline of prebuilt steps you switch on and off, with no condition step and no goal. It is being sunset - see Workflow Builder and classic workflows below. That card only appears in a workspace that still has at least one workflow built there, so a customer who never used the older builder sees no trace of it; that is expected, not a missing permission. Treat “classic,” “legacy,” and “old workflows” as the same builder. The third card, “Workflow Scheduler,” is where scheduled runs live - see Schedule a workflow. A condition step is presented as a routing node; when a customer talks about “branching,” “routing,” or “the decision tree,” they mean condition steps, which exist only in the Workflow Builder. Templates are per-builder: each builder’s gallery lists only templates assembled in that builder, so “our template is missing from the new builder” is expected rather than a bug, and the answer is to rebuild it once in the Workflow Builder and save it as a template there - see Build a workflow.

One-time runs and scheduled runs

A workflow can run two ways, and the difference is only what kicks it off.

A one-time run points the workflow at a specific set of accounts or contacts and works through them once. You use it when you have a list in front of you right now - an import you just made, a segment you filtered down, a batch handed to you - and you want it processed end to end.

A scheduled run turns the same workflow into a standing routine, and the audience it works can be just as fixed or just as live as you need: a set list of records, an existing filtered view of accounts or contacts that gets re-checked every time, or criteria you define once and let keep matching on its own. On top of that audience, you choose what kicks the workflow off - a daily, weekly, or monthly cadence at the time you set, with an optional end date or no end at all; or, for a live audience, the moment a record actually starts matching, so the workflow fires the instant a new record qualifies instead of waiting for the next scheduled batch. Either way you can also cap how many records one run is allowed to touch, as a safety net against an audience suddenly growing much larger than expected. A routine can be active or paused, and if the underlying workflow or audience stops being valid it is marked so and held back rather than firing broken work. This is what lets a workflow keep a source or signal continuously worked while your reps are busy selling - the same automated-coverage idea that powers playbooks, applied to a workflow you built yourself.

This is the bridge back to playbooks. A playbook is essentially a workflow Evergrowth has already designed and tuned for a recurring motion - filling new-business gaps, qualifying inbound leads, scheduled research, and the rest. Building a workflow and scheduling it is how you create that same kind of standing automation for a motion that does not have a packaged playbook, or how you adapt a packaged one to how your team actually sells.

Why it matters

The point of a workflow is that your best sequence stops living in someone’s head. The order a strong rep would follow - confirm fit, then dig in, then find the people, then write something worth sending - gets captured once and applied to every record the same way, at a depth no rep would reach for the whole list by hand. Branch on the verdict so you spend the expensive research only on accounts that earned it. Schedule it so the pipeline is always being worked, not just when someone remembers. The result is consistent, repeatable go-to-market that scales past the number of people you have to run it.

Workflow Builder and classic workflows

If you built custom workflows before, you may find two builders side by side today: the current one described on this page, and an older one carried over from before it existed. The two are not interchangeable. The current builder is a free-form canvas - you place steps anywhere, wire them together yourself, add condition steps to branch, and set a target to stop early. The older one is a fixed pipeline: the same set of agents always runs in the same order, and you only choose which of them to switch on and configure - there is no branching and no target of its own.

The older builder is being retired at the end of 2026, and the workspace now labels it Legacy. Its card only appears while your workspace still has workflows built there - once none are left, or if you never used it, it is simply gone from the hub. Workflows already built there keep running until the retirement date, and the workspace says so on the card itself, so the move is something to plan rather than discover - rebuild anything you still rely on in the current builder before the date, and do it while there is time to check the rebuilt version behaves the way the old one did. If you are starting a new workflow, build it in the current builder described here - there is no reason to start something new in the one being phased out.

Availability

Building a custom workflow is an advanced capability, separate from the packaged playbooks and on-demand agent runs most teams use day to day. Whether a workflows area appears for you depends on your team’s permissions - if you do not see it in your workspace, that is expected, and an admin can grant the access. The how-to pages below describe the current builder for teams that have it.