Skip to main content
Migrate one table at a time. Keep the current Clay table active while you prove that the new Play has the same input, logic, review boundary, and acceptable output on the same representative rows.

​
Prerequisites

  • A Clay table you can inspect, plus a small export of representative rows.
  • The expected output fields, acceptance rules, and any review or writeback boundary.
  • A local project folder with Deepline installed. Use the Quickstart if it is not installed yet.
Keep Clay credentials, browser session cookies, and exports with sensitive data out of Play source and version control.

​
Export the table with the Clay Extract bookmarklet

Use the bookmarklet when you are already signed in to Clay and want to capture the table before you migrate it. It downloads a local clay_extract_<table>.json file with the table configuration, fields, schema, sample rows, and up to 500 records. It uses your existing Clay browser session; it does not read, save, or send your Clay cookie to Deepline.
1

Add the bookmarklet

Drag Clay Extract to your bookmarks bar. If your browser does not allow dragging, select the button to copy its URL, then create a bookmark and paste the URL into its address field.
2

Open the Clay table or workbook

Open the table view you want to migrate. The bookmarklet also accepts a Clay workbook URL and creates one export containing its tables.
3

Run Clay Extract

Select the saved bookmark. A progress message appears in the lower-right corner, then your browser downloads the JSON file.
4

Attach the export

Attach the downloaded JSON when you ask /clay-to-deepline to document the table. Review the generated map before you create or run a Play.
The bookmarklet calls Clay’s table and workbook read endpoints from the Clay tab, then downloads the export locally. It does not make changes in Clay.

​
Capture the table before you recreate it

Use the installed clay-to-deepline skill to inventory the table. Give it a Clay export or use its local extraction path. Ask for a review document before any new Play is written:
Review this document against the live table. In particular, confirm provider fallbacks, suppression rules, prompt text, and the conditions that allow a CRM or campaign write.

​
Create one custom Play

After you accept the column map, ask your agent to create a local Play:
The target is a custom Play that your team can inspect and version. Do not replace unverified table behavior with a generic enrichment shortcut.

​
Validate it without deploying or spending credits

Check the local file before it runs:
plays check bundles and validates the source. It does not publish the Play, create a run, or call a provider.

​
Compare a representative pilot

Create leads-pilot.csv with the header and a small mix of normal, sparse, and edge-case rows from the Clay table. Run the custom Play on only that file:
The pilot can use Deepline credits. Export its result and compare it with the same rows in Clay:
Check the input preservation, output values, unresolved rows, provider fallback behavior, review boundary, and Deepline-credit usage. Record every intentional difference before you continue.

​
Publish only after the pilot passes

Keep Clay as the fallback until the pilot meets the agreed acceptance rules. Then publish the reviewed source:
For a scheduled, webhook-triggered, or writeback workflow, add the trigger and external action only after the batch Play is correct. See Webhooks and schedules and Cost control for the next boundary.