> ## 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. # Where data lives > Use a CSV for a small pilot, the Database for durable working state, and your CRM for approved operational records. A GTM workflow can produce several kinds of data: an input file, provider observations, an execution's intermediate rows, a review decision, and a CRM update. Giving all of them the same storage role makes it difficult to answer what is temporary, what is reusable, and what the team has accepted as true. The useful distinction is the data's purpose and lifetime. A file supports an inspectable exchange. A run dataset describes work within an execution. The Database carries customer working state across runs. A CRM carries the team's operating records. ![Files, Database working state, and approved CRM records serve different purposes](https://mintcdn.com/deepline2/jbNrWuL_F2rDi05A/images/where-data-lives.svg?fit=max\&auto=format\&n=jbNrWuL_F2rDi05A\&q=85\&s=5c304ff574617fce624eb7d4d4d811ac) ## A file makes a bounded experiment concrete A small CSV ties each input row to an output that a person can review. It works well when testing a new criterion or handing a result to another team. It is less suited to a process that must remember events, join several sources, or coordinate concurrent writers. For example, a first account-research pilot might end with a reviewed export. That is a complete useful result. It need not become a database import or a CRM write merely because those capabilities exist. The transition to durable tables is justified when later work needs memory: which accounts were researched, when an observation was made, or which rows await review. Passing revised files between agents eventually makes identity and history depend on filenames and human convention. ## Runtime Sheets describe one run's row work A Play dataset has named rows and recorded work. Its Runtime Sheet supplies durable row storage for that execution. That is useful when inspecting a batch, recovering retained outputs, or understanding which rows reached each step. Durable does not mean it is the authoritative business table for every future run. A research dataset may include provisional candidates and failed rows that should never appear as approved account facts. A result can also refer to dataset handles rather than inline arrays. The compact run response and an exported row set serve different purposes: one summarizes execution, while the other supplies row data. A caller should not infer that a small status response contains every intermediate record. ## Customer tables carry the process's memory The workspace Database stores customer records and supported event tables independently of a single Play run. It supports questions such as which signals arrived for an account, whether two sources agree, or which approved review result a later process should reuse. Customer-authored working data belongs in permitted customer storage objects, such as qualified `storage.*` tables or allowed customer-managed schemas. Deepline-managed views and internal objects have separate protections. A query interface does not grant unrestricted mutation of every visible relation. The platform owns its own control state: Play definitions, Monitor lifecycle, credentials, and billing. Editing customer data is not a way to change those objects. Their API and CLI operations remain the control surface. ### Storage and cache reuse are different mechanisms A workflow can persist accepted observations and decide when they are fresh enough to reuse. That is an authored data policy. Deepline also has completed runtime receipt reuse, governed by a call's cache identity and refresh behavior. Neither mechanism makes a stored answer permanently correct. A person's role can change after a successful lookup. Reusing a historical result without its observation time may save work while weakening the current decision. ## The CRM carries approved operational meaning A CRM field often has consequences beyond one workflow. Ownership affects routing; lifecycle stage affects reporting; contact details affect outreach. Writing an enrichment candidate into that field promotes an observation into an operating fact. That promotion needs a policy. The workflow must distinguish a plausible candidate from an accepted value, and an accepted value from an authorized change. Approval may be automated or human, depending on the team's rule and the field's consequences. The CRM is therefore a poor default home for raw signals and unresolved candidates. Keeping working evidence separately makes it possible to compare sources without repeatedly changing the rep's record. ## Data can follow several valid paths A Monitor can write directly to the Database. A Play can read a CSV and return a reviewable result. Another Play can query durable state and write a small approved update to a CRM. There is no requirement that every row pass through all storage layers in sequence. In an account-routing example, the posting remains source evidence, the qualification decision is customer working state, and the assigned owner is an operating record. The same account identity connects them, but each answers a different question and can require a different retention policy. ## Continue learning * [Query Database](https://deepline.com/docs/database-access.md): supported reads, writes, and access boundaries. * [Database reference](https://deepline.com/docs/features/postgresql-database.md): schemas and ownership rules. * [Batch CSV enrichment](https://deepline.com/docs/sdk-v2/batch-csv.md): pilot and export procedures. * [CRM repair guide](https://deepline.com/docs/guides/crm-data-quality-automation.md): proposals, allowed fields, and verification. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.