Define a company-inbox workflow before claiming one exists

A product model for company identity, team assignment, conversation scope, response controls, and support evidence without inventing a LinkedIn company inbox API.

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

Talk to us ↗Read technical guides →

Capability check

Company inbox is not in the current DewEngine contract

The LinkedIn target catalog includes companies, chats, messages, and message.send, but it does not define a distinct company-inbox resource, page-admin authorization, assignment model, or company-message event. Combining nearby nouns would create a false capability claim. This route therefore explains the questions a product team must answer while all LinkedIn account access remains decision-gated and unimplemented.

Do not infer a page inbox from generic chat resources
Add a capability only after exact provider and entitlement evidence

Acting identity

Distinguish the company presence from the human operator

A business communication product must show which organization identity appears to the recipient, which connected account or page relationship authorizes it, and which employee performs the work. Company administrators, inbox agents, and general workspace members may have different rights. A backend key must never flatten those roles or let one tenant impersonate another company.

Display both external sender identity and internal operator
Revoke access promptly when an admin role changes

Conversation ownership

Assign work without changing provider truth

Internal states such as assigned, waiting, escalated, or resolved belong to the customer workspace. Provider observations such as message direction and timestamp remain separate. This allows teams to coordinate without pretending that an internal resolution changed the provider thread. Transfers should preserve history and visibility rules, and private notes must never be sent as replies or included in provider payloads.

Keep internal notes outside message bodies
Audit assignment and response ownership changes

Response control

Bind replies to current company authority

Before a reply, recheck operator role, company identity, conversation mapping, recipient context, account health, and the exact approved method. Use idempotent commands and preserve acknowledged, rejected, and indeterminate outcomes. A saved reply or automation rule cannot survive loss of page entitlement. Incoming messages should pause conflicting scheduled replies and route to a responsible human.

Expire drafts after sender authority changes
Do not automatically retry an ambiguous response

Service operations

Measure responsiveness without claiming provider delivery

A team can measure assignment delay, first human action, unresolved age, and internal service targets from its own event ledger. It should not claim recipient delivery, read state, or provider availability without direct evidence. Support tooling needs sanitized account and conversation identifiers, last observation time, sync coverage, and failure class rather than broad access to business messages.

Separate internal SLA clocks from provider timestamps
Protect message content from general analytics and logs

Decision package

Verify the actual company messaging product

Release would require an authorized provider contract, exact page or company entitlement, admin and operator role tests, inbound and outbound fixtures, identity display validation, reconnect and restriction handling, tenant isolation, retention, deletion, audit, action budgets, and kill switches. If no such authorized surface is selected, DewEngine must keep company inbox language educational and omit it from released API documentation.

Test admin removal during an active conversation
Document unsupported company types and message states

Questions

Before you build.

Does the presence of companies and chats in the catalog prove a company inbox?+

No. Those target resources do not define who can act as a company, which conversations are visible, or which messages are supported. A separate provider contract and conformance matrix are required.

Where should team assignment state live?+

In the customer's workspace or CRM, linked to an opaque conversation reference. Keep assignment and resolution separate from provider facts so internal workflow changes cannot distort the external thread.

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 ↗