Resolve LinkedIn identifiers without creating a global identity key

A data-model guide to source-scoped IDs, URL and name hints, tenant isolation, aliases, merges, and deletion for a profile lookup that is not implemented.

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

Talk to us ↗Read technical guides →

Current truth

DewEngine cannot resolve a LinkedIn ID today

The target catalog includes profiles and profile.get, but no LinkedIn connector, lookup contract, or approved account access exists. A route title is not an endpoint. Applications should not scrape a profile page, inspect private traffic, or bypass access controls to discover an identifier. Use customer-supplied references as unverified hints until an authorized resolver is selected and proven.

Expose the method as policy-gated or unavailable
Keep manual linking usable without provider resolution

Identity semantics

Namespace the identifier by provider and account

An external identifier should be stored with provider, connected account or verified product scope, resource type, first and last observation, and source. DewEngine can issue its own opaque immutable ID to customers. This prevents downstream code from assuming a provider value is globally portable, public, or stable across entitlements and allows mappings to change without breaking the host application's keys.

Never use a display slug as the database primary key
Reject resource IDs presented under another account

Resolution input

Treat names and URLs as candidate locators

A name can match many people, and a URL can change, redirect, be mistyped, or point to the wrong subject. An approved lookup would return candidate evidence and confidence rather than silently attaching the first result. User confirmation, customer-known contact data, company context, and prior provider mappings can support a match within one tenant. None should leak across customers.

Show competing candidates for ambiguous inputs
Retain who confirmed the selected mapping

Alias lifecycle

Support changed references without rewriting history

Keep alias observations and validity times so old CRM links remain explainable. If a source identifier is replaced or a duplicate is resolved, create an explicit supersession or merge record and preserve reversibility. A failed lookup must not delete the mapping; it may reflect revoked access, entitlement, or temporary provider failure rather than an identity change.

Distinguish unresolved, inaccessible, superseded, and deleted
Make merge and split operations tenant-local

Privacy boundary

An identifier is still personal-data infrastructure

Stable identifiers can enable correlation across datasets even when they contain no readable profile text. Restrict access, log lookups without unnecessary content, minimize exports, and define retention. Avoid building a global identity graph from different customers' observations. Subject access, correction, and deletion need to find aliases and downstream links without exposing other tenants' associations.

Treat bulk ID resolution as a separate high-risk purpose
Do not expose raw provider identifiers where opaque IDs suffice

Evidence plan

Prove identifier scope and ambiguity

A future resolver needs legal and provider authorization, eligible-account conformance, exact accepted inputs, changed URL fixtures, homonyms, missing profiles, account restriction, throttling, cross-account and tenant substitution, merge reversal, retention, and deletion tests. Documentation must say whether an ID is stable and where it is valid based on evidence, not assumption. Until then, no DewEngine ID lookup should be advertised.

Test intentionally ambiguous names and stale URLs
Expire mappings when their retention purpose ends

Questions

Before you build.

Can a LinkedIn profile URL serve as a permanent person identifier?+

No. Treat it as a mutable source reference. Use a tenant-owned person ID, retain provider mappings and aliases with provenance, and support correction when the URL changes or identifies the wrong subject.

Why scope a provider ID to the connected account?+

Visibility and meaning can depend on the observing account and product entitlement. Account scope prevents unsafe global assumptions, cross-tenant leakage, and accidental use of a cursor or identity outside its authorized context.

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 ↗