Skip to main content
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.

​
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:
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:

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

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