Skip to main content
Start a new idea in a CSV. Move it to Customer DB when the work needs durable state. Write to the CRM only when a person or process should act on the result. Data moves from a CSV pilot, through Customer DB working state, to approved CRM records

​
Choose the right home

​
Start with a CSV

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 input and output concrete before you automate anything.
Keep the pilot small. Review the matched and unresolved rows. Once the rules are credible, move the work into a Play and Customer DB.

​
Use Customer DB for working state

Customer DB is the durable staging layer for code running in Deepline. 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.
Use query_customer_db for bounded agent SQL reads and storage.* tables. Do not use the CRM as a scratch database.

​
Write the result to your CRM

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:
  1. The fields the Play may change.
  2. The evidence or quality gate required for a change.
  3. The action for an ambiguous row: review, skip, or create a task.
  4. Whether a person must approve the update in Slack or another review step.
Do not overwrite CRM fields from an unreviewed enrichment result. Keep the source evidence and the prior value available for review.

​
Common questions from office hours

​
Should I start in Customer DB or a CSV?

Start in a CSV when you are proving a rule or reviewing a small list. Start in Customer DB when the work already needs durable state, volume, joins, or a Monitor. You can import the tested CSV into Customer DB 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 pushes ongoing changes into Deepline. Use a job-change check when you want to inspect an existing list now. See Job changes and CRM cleanup and Monitors.

​
What makes matching 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.

Read Customer DB access

See the supported SQL access paths and the storage.* write boundary.