LinkedIn
Decision-gated
LinkedIn engineering guide

Design enrichment as evidence, not an outreach shortcut

A governance guide for combining authorized professional observations with customer records while preserving provenance, uncertainty, correction, and contact permission.

Educational research only. LinkedIn account access remains decision-gated. No DewEngine LinkedIn connector is approved or implemented.
01
Purpose

Name the decision each enrichment supports

Enrichment can help a user resolve a company match, notice a stale role, or add research context. It should not mean copying every visible attribute into a permanent profile. DewEngine's LinkedIn resources are decision-gated targets with no connector. Define field-level purpose and an alternative authorized source before choosing any provider access method.

  • Remove fields that do not alter a user decision
  • Keep enrichment useful without enabling messaging
02
Source layers

Keep observed, customer-confirmed, and derived data apart

A provider observation, a CRM user's correction, and a model-generated segment should retain distinct provenance. The current customer view may combine them according to field ownership, but the underlying evidence should remain inspectable. This prevents an inferred seniority or guessed company match from appearing as a statement by the professional and allows recalculation when transformation rules change.

  • Version every derivation and matching rule
  • Show source and freshness beside proposed updates
03
Entity matching

Use suggestions for ambiguous identities

Names, roles, companies, and URLs can be stale or duplicated. A matching service can propose links using provider-scoped identifiers and customer-known evidence, but it should not merge uncertain people automatically. A bad merge can expose conversations, contaminate analytics, and send outreach under the wrong context. Support accept, reject, unlink, split, and review history within each tenant.

  • Require stronger evidence for destructive merges
  • Never use another tenant's identity association as proof
04
Freshness policy

Refresh according to business need and account health

Different fields age differently. A research note may remain useful while current role context becomes stale. Use per-field observation time and a purpose-based refresh policy rather than continuous broad collection. When authorization or entitlement is lost, stop retrieval, retain permitted last-known evidence with a stale marker, and avoid treating inaccessibility as a blank profile.

  • Budget refreshes per account and data class
  • Let users request a targeted refresh after reviewing stale context
05
Outreach firewall

Enriched data does not grant contact permission

An updated role or company can make a draft more accurate, but it does not establish lawful outreach, consent, recipient preference, sender ownership, or provider eligibility. Campaign admission must independently check suppression, current conversation, customer policy, and human approval. Keep enrichment completion from triggering invitations or messages, and log the explicit decision that crosses into action.

  • Do not score professional visibility as intent
  • Cancel queued contact when corrected identity breaks eligibility
06
Proof and rights

Test correction and deletion as first-class flows

Release depends on legal and provider authorization, minimized schemas, consented real-account fixtures, tenant isolation, matching accuracy, partial data, account restriction, retention, subject access, correction, export, deletion, audit, and kill switches. Secondary analytics or model training need separate approval. If LinkedIn's gate never clears, the enrichment system should accept customer-owned or licensed evidence instead.

  • Trace downstream copies from one source observation
  • Measure false matches and successful reversals
Questions

Before you build.

Does a new job title justify contacting someone again?+

No. It may justify a human review of CRM context, but outreach eligibility still depends on purpose, prior interaction, suppression, sender authority, and the approved provider action path.

Should enrichment overwrite a customer's verified field?+

Usually it should propose a change with source and freshness. Field-level ownership rules can automate low-risk updates, but customer-confirmed values and ambiguous conflicts need reversible handling rather than silent replacement.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case