Design a profile retrieval contract around partial, authorized data

An engineering guide to profile identity, field provenance, account scope, refresh, correction, and privacy without claiming a full-profile extraction API.

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

Talk to us ↗Read technical guides →

Resource definition

A profile is an observation, not a universal person record

The same professional may have customer-entered details, provider observations, and derived CRM context. Keep those sources separate. DewEngine's target includes profile.get, but the LinkedIn adapter is neither approved nor implemented. Any future response would need to identify the connected account, provider-scoped profile ID, observed time, eligible product, returned fields, and coverage rather than promise a complete person.

Use opaque internal IDs outside the adapter boundary
Never treat name or profile URL as a guaranteed immutable key

Authorization

Validate why this account may retrieve this profile

A customer-supplied URL does not prove that a connector is allowed to resolve or copy its contents. Check the approved provider contract, account entitlement, workspace role, product purpose, and requested field set. Do not fall back to page scraping, private endpoint replay, or session bypass. If authorization is missing, return a gated result without touching the provider.

Attach purpose to the read request
Reject cross-tenant or cross-account identifier substitution

Schema design

Represent optional and derived fields explicitly

Names, headline-like text, company context, locations, and other attributes may be partial or absent under a future contract. Use optional fields and typed source metadata. A normalized seniority label or company match belongs in a derived layer with its own version and confidence. Do not invent an email, phone number, or demographic attribute from profile text or return it as provider data.

Distinguish not requested, unavailable, and truly absent
Keep inference outside the provider observation object

Refresh

Protect customer edits from observation churn

Refreshing a profile creates a new observation; it should not blindly overwrite curated CRM fields. Compare versions, apply field-level ownership, and show conflicts for review. A changed employer can be useful context while leaving account ownership and relationship history untouched. If access fails, retain the last confirmed projection with a stale marker instead of clearing the record.

Store observed-at and last-confirmed timestamps
Make every automated update reversible

Privacy

Limit copies and secondary use

Professional profiles can contain personal data. Collect only fields needed for the stated feature, restrict access by workspace role, encrypt authorization material, redact logs, and set retention. Search indexing, model training, enrichment, or export are separate uses requiring separate decisions. A deletion workflow must traverse normalized records, raw observations, caches, exports, and backups according to policy.

Audit access to sensitive profile context
Support correction and unlink without destroying unrelated CRM history

Conformance

Test the exact meaning of every advertised field

Before release, field fixtures and consented real-account smoke tests must cover eligible and ineligible accounts, partial responses, redaction, wrong identifiers, changed profiles, throttling, revoked sessions, restriction, tenant isolation, retention, and deletion. Legal and provider approval remain prerequisites. The phrase full profile should not appear in a product promise unless a versioned contract defines and proves it.

Publish unsupported fields and product variants
Expire claims when the provider contract or fixture changes

Questions

Before you build.

Can profile.get be considered an implemented DewEngine method?+

No. It appears only in the target LinkedIn capability catalog. The provider is decision-gated and has no implementation, conformance evidence, or released account connection.

How should a CRM handle a profile employer that conflicts with its contact record?+

Create a source-attributed proposal or additional historical observation. Do not erase the CRM's curated value automatically. Let a user review the evidence and retain the resolution so later refreshes remain explainable.

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 ↗