Planned capability

Conversation workspace

Unify the operator's view without flattening channel truth

Plan an inbox that places mail and conversations beside the customer or candidate record while preserving the exact account, provider thread, participants, and action constraints. A shared interface should reduce context switching without pretending that every channel has identical identity, ordering, reply, media, or deletion semantics.

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

Talk to us ↗Read technical guides →

Planned boundary

The unified inbox resource layer does not exist yet

This cross-channel inbox is planned and not callable. The repository does not implement mailbox synchronization, messaging conversation storage, attachments, participant resolution, reply actions, or a customer inbox UI.

Current evidence: The control plane has connected-account lifecycle records, command and event primitives, and signed webhook delivery. The architecture sketches conversations, messages, mailboxes, email threads, attachments, and attendee identities, but those tables and connector projectors remain target design.
Target contract: Store each item under its originating connected account and native thread while exposing a stable DewEngine resource identifier; Project provider edits, deletes, reactions, receipts, and mailbox changes as explicit versioned state rather than rewriting history invisibly; Offer application-controlled associations between channel participants and CRM or ATS records with provenance and review
Known limits: One person can use several addresses, profiles, phone numbers, or shared inboxes, so cross-channel matching cannot be guaranteed automatically; Provider history depth, media access, message windows, deletion semantics, notification coverage, and ordering differ and may leave documented gaps
Release gates: Release authorized read and reply connectors with backfill, incremental sync, cursor recovery, and edit/delete conformance; Add object storage, malware scanning, bounded media retention, export, correction, and deletion workflows; Prove account-scoped ordering, participant mapping review, unread behavior, and duplicate-event handling in realistic inbox fixtures

Inbox model

Keep native threads as the durable backbone

The shared view can group related activity around an application contact, but it should not merge two provider threads into one mutable record. Each message or email retains its native parent, connected account, sender identity, timestamp provenance, and provider version. A presentation layer can then build a timeline without destroying reply context.

Reply through the account and native thread that received the item
Represent application contact links as reviewable associations

Implementation pipeline

Backfill before relying on notifications

A connector first discovers the authorized folders or conversations, imports a bounded history, stores a provider cursor, and then processes incremental observations. Notifications should wake synchronization rather than become the only source of truth. Cursor expiry or an unexplained gap triggers a scoped reconciliation instead of silently marking the inbox current.

Track last successful provider read per account and collection
Make a full resync an explicit, observable recovery state

Identity handling

Let matching remain evidence, not certainty

Exact provider participant IDs and verified email addresses are strong keys inside their source, while names and phone formatting are weaker hints across sources. The consuming product can suggest a CRM or candidate association and record who accepted it. Shared mailboxes and group conversations require multiple participants, roles, and acting-account identity.

Never key a person solely by display name
Keep shared-account senders distinct from the represented organization

Interaction limits

Render unsupported actions as unavailable

A channel may permit reply but not edit, expose read receipts only for some messages, limit attachment download, or apply a conversation window. The resource capability attached to the account should drive each interface control. A disabled action needs a specific reason so users do not retry a provider restriction as if it were downtime.

Calculate actions from account and resource capability together
Preserve provider-specific states that have no honest common equivalent

Operational gate

Measure freshness before promising one inbox

Operators need per-account sync lag, cursor health, failed media fetches, unresolved identity matches, and reply outcome state. Release testing must include high-volume threads, edits during backfill, duplicate notifications, lost cursors, disconnected accounts, and data retirement. A polished timeline without those recovery paths would be a cache, not a dependable inbox.

Show last confirmed source time beside degraded accounts
Prevent one failing connector from blocking unrelated account updates

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 a unified inbox merge every identity into one contact automatically?+

No. The intended model preserves provider identities and offers evidence for an application-controlled association. Ambiguous names, shared addresses, group threads, and recycled phone numbers need review instead of an irreversible automatic merge.

Can every channel action appear as the same inbox button?+

Only when the connected account and specific resource permit equivalent behavior. Unsupported reply, edit, reaction, media, or deletion actions should stay disabled with a provider-grounded reason rather than being simulated.

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 ↗