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.

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 two 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.
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 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 goal is how you stop paying for work the moment the run has delivered what you actually needed - you set the target, and the workflow winds down on its own rather than processing the whole list for its own sake.

Eva: The left nav item is plain “Workflows” (no badge) and opens a hub with two 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 other card, “Workflows” with a “Classic” badge, is the older, 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. 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.

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 goal 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 goal.

The older builder is being retired. Workflows already built there keep running for now, but the workspace is steering everyone toward rebuilding anything they still rely on in the current builder before the older one is switched off. 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.