Planned capability

CRM product engineering

Embed customer conversations with source and account intact

Plan a CRM integration that places authorized provider activity beside contacts, companies, and opportunities while keeping communication state traceable to its native account. DewEngine should remove repeated connector engineering, but the CRM remains responsible for customer identity, ownership, permissions, consent, workflow, retention, and sales or service decisions.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Planned boundary

No embedded CRM communication layer is released

This CRM publisher use case is planned and not callable. DewEngine has no customer-ready contact timeline, mailbox sync, messaging inbox, profile lookup, account widget, CRM package, or provider action available to embed.

Current evidence: The development control plane persists workspaces, API keys, account metadata, commands, events, and webhook delivery, plus a narrow Calendar path. It does not implement CRM tenant delegation, contact and company resources, conversation synchronization, Gmail, messaging, enrichment, or released UI components.
Target contract: Connect user-owned provider accounts under the CRM customer's tenant and return opaque account lifecycle state without exposing authorization material; Deliver versioned communication resources and events that retain provider lineage while the CRM controls contact and company association; Execute a write only after both CRM business permission and current provider-account capability pass, with truthful asynchronous outcome
Known limits: DewEngine will not guarantee that an address or profile maps to the intended CRM contact, infer opportunity meaning, or decide who owns a relationship; Shared mailboxes, duplicate contacts, merged companies, provider gaps, consent changes, retention, and regional communication law require CRM-level policy
Release gates: Add publisher applications, delegated users, environment separation, scoped account grants, and customer-safe authorization callbacks; Release chosen mail and messaging connectors with sync cursors, replies, edits, deletion, health, retirement, and webhook evidence; Prove contact-association review, merge handling, suppression, ownership transfer, export, and deletion in representative CRM journeys

CRM boundary

Keep the relationship graph in the customer product

A CRM understands accounts, contacts, leads, opportunities, cases, owners, territories, and custom permissions that a communication API should not duplicate. DewEngine can return source identities and activity with opaque correlation. The CRM decides where that activity appears and whether a suggested association is accepted, rejected, or later corrected.

Treat CRM record links as versioned application metadata
Preserve the original provider participant after a contact merge

Implementation onboarding

Connect accounts under the CRM's authenticated user

The CRM begins a short-lived authorization flow from its server and binds the returned DewEngine account to the current tenant and user. Team visibility is then granted through CRM roles rather than provider credential sharing. Disconnect, employee departure, and workspace deletion must fence queued work before the underlying authorization is retired.

Do not trust browser-supplied tenant or owner identifiers
Separate connection ownership from colleagues allowed to view a timeline

Timeline projection

Ingest once, present under CRM rules

A provider observation becomes a DewEngine resource and canonical event before the CRM projects it. The CRM deduplicates by event ID, fetches current state when necessary, and applies record visibility. Edits or deletion tombstones update the presentation without making a past business decision disappear from the appropriate audit history.

Store source timestamps separately from CRM ingestion time
Do not equate webhook delivery order with conversation order

Action policy

Make the correct acting account explicit

Before a user replies or schedules, the CRM presents the account identity, native thread, recipients, content, ownership rule, and suppression result. DewEngine checks capability and health again at dispatch. This prevents a convenient shared timeline from sending through a colleague's account or continuing after an opt-out or ownership transfer.

Bind approval to the exact recipient and content version
Reject an action when its CRM record association no longer resolves

Publisher proof

Test messy customer data before shipping a clean demo

Conformance needs duplicate leads, shared addresses, personal and team mailboxes, merged contacts, reassigned owners, deleted companies, delayed replies, provider edits, stale cursors, and disconnected accounts. A publisher support team should trace one activity across CRM projection, DewEngine event, connector observation, and provider outcome without viewing unrelated tenant data.

Verify correction and unlinking without corrupting source history
Exercise tenant boundaries during support impersonation and export

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapePlanned · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No live connector · no provider request

Questions

Before you build.

Will DewEngine replace a CRM's contact-matching logic?+

No. It can preserve provider identifiers and future matching evidence, but the CRM owns its relationship graph and merge rules. Ambiguous associations should remain reviewable and reversible.

Can every CRM user reply through every connected account?+

No. The CRM must grant business access and DewEngine must confirm account ownership and provider capability. Shared visibility does not imply permission to perform a provider-visible action.

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 ↗