Import Research into Clay with Sources Intact

Decide what Clay should do with the imported research

Write the table's purpose before choosing columns. It might be a review workspace for sourced company research, a place to add a specific missing field, a scoring worksheet, or a staging layer for CRM delivery. These uses have different requirements. A table intended only for review does not need automatic downstream actions; a table intended for updates needs stronger identity and reconciliation controls.

Define the boundary between imported research and new work performed in Clay. For example, the imported file may contain a reviewed product classification and sources, while Clay is used to check a current website URL or add a missing business description. The new task should not silently reinterpret every original finding unless that is explicitly intended.

Name a table owner and an acceptance owner. The table owner maintains columns, formulas, and enrichment settings. The acceptance owner decides whether the resulting evidence supports the business use. One person can hold both roles, but the distinction prevents a successful automation run from being mistaken for a completed research review.

Prepare a clean CSV and inspect the import preview

Clay's documentation describes uploading a CSV by browsing for a file or dragging it into the import area. Use the current documented import flow and inspect the resulting columns and sample rows. A successful upload establishes that data entered the workspace; it does not establish that types, identities, sources, or findings are correct.

Save an unchanged source file and prepare a separate import copy. Use a single header row with unique, descriptive column names. Keep embedded commas, quotes, and line breaks correctly encoded in the CSV. If a long narrative breaks into unexpected columns, repair the export rather than manually moving cells in the destination table.

Check a few difficult rows before proceeding: a company name with punctuation, a URL containing query parameters, an empty optional field, a quoted sentence, and a multiline research note. Confirm that these values arrive intact. A table with plausible first rows can still contain later parsing errors, so choose examples that exercise the actual file's complexity.

References: Clay: How to import your CSV into Clay ↗

Use stable keys that survive sorting and enrichment

Create a company_key that identifies the researched entity within the project and a source_row_key that identifies the original input row. If the company already exists in a CRM, preserve the native CRM ID in a separate field. Do not use the current row number as the only identifier; sorting, filtering, and appending can change what that number refers to.

A canonical domain can help match companies, but it is not a complete entity model. Several subsidiaries can share a domain, and a company can operate several domains. Keep the reviewed entity key separate from the domain. Record aliases and uncertain matches in the evidence or review layer rather than merging them automatically.

Carry the same keys into every evidence row and downstream export. This lets a reviewer trace a finding back to its company even after the table has been reordered. It also supports targeted correction: if one company's identity is wrong, the team can find all related claims and outputs without relying on text search through a narrative paragraph.

Separate company fields from claim fields

Use a company table for stable identity and concise reviewed attributes, and an evidence ledger for individual claims. The company table might include company_key, company_name, canonical_domain, input_origin, research_status, accepted_score, brief_url, and reviewed_at. The evidence ledger can contain claim_key, company_key, criterion, observation, source_url, observed_at, confidence, and review_note.

This structure prevents one source URL from appearing to support an entire dossier. A product page may support a product classification, while a jobs page supports a hiring observation. Those findings have different dates and limitations. Keeping them separate allows a reviewer to accept one claim and hold another without discarding all research about the company.

If the project is small, the evidence ledger can remain a companion CSV rather than a complex relational system. The essential control is the stable company key and an explicit claim-to-source link. Choose a structure the team can maintain. A sophisticated design that nobody updates is less useful than a simple, consistently applied ledger.

Preserve input origin and added research separately

Prefix or group fields according to their origin. For example, input_company_name records the supplied value, research_company_name records the reviewed result, and accepted_company_name records the value approved for downstream use. You do not need three copies of every field, but important conflicts deserve a structure that preserves both evidence and decision.

Record input_origin and research_origin at the appropriate level. An Apollo export, a customer CRM export, a manually researched page, and a generated summary are different origins. A later enrichment should not make the original contact details appear newly verified if no verification occurred. Use explicit task scope and timestamps to show what was actually added or checked.

