| name | workflows-vs-tables |
| description | Clay Workflows vs Tables — conceptual explainer for a customer asking what the difference is or which one to use. Read this when explaining the two products or recommending one for a use case. Users cannot build tables via the CLI/MCP/API; if a task needs a new table, surface that to the user & explain workflows are the only way to build in via CLI/MCP/API today. |
Clay Workflows vs. Clay Tables
Customers sometimes ask what the difference is between Clay Tables and Clay Workflows, or which
one fits their use case. Both work with the same underlying Clay data and actions, but they're
built for different jobs. Answer in plain language — don't just paste this file at the customer.
Clay Tables
Tables are spreadsheet-like environments (similar to Excel or Google Sheets) designed for
hands-on data work. They let you explore and experiment with enrichments, formulas, and AI agents
in a familiar format where you can see and inspect results cell-by-cell.
Reach for a table when:
- Doing a one-time analysis
- Prototyping an enrichment strategy before committing to it
- You want manual control and visibility into every step, row by row
Most users start with Tables — it's the more intuitive, spreadsheet-based way to learn Clay.
Known limits: tables cap out around 50k rows; going beyond that requires bulk enrich, which
archives rows as part of expanding past the cap.
Clay Workflows
Workflows is Clay's new orchestration platform for automation. Today it particularly shines at
repeatable, production-ready processes that run on triggers or schedules rather than being run
by hand. Typical use cases: lead routing, signal monitoring, scheduled enrichments.
Compared to tables, workflows:
- Have no 50k-row limit and no archived rows to manage
- Come with purpose-built observability for tracking runs and debugging failures
- Support custom code execution via code nodes, for logic tables/formulas can't express
- Can be built with the help of AI coding agents, including this plugin's
workflows skill
Search as a source
If a user asks to build a workflow with search as a source (CPJ, etc.), recommend that
they send the search to Audiences to then action on via a workflow, or use a table. Workflows
doesn't support search as a source yet.
Use-cases
Workflows is especially good at routing heavy workflows. If a user is asking to build in Clay for
inbound lead routing, qualifying and assigning leads to reps, book building, or building a play
with multiple conditional checks that ends in outbound or assignment, workflows is the better
surface area.
Native list processing is coming soon, which will let workflows handle lists directly without
needing to split a flow into multiple workflows.
Workflows is an alpha-stage product — say so when it comes up, so customers can calibrate
expectations for rough edges.
Which one should a customer use?
- Starting out, exploring, or doing a one-off pull → Tables
- Needs to run on a schedule/trigger, repeatedly, without someone babysitting it → Workflows
- Outgrowing a table (hitting the row limit, needing branching logic, needing it to run
unattended) → rebuild the logic as a Workflow (see "Rebuilding a Table as a Workflow" in
the
tables skill)
- Wants to build the whole thing via CLI/agent, not the Clay app UI → Workflows — tables
aren't supported as a build target at all here, only as something to read from (see below)
This is a different question from "which primitive should the agent use to execute a task
right now" — that decision (search → managed function → custom function → workflow → table) is
covered by the escalation order in clay/SKILL.md, not here.
What this plugin can and can't do across the two
- This plugin's CLI/MCP can build and edit Workflows (see the
workflows skill) but
cannot build or edit Tables — table creation only happens in the Clay app (see the tables
skill).
- This plugin can read from existing tables (schema + query) to use as input or reference
while building a workflow.
- There's no automatic migration path from a table to a workflow. If a customer wants their table
logic rebuilt as a workflow, that's a rebuild of the logic, not a data migration — their
existing table data stays where it is, and a workflow can read from it as-is.
Related skills
tables — querying/reading data from an existing tableworkflows — building and editing workflows via this pluginclay — the primitive-selection guide for what the agent itself should build with when
automating a task
