A partner-ready lead record is not a CRM export. It is a deliberately limited decision packet: enough verified context for an eligible partner to evaluate fit, understand provenance, and take ownership—without exposing every note, personal detail, or seller inference collected during the original relationship.
Partner Connector’s public lead preview pattern masks company and job-title details before an authenticated purchase flow. This guide extends that principle into a two-layer operating model. It does not claim that the same fields are lawful or necessary for every marketplace, jurisdiction, or transfer purpose.
Organize the record around the buyer’s decisions
A buyer needs to answer a sequence of questions:
- Is this type of opportunity potentially relevant?
- Is the seller’s evidence current and understandable?
- What becomes available after an authorized acceptance?
- Who owns contact, suppression, and dispute handling?
- What result must be reported back?
Fields that do not help one of those decisions need a separate justification. “It exists in HubSpot” is not a purpose.
Layer 1: marketplace preview
The preview helps an eligible buyer decide whether to continue without disclosing direct identifiers. Depending on the marketplace policy, it may include:
- masked company or contact label;
- broad industry, company-size, and geography bands;
- general role or seniority band rather than a unique title;
- service-interest category;
- qualification and non-fit reason categories;
- age or freshness band;
- seller verification state and listing terms.
Preview fields should resist re-identification. A rare title, narrow location, exact employee count, and dated public trigger can identify a person when combined even if the name and email are hidden.
Layer 2: acceptance packet
After the buyer is eligible, the transaction or handoff is authorized, and ownership rules are satisfied, the acceptance packet may add the information required to act:
| Field group | Buyer question | Control |
|---|---|---|
| Identity and channel | Who may be contacted, through which verified route? | Access event, buyer identity, suppression check. |
| Need and context | What did the prospect state, and when? | Source, timestamp, exact statement versus summary. |
| Qualification | Which written criteria were met? | Rule version, evidence, missing fields. |
| Non-fit reason | Why did the seller decline while preserving qualification? | Specific category and dated seller judgment. |
| Ownership | What must the seller and buyer do next? | Transfer time, contact window, stop events. |
Do not release data merely because payment succeeded. Eligibility, policy, access logging, and current suppression state remain separate gates.
Separate facts, statements, and inferences
Use visible labels throughout the record:
- Fact: “Company website lists offices in London and Dublin,” with source and date.
- Prospect statement: “Exploring an outbound program next quarter,” with interaction date and context.
- Seller inference: “Likely needs a specialist agency,” with owner and confidence.
Never silently convert an inference into a fact. A buyer should be able to accept the evidence and reject the seller’s interpretation.
Make non-fit reasons useful
“Bad fit” is not operational. Use specific reason categories such as service mismatch, geography, budget-model mismatch, capacity, industry restriction, timing, conflict, or qualification failure. Keep qualification failure separate: a record that never met the rule should not enter the same inventory as a qualified opportunity that belongs elsewhere.
Allow a concise explanation, but do not use free-form notes as a place for sensitive opinions, protected traits, or irrelevant personal information.
Add provenance and freshness
Every material field should carry:
- source system or interaction;
- captured-at date;
- last verified date;
- owner or responsible team;
- transformation history where a value was normalized or inferred;
- expiry or revalidation rule.
Freshness should be field-specific. A company industry may remain useful longer than an active project date, role, or contact preference.
Define what must never enter the packet
Default exclusions should include secrets, passwords, authentication tokens, payment data, special-category or highly sensitive personal data, private internal commentary, unrelated communications, unapproved call recordings, and attributes unnecessary for the buyer’s stated purpose. Also exclude hidden tracking or enrichment fields the buyer cannot explain.
The safest transfer field is the field the buyer does not need.
Reusable readiness template
- Opportunity: category, geography band, company band, verified need, evidence date.
- Qualification: rule version, passed criteria, missing criteria, reviewer.
- Seller fit: specific non-fit reason, decision date, current owner.
- Preview: masked fields, re-identification review, eligibility rule.
- Acceptance: released fields, lawful/policy review, access log.
- Ownership: transfer time, contact window, reply and objection routing.
- Outcome: accepted, rejected, contacted, meeting, qualified outcome, dispute.
Validate with accept and reject reasons
After launch, review what buyers could and could not decide. If many buyers reject because a critical field is missing, assess whether that field is necessary and safe to add. If a field is rarely used, remove it. If buyers consistently disagree with seller inferences, improve the qualification language rather than hiding the disagreement inside a score.
Sources and next step
This template applies the UK ICO’s official guidance on data minimisation and the NIST Privacy Framework. It is a product and operations framework, not a legal determination for a particular transfer.
Before syncing the packet from a CRM, complete the HubSpot marketplace ownership and sync checklist.