Workflows Vs Tables

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 via the workflows entry-point 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.

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 entry-point 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 you can and can't do across the two

• You can build and edit Workflows (see the workflows entry-point skill) but cannot build or edit Tables — table creation only happens in the Clay app (see the tables entry-point skill).
• This skill 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 regular-table data stays where it is. For a bulk enrichment table, rebuild from the available source configuration and column DAG; use Audience configuration only when the source includes it. A rows list response with truncated: true is only a bounded retained-row sample; completed passthrough rows may already be deleted, so it is not a complete input dataset.

Related skills

• the tables entry-point skill — querying/reading data from an existing table
• the workflows entry-point skill — building and editing workflows
• clay — the primitive-selection guide for what the agent itself should build with when automating a task