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

# Run a Clay table workflow in Deepline

> Turn a Clay table into a review-first Deepline Play without assuming every column maps one-to-one.

<Info>
  Use this recipe when you have a Clay table and want to test a Play in
  Deepline. Start with a small exported sample. Do not rebuild a full table
  before you have verified the accepted result.
</Info>

## What this recipe does

It moves the data contract, not the interface. You keep the source rows and
the outcome you need, then test a Deepline route against representative rows.
Clay remains a good choice when your team wants to build and operate the work
inside a visual table. Use Deepline when you want the work to run through a
coding agent, CLI, API, SDK, or reusable play.

## 1. Export the smallest useful sample

Export ten representative rows from the Clay table as CSV. Include the
identity fields that make the work possible, such as name, company, domain,
LinkedIn URL, or the upstream columns used by the Clay action.

Keep the original Clay columns in the file. They are evidence for comparing
the pilot; they are not an instruction to recreate each Clay column exactly.

## 2. State the result contract

Before you run anything, write down:

* the accepted output column or columns;
* the evidence or validation rule that makes a result usable;
* values that must not be overwritten;
* failure states that should stay visible;
* the downstream destination for an accepted result.

For example: “Return one current work email when verified. Preserve an
existing valid email. Keep `not_found`, `catch_all`, and `needs_review` as
explicit states. Include the source and verification date.”

## 3. Ask Claude Code to plan the Deepline route

In Claude Code, invoke the customer-facing skill and attach the sample CSV:

```text theme={null}
/deepline-gtm

I exported ten representative rows from a Clay table. I need [accepted output].
Inspect the CSV and propose the smallest Deepline plan. Preserve [columns],
show the output schema and failure states, estimate Deepline spend, and do not
run the full file. Stop for approval after the pilot.
```

If you need to translate an existing Clay table configuration rather than run
a new workflow, use `/clay-to-deepline`. Treat the generated mapping as a draft:
verify the source fields, dependencies, and output contract before executing
it.

## 4. Run the ten-row pilot

Approve only the pilot. Review a mix of easy, incomplete, and ambiguous rows.
Check the output against the result contract, not only whether the cells are
filled.

Ask for a compact review:

```text theme={null}
/deepline-plays-review

Review the pilot against the accepted result. Show accepted coverage, failure
states, evidence, any rows that need human review, and the Deepline spend
before I decide whether to scale.
```

## 5. Save the accepted method

When the pilot is correct, ask Deepline to save it as a play. The play keeps
the input mapping, provider route, evaluation rules, and output contract for
the next file or API call.

```text theme={null}
/deepline-plays

Save the approved pilot as a reusable play. Preserve the input mapping,
acceptance checks, review states, and approval boundary. Do not change the
workflow logic without showing the diff.
```

## When not to use this recipe

Do not expect a one-to-one translation when a Clay table depends on visual
formula behavior, connected-table lookups, app-specific actions, or a large
amount of manual context. Document those dependencies first, then decide
whether to keep that part in Clay or model it explicitly in a Deepline play.

## Related guides

* [Migrate from Clay](/docs/migrate-from-clay)
* [Deepline Skills](/docs/features/claude-code-skills)
* [I have X, I want Y](/docs/plays/decision-tree)