Specify Sales Navigator search features at capability granularity

A feature-selection guide for people and company searches, lists, entitlement, pagination, review, and CRM handoff without assuming a provider contract.

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

Talk to us ↗Read technical guides →

Product gate

Select the entitled Sales Navigator contract first

Search features are meaningful only for the exact product and account allowed to use them. DewEngine has no approved Sales Navigator connector. The platform plan requires subscription and contract validation, search and list entitlement tests, InMail credit accuracy where applicable, and action-specific limits in addition to the broader LinkedIn legal and provider gate.

Identify the account product in capability discovery
Do not inherit features from another LinkedIn variant

People versus companies

Use separate query and result contracts

A people search resolves professional candidates; a company search resolves organizations and account context. Their filters, identifiers, review decisions, and CRM destinations differ. Do not combine them into an untyped result array. Shared pagination metadata can be normalized, while provider-specific filter facets and product extensions remain explicit and versioned.

Require a declared result type for each saved search
Keep company matching separate from person matching

Saved work

Model lists as account-scoped observations

Lead or account list membership can help a seller resume research, but it is not CRM ownership, campaign eligibility, or a global fact. Namespace lists by connected account and record observed membership over time. If a list becomes inaccessible, preserve the last confirmed customer association under policy without claiming it remains current or deleting the CRM entity.

Store list mappings with source and observation time
Keep provider list changes from rewriting pipeline stages

Pagination and limits

Design for bounded, partial search

An approved adapter would need to document filters, cursors, page behavior, result ordering, and any provider feedback for the entitled product. Persist each accepted page, deduplicate resources, and expose incomplete coverage. Internal budgets should prevent runaway saved-search refreshes and coordinate across workers. They must not claim to be provider quotas unless direct evidence supports the number.

Resume from durable query progress
Stop on entitlement change, challenge, or restriction

Review workflow

Turn results into evidence-backed candidates

The editor should show why each person or company appeared, what fields were observed, and which customer record may match. Users can accept, dismiss, annotate, or assign without triggering an invitation or InMail. That separation lets the team measure precision and correction while protecting recipient choice and preventing search from becoming an implicit bulk-contact engine.

Require separate approval for every provider-visible action
Preserve rejection reasons to reduce repeated noise

Conformance plan

Prove filters, lists, and entitlements independently

Tests must cover each advertised operator, people and company result schemas, account-scoped lists, pagination, reordered results, subscription downgrade, permission loss, throttling, tenant substitution, retention, correction, and deletion. Provider authorization, counsel review, consented real-account evidence, support redaction, and kill switches remain mandatory. The narrowest proven feature set should drive documentation automatically.

Maintain fixtures for eligible and ineligible subscriptions
Reject unsupported facets with a stable error

Questions

Before you build.

Should people and company searches share one result schema?+

They can share envelope concepts such as cursor, source account, and observed time, but the resources and matching semantics differ. Typed result variants prevent company and person data from being confused downstream.

Does adding a lead to a Sales Navigator list authorize an InMail?+

No. List membership is research context. Contact requires a separate entitlement check, customer purpose, sender authority, recipient safeguards, approval, budget, and truthful action outcome.

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 ↗

Specify Sales Navigator search features at capability granularity

Select the entitled Sales Navigator contract first

Use separate query and result contracts

Model lists as account-scoped observations

Design for bounded, partial search

Turn results into evidence-backed candidates

Prove filters, lists, and entitlements independently

Before you build.

Related guides

Evaluate company search for an authorized LinkedIn product

Replace the company-scraper idea with a lawful CRM intake design

Design a governed lead-intake workflow without automated extraction

Does this match the workflow your users need?