Company intelligence is easiest to use in Pipedrive when it stays attached to the right organization and remains distinguishable from person details and sales opportunities. A researched company does not become a deal merely because it has a score, and a person row should not be the only place where a company-level finding is stored.
This guide provides an original preparation workflow and fictional mapping specimen for organization and person data. The platform-specific guidance is checked against Pipedrive's current import documentation. The examples are design exercises, not a claim of a live account test. Review your own fields, permissions, existing records, and automation before running a representative import.
What you’ll be able to do
- Put company findings on organizations and person-specific information on people.
- Use the correct Pipedrive System ID for reviewed updates to existing items.
- Keep research fit separate from a lead or deal's commercial status.
- Prepare custom fields and a protected-values policy before mapping the file.
- Check associations and downstream actions in addition to the import summary.
Define the decision the research should support
Begin with a narrow purpose: prioritize existing organizations, add source-backed context before a conversation, identify relevant people, or review whether an account fits a particular offer. The purpose determines the fields and objects needed. A general company brief may support account review without creating a new lead or deal.
Write down what the import is allowed to change. For example, it may add research status, observation date, and a brief link to organizations while leaving owners, deal stages, and person preferences untouched. This boundary is especially important when research returns from an external supplier that cannot see the full history of the customer relationship.
Name the person who accepts the batch and the person who resolves exceptions. The operator mapping columns should not have to decide whether an uncertain company belongs in the pipeline. Business decisions belong to the account or process owner; technical mapping should implement those decisions clearly.
Distinguish organizations, people, leads, and deals
Pipedrive's import documentation groups fields by item type, including person, organization, lead, and deal. It also distinguishes default, system, and custom fields. Use that structure deliberately: an organization holds company context, a person holds contact context, and sales work is represented through the appropriate lead or deal process configured by your team.
A company research score does not establish a commercial project. Do not populate a deal value or expected close date just because a research template contains a potential-fit estimate. If your process creates an early lead for review, label its state accurately and ensure it does not appear as a qualified opportunity in reporting.
Decide how the team represents complex relationships. A group with several operating companies may require separate organizations. A consultant may have a relationship with several client accounts. The correct structure should follow the team's business model and available relationship controls, not the convenience of a flat spreadsheet. Hold ambiguous cases until the owner can explain the intended representation.
References: Pipedrive: Import fields ↗
Create a small organization research dictionary
Choose fields that support actual review and sorting. A practical organization dictionary might include research_fit_status, research_score, research_observed_at, research_source_url, research_brief_url, research_version, and research_review_status. These are proposed custom fields, not Pipedrive defaults. Specify the type, allowed values, meaning, and owner for each.
A score needs a scale and criteria. A value of seventy has no useful meaning unless the team knows what was assessed and how unknown evidence was treated. Keep the explanation available through a brief or linked dictionary. If the research relates to a specific offer, preserve the offer or brief version so future users do not apply the score to a different product.
Separate the observation date from the delivery date. A file delivered today may contain a finding observed earlier. Both dates can be useful, but they answer different questions. Likewise, a source URL should support a particular finding rather than act as a decorative homepage link attached to every field.
For example, define research_fit_status as accepted, rejected, or review, and document exactly which criteria permit each value. If a score is stored, record whether missing evidence lowers the score, remains neutral, or sends the account to review. A seller sorting on the numeric value should not have to guess. Define research_brief_url as a link to the accepted brief version, not a temporary download address that will soon become unusable. If access is restricted, test that the intended owner can open it before the handoff. These details make the fields operationally useful after the spreadsheet has left the researcher's hands.
Preserve the correct System ID for each item
Pipedrive documents using System IDs to update existing items through a spreadsheet. Each item has its own identifier, so an organization ID and a person ID must remain in separate columns and map to the correct item. Export the relevant IDs with the fields you intend to update and preserve them unchanged through the research process.
Do not treat a source supplier's row key as a Pipedrive System ID. Keep source_company_key and pipedrive_organization_id distinct, even if both are numeric. The source key traces the research; the native ID targets the existing CRM item. A clear mapping between them is what makes a repeatable enrichment cycle possible.
Review the exported population. A view focused on deals may not include people or organizations without associated deals. Make sure the export covers the actual accounts intended for enrichment. Missing records in a narrow export should not lead the researcher or importer to assume that those companies are new to the CRM.
References: Pipedrive: Updating data with a spreadsheet ↗
Build the mapping before uploading the spreadsheet
Prepare a source-to-destination table with object, field, type, update policy, and example value. Create or review custom fields before the main import. During mapping, confirm that each column points to the intended item type, especially when organization and person fields have similar names.
Keep audit-only information in the working package without mapping it accidentally. Notes such as 'check this company' or 'possible duplicate' should not become customer-facing text or overwrite a business field. If review status belongs in the CRM, use a clearly defined property and allowed values. Otherwise retain the note in the exception ledger.
Map only fields the batch is authorized to change. Including extra reference columns can be convenient for humans, but an operator may inadvertently import them. A prepared import file with a deliberate set of columns reduces that risk. Retain the richer working file separately for review and traceability.
| Source column | Destination item | Mapping decision |
|---|---|---|
| pipedrive_organization_id | Organization | System ID for reviewed updates |
| organization_name | Organization | Name; update only when approved |
| canonical_website | Organization | Website or approved equivalent field |
| research_fit_status | Organization | Proposed custom classification |
| research_observed_at | Organization | Proposed custom observation date |
| pipedrive_person_id | Person | Separate System ID for person updates |
| person_email | Person | Reviewed business email field |
| brief_url | Organization | Proposed custom research link |
Protect existing ownership and person preferences
Identify fields that research should not overwrite: current owner, active deal stage, buyer commitments, contact preferences, internally confirmed role information, and other protected relationship data. The exact list depends on the workflow, but it must be written before import. A new file should not have unrestricted authority over a living CRM.
When incoming research conflicts with a protected or verified value, preserve both in a review record and assign an owner. A public page may be outdated, while the CRM contains a recent conversation. Conversely, an old CRM field may need correction based on clear current evidence. Review the sources and dates rather than deciding solely by which system supplied the value.
Test missing-value behavior. An empty phone field may mean the research did not include phone, not that the existing phone should be removed. An unknown fit criterion may need a review state rather than a negative value. Check the actual import behavior for blanks and approved update settings before releasing the full batch.
Worked example: enrich two organizations without creating deals
This fictional example involves Elm Manufacturing and Harbor Design, both already present as organizations. Elm has one existing person; Harbor has two. The research adds a product-category finding and a dated source to each organization, plus a linked brief. The campaign owner has not yet decided whether either account should receive outreach.
The operator exports the organization System IDs and prepares organization-only updates for the research fields. The people remain unchanged. No lead, deal, value, or close-date field is included. The expected result is two updated organizations with current research context and no new commercial objects. That boundary matters because a company can be a plausible fit without having an active buying project.
The test reviewer opens both organizations, checks the findings and links, confirms the original owners, and verifies that existing people remain associated correctly. The reviewer also checks that no automation has created unwanted outreach tasks. The test is accepted only when the actual account behavior matches the intended operation.
The numerical ledger is fictional and internally consistent; it is not a live Pipedrive test result. Use the same style of expected-operation ledger for your account, then compare it with the actual import and records. The useful asset is the explicit distinction between research enrichment and pipeline creation.
Add people only with reviewed identity and association
If the research includes a new person, confirm their identity, role, business contact information, and relationship to the organization. A name on a website may identify a former employee, an adviser, a customer testimonial, or a partner. The source must support the relationship you intend to store.
Prepare a separate person review with the source key, intended organization, existing person match if any, and allowed updates. Do not assume that a shared surname or a generic email address identifies the same person. If a contact already exists, use the reviewed native identifier and avoid creating another record merely because the source spells the name differently.
Keep person contactability and communication eligibility separate from company fit. A company can satisfy the campaign criteria while the available person is the wrong role or has a preference against contact. The import should preserve that distinction so an organization score does not automatically authorize a message to every associated person.
Separate fit from contact eligibility Use distinct record fields for company research, person relevance, preferences, and sales action.
Worked example: a person moves to a different organization
In this fictional case, a returned research file lists Morgan at Summit Systems, while the CRM has Morgan associated with an older employer, Alder Group. The email and public role evidence suggest a change, but the record also contains an active conversation tied to Alder. Automatically overwriting the organization field could make the history misleading.
The reviewer holds the row and asks the relationship owner to assess the evidence and current conversation. The team decides how its account model should preserve the historical association and represent the new role. It records the observation date and source rather than treating the move as an undated fact.
Only after that review does the operator apply the approved person and relationship update. Any planned outreach is reconsidered in the context of the new role and prior preferences. The example shows why a person record is more than a set of current contact fields: it is connected to relationship history that must remain interpretable.
Use a test set that covers relationships and update rules
Include a new organization, an existing organization update, a person update, a new person at an existing organization, a blank optional field, a duplicate candidate, a shared-domain company, and a protected preference. Write expected outcomes before import. A test using only new, complete records cannot reveal the update and association defects most likely to affect existing CRM data.
Follow the current Pipedrive import flow and inspect the mapping screen carefully. Confirm item types, System IDs, and custom fields. Review any preview or error information available, then inspect the resulting records directly. The import interface's successful completion is one piece of evidence, not the entire acceptance test.
Check downstream behavior. A newly populated field may trigger a workflow or change a filtered view used by a salesperson. Make sure the record remains in the intended review state until the owner accepts it. If the test causes an unintended action, correct that interaction and repeat the relevant case before the main import.
Compare the record before and after
Capture the approved baseline values for the test items, including owner, existing person association, and any protected preference. After import, compare those fields with the baseline and the expected change list. Mark each field as changed as intended, preserved as intended, or unexpected. This field-level comparison is more informative than a general note saying the test passed, and it gives the administrator a precise description if a mapping or automation needs repair.
Reconcile organizations, people, and commercial objects separately
Compare expected and actual organization creates, organization updates, person creates, person updates, relationship changes, holds, and failures. Also confirm that any lead or deal operations match the explicit scope. A batch intended only for enrichment should not quietly add pipeline inventory.
Keep a row-level ledger with source key, intended item type, native ID, result, and correction. If a subset fails, repair the subset rather than blindly rerunning the whole file. Repeated imports without controlled identifiers can create duplicate work or overwrite changes made after the first attempt.
Inspect successful records for meaning. A valid URL attached to the wrong organization may produce no import error. A numeric score can fit the field type while using the wrong scale. A person can exist with the correct email but the wrong organization relationship. These semantic checks require a reviewer who understands the research and the business process.
Troubleshoot the mapping instead of improvising values
If a field is unavailable during mapping, confirm the item type, field configuration, and permissions. Pipedrive's documentation notes that not every system field is editable through import. Do not map the value into an unrelated field simply to get it into the CRM. Decide whether an approved custom field or linked artifact is the appropriate destination.
If an existing item is not updated, inspect the System ID and the object it belongs to. Check for altered IDs, spreadsheet formatting, or a source key mistaken for a native identifier. If duplicates appear, trace the matching assumptions and the exact prepared file rather than editing names until the records look similar.
If the imported research seems to disappear, verify whether it was mapped to a different item, omitted, rejected, or overwritten by another process. Review the outcome ledger and record history where available. Preserve the original file and avoid multiple speculative reimports that make the sequence of changes harder to reconstruct.
References: Pipedrive: Import fields ↗
Agree the research delivery and customer responsibilities
If a supplier enriches an existing Pipedrive list, include the reviewed organization IDs needed for return mapping and state that those values must be preserved. Specify the company fields, evidence format, observation dates, score meaning, and desired brief links. Clarify whether people are in scope rather than assuming every company enrichment includes a new contact.
StackShortlist's own-list services do not guarantee new contacts. Stack leads includes fit scores; Company intelligence adds general company context, and Your-offer intelligence relates the research to the buyer's offer. Choose the depth according to the review decision the salesperson must make, not according to an assumption that only a higher tier supplies a score.
An emailed delivery or an agreed signed HTTPS webhook can feed a customer-configured process, but it does not imply a native Pipedrive connector. The customer remains responsible for field mapping, automation, idempotency, retry handling, permissions, and import acceptance. Make those responsibilities explicit during implementation planning.
Hand research to the responsible seller Ensure the owner accepts the context and next action after the data is reconciled.
Maintain the mapping as part of normal operations
Store the approved dictionary, source file, prepared file, test cases, outcome ledger, and corrections together. Record the account assumptions and the version of the mapping. The package should let another operator repeat the process without relying on the original person's memory.
Review the map when the team changes custom fields, owners, workflows, or its definition of a qualified lead. Retest the affected cases after a material change. Research imports are recurring interactions with a changing CRM, so a previously successful spreadsheet is a starting point for review rather than permanent proof of correctness.
- Organization research and person details map to the correct item types.
- Native System IDs remain unchanged and distinct from source keys.
- Research scores retain their scale, criteria, and observation context.
- Protected fields and relationship history survive updates.
- Test cases cover new items, existing items, blanks, duplicates, and associations.
- The final ledger explains every create, update, hold, failure, and unintended action.
Common questions
Should a researched company automatically become a deal?
No. Company research can support review and prioritization without establishing a commercial project. Create or advance a deal only through the team's defined qualification process. Keep research fit separate from deal value, stage, and expected close date.
Can the same ID column update organizations and people?
Each item has its own native identifier. Keep organization and person System IDs in separate columns and map each to the correct item type. Preserve source supplier keys separately so they cannot be mistaken for Pipedrive IDs.
Where should a detailed company dossier go?
Use a suitable linked brief or approved narrative location, with concise organization fields for sorting and review. Preserve the brief version and observation date. Avoid copying the full dossier into multiple person records where it can become inconsistent.
What if a contact has changed companies?
Hold the update for relationship review. Confirm the evidence, preserve relevant history and preferences, and apply the organization's approved model for the changed role. Do not let a delayed research file silently rewrite the context of an active conversation.
Does a successful import mean the batch is ready for outreach?
No. Reconcile object operations, inspect associations and protected fields, then have the responsible owner review fit and communication eligibility. Technical import completion is separate from data acceptance and permission to act on the record.
Sources & further reading
Primary references support the technical details. Worked examples are illustrative; workflows and checklists are practical methods to adapt to your own process.
Something changed? Tell the editorial team.