Avoid overwriting source columns with formulas or enrichment outputs. Put derived values in new columns until reviewed. This allows comparison and rollback, and it helps explain why a later result differs from the input. The accepted output can then be mapped deliberately rather than choosing whichever column happens to be populated most recently.

Give missing and conflicting evidence usable states

A blank cell is ambiguous. It may mean not researched, not found, not applicable, unavailable, or an import error. Define those states in a status column instead of forcing every condition into the same empty value. The actual finding can remain blank when unknown, but the status should explain why.

Do not turn absence of public evidence into a negative claim automatically. If a company does not mention a technology, that may be an unknown result rather than proof it does not use it. Similarly, a failed page retrieval says something about the research attempt, not necessarily about the business. Preserve the difference so later scoring does not reward or penalize companies for the wrong reason.

For conflicting sources, store both observations with dates and a review note. The accepted company field can remain pending until the reviewer decides. A formula that selects the newest nonblank value may be convenient, but recency alone does not establish authority or relevance. Explain the conflict resolution rule and test it on representative examples.

Worked example: one company, three claims, three sources

This fictional example concerns Harbor Metrics. The input file supplies the company name and website. Research identifies a public onboarding page, a product integration page, and a careers page. The onboarding page supports a claim that assisted onboarding is offered. The integration page supports a named integration capability. The careers page supports a dated published vacancy, not a claim that the role has been filled.

The company table contains one company_key and concise review status. The evidence ledger contains three claim keys, each with its own source URL, observation date, and interpretation. The company brief can summarize all three, but the summary does not replace the ledger. A reviewer can inspect the integration claim without searching through the entire narrative.

Suppose the careers page is no longer accessible during review. The hiring claim moves to needs review, while the onboarding and integration claims remain accepted if their evidence is still sound. The account's score is recalculated only according to the documented treatment of the unresolved criterion. The table does not erase the other findings or present the vanished page as a current verified vacancy.

The example demonstrates the advantage of claim-level provenance: uncertainty can be handled precisely. If all three findings were stored in one paragraph with one homepage URL, the reviewer would have difficulty determining what changed and which conclusions remain supported.

Add new enrichment as a bounded research task

Define one question for each enrichment step. 'Find whether the company offers managed onboarding and return the supporting page' is more inspectable than 'research everything useful about this company.' Specify the expected output fields, treatment of unknowns, and required source evidence. Keep the task aligned with the campaign's actual decision.

Before running across the table, review the configured inputs and output columns on a small representative set. A prompt or lookup that receives the wrong domain can produce a fluent result about the wrong company. Stable keys and visible input columns make that error easier to detect. Do not infer correctness from the fact that the enrichment returned text.

Treat generated summaries as interpretations that need evidence. If a result states a finding without a usable source, mark it for review rather than accepting it because the wording sounds confident. If the source supports only part of the statement, narrow the accepted claim. The table should reward traceable information, not eloquence.

Review automatic execution and downstream actions in the actual workspace. Ensure that importing or editing a row does not unexpectedly run costly or consequential processes before the owner is ready. Configuration changes should be tested with the same care as the initial import.

Score accepted evidence without losing the reasoning

If a score is useful, define its purpose and the criteria that contribute to it. Separate mandatory eligibility criteria from optional ranking signals. A company that fails a mandatory service-fit condition should not be rescued by several weak positive signals unless the policy explicitly allows that tradeoff.

Keep score_version and criterion_status available. When a criterion changes or a source expires, the team should be able to identify which scores need review. A number without its rule version is hard to compare across batches. If the score is imported from a research supplier, preserve its supplied meaning rather than treating it as a probability of purchase.

Inspect a few high, low, and borderline scores manually. Ask whether the ranking reflects the actual evidence and intended decision. A formula may be syntactically correct while treating unknown values incorrectly or double-counting related observations. Use the review to repair the rule, then document the change before comparing the revised score with earlier results.

Worked example: an enrichment contradicts the input

In this fictional scenario, the input describes Cedar Applications as an agency, while a new research step classifies it as a software vendor. The generated summary is confident but cites a product page that also mentions implementation services. Automatically replacing the input category would conceal a genuine ambiguity in the business model.

