Choose the right home
This is a boundary, not a conveyor belt
Data does not need to pass through every place. A small CSV pilot can end with a reviewed export. A Monitor writes events directly to the Database. A Play can read durable data, create a reviewable result, and write only approved fields to the CRM. The useful question is: who needs to trust this data next?- If you are still proving the rule, keep it inspectable in a CSV.
- If code or multiple runs must remember it, keep it in the Database.
- If a person or operating process must act on it, write the approved result to the CRM.
CSV: prove the rule
Use a CSV for a first run: a new ICP, a small list, a one-time research job, or a file someone needs to inspect. It makes the input and output concrete before you automate anything.Database: keep durable working state
The Database is the workspace-scoped PostgreSQL database for durable customer records and supported event tables. Use it when a process has more than one source, needs a SQL join, must deduplicate records, receives Monitor events, or must remember what happened in an earlier run. Examples:- A Monitor writes job-change events; a Play joins them to existing people and accounts before deciding whether to notify a rep.
- A Play stores enrichment results and avoids paying again for the same lookup.
- A research workflow compares several sources before producing an approved audience or CRM update.
query_customer_db for bounded agent SQL reads
and storage.* tables for agent-owned data. Do not use a CRM as a scratch
database.
Runtime Sheets are different
A Runtime Sheet stores per-run row state for a Play dataset: row data and the steps that ran for that execution. It helps you inspect or resume that run. The Database stores durable records independently of any one Play run. Do not treat a Runtime Sheet as a Database table, or use the Database as a substitute for per-run output.CRM: operate on approved results
The CRM is the operating record: what the team owns, works, and reports on. Write a result there after the rule and fields are clear. Before an automated CRM write, define:- The fields the Play may change.
- The evidence or quality gate required for a change.
- The action for an ambiguous row: review, skip, or create a task.
- Whether a person must approve the update in Slack or another review step.
Common decisions
Should I start in the Database or a CSV?
Start in a CSV when you are proving a rule or reviewing a small list. Start in the Database when the work already needs durable state, volume, joins, or a Monitor. You can import a tested CSV later; do not build a large process around passing files between agents.Does a Monitor replace a job-change check?
No. Use a Monitor when a supported external source produces ongoing changes that Deepline should store. Use a job-change check when you want to inspect an existing list now. See Job changes and CRM cleanup and Monitors.What makes a match reliable enough for a CRM update?
Use stable input whenever possible. A LinkedIn URL is stronger than a name and company alone. Treat a company-name mismatch as a lead, not proof; keep the profile or domain evidence with the proposed update.How do I avoid a large, brittle Play?
Make the first Play do one useful job. Add an explicit quality check between source, enrichment, and CRM write. A failed or ambiguous row should have a defined output, rather than falling through to an update.Query Database
Read the supported SQL access paths and the
storage.* write boundary.