The reviewer preserves input_business_model and research_business_model, then opens the source pages. The accepted classification becomes a documented mixed model, with a note explaining which part matters to the campaign. If the campaign requires a pure software vendor, the account may remain excluded or held even though the company sells software.

The downstream output uses accepted_business_model and includes the review note or brief link. The original supplied value remains available for traceability. This approach allows the table to improve the research without rewriting its history. It also prevents a later operator from assuming that the generated label was independently verified merely because it occupied the final column.

Prepare a reviewed output view for downstream systems

Create an output specification separate from the working table. Include only accepted fields needed by the receiving workflow, plus stable identifiers, source references, observation dates, and the batch version. Internal prompts, temporary debug columns, and unresolved draft claims should not become CRM properties or email merge fields accidentally.

Map accepted fields explicitly. For example, accepted_company_name updates the approved organization name field, while research_company_name remains an audit value. A brief URL should point to the accepted version and be accessible to the intended user. Test links and permissions before handoff so the salesperson does not receive a table whose evidence cannot be opened.

Preserve suppression and communication eligibility from the system responsible for them. A newly enriched account score must not override those controls. If the table feeds customer-configured automation, require a staging or acceptance gate before any outreach action. The fact that Clay can hold a result does not establish that the result is ready for communication.

Troubleshoot broken provenance and mismatched rows

If sources appear detached from findings, inspect the keys and joins before editing prose. A partial spreadsheet sort, a duplicated company key, or a lookup returning multiple entities can produce plausible but incorrect combinations. Return to the unchanged source file and reconstruct the relationship using reviewed identifiers.

If a source URL is generic or irrelevant, check whether the task requested evidence for the specific criterion and whether the result actually supplied it. A homepage can support some basic identity claims, but it may not support a detailed product or technology claim. Mark the finding as needing review until the source is adequate.

If a rerun changes a finding unexpectedly, compare the prior input, task configuration, source date, and output. Preserve the previous accepted result while the difference is reviewed. Do not allow repeated enrichment to create an untraceable moving target. A controlled version history is especially valuable when the result influences account ranking or customer-facing messages.

Agree what an imported research delivery actually includes

For a supplier delivery, specify the company key, original input identifiers, claim fields, source format, dates, null states, and brief structure before work starts. Ask for a sample that demonstrates the difficult cases, including unknown and conflicting evidence. A sample containing only complete positive records provides little assurance about real-world handling.

StackShortlist can provide research for a new list or enrich an own list; payment is taken at checkout and the research is prepared after payment. Own-list enrichment does not guarantee a new contact. Stack leads already includes fit scores; Company intelligence adds general company context, while Your-offer intelligence ties the dossier to the buyer's offer. Preserve those distinctions when naming columns and describing the output.

Importing a delivered CSV into Clay does not imply a live StackShortlist-to-Clay connection or automatic refresh. An agreed signed HTTPS webhook may support customer-configured automation, but field mapping, retries, idempotency, acceptance, and downstream actions still need explicit design. The receiving team should be able to explain which system owns each step.

Accept the table as a research artifact, not just an upload

A final review should trace several records from input through evidence, interpretation, accepted fields, and output. Include a straightforward positive match, a rejected account, an unknown criterion, a conflicting source, and a changed result. The reviewer should be able to explain why each accepted claim is supported and where the limitations remain.

Retain the import file, schema, evidence ledger, task definitions, score version, and output specification together. Review them when the campaign or research question changes. A table remains trustworthy when its structure makes uncertainty and provenance visible, even after several people and tools have contributed to it.

• Every company and claim has a stable key that survives sorting and export.
• Sources and dates support individual findings rather than an undifferentiated paragraph.
• Input values, new research, and accepted outputs remain distinguishable.
• Unknown, conflicting, and failed-retrieval states are explicit.
• Enrichment tasks have bounded questions and reviewable evidence requirements.
• Downstream exports include accepted values and preserve identity, preferences, and review gates.