Model send-on-behalf workflows for CRM and ATS products

An accountable delegation design for professional messaging that keeps the sender, customer purpose, approval, provider outcome, and candidate or contact record explicit.

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

Talk to us ↗Read technical guides →

Delegation

On behalf of must name a real acting user

A CRM or ATS application is not the professional identity that sends a message. Every proposed command must resolve to one connected account, one authenticated customer user allowed to act for it, and one business context. Shared credentials or a workspace-wide sender obscure accountability. DewEngine's LinkedIn message target is decision-gated, so this delegation model is educational until lawful access and provider authorization are established.

Display the sender account before approval
Reject commands whose workspace user cannot control that account

Record ownership

Keep CRM contacts and ATS candidates in their source system

The customer application should remain authoritative for contact identity, candidate stage, requisition, relationship owner, consent, and suppression. A connector needs only opaque external references required to return conversation state to the right record. Copying the entire candidate or sales record into the messaging layer increases privacy exposure and risks letting a connector become a hidden hiring or sales-decision engine.

Pass minimal purpose and record references with the draft
Never let a message result advance or reject a candidate automatically

Approval

Bind approval to recipient, sender, and content version

Approval should cover the exact message text, attachments if ever supported, recipient identity, acting account, and reason. Editing any of those invalidates the approval. Templates can assist composition, but placeholder expansion must be visible before authorization. For sensitive recruiting or sales outreach, the reviewer should also see recent conversation and whether another team member already owns the relationship.

Store who approved which immutable content hash
Expire approval when context or account health materially changes

Command truth

Separate eligibility from provider acknowledgement

Passing customer policy only means the command may attempt dispatch. Persist an idempotency key and pre-dispatch state, then classify provider acknowledgement, definite rejection, retryable pre-dispatch failure, or indeterminate outcome. An HTTP timeout after the action may mean the provider accepted it. Automatic retries in that state can duplicate a candidate or prospect message and must be fenced.

Return a durable command ID to the CRM or ATS
Reconcile unknown outcomes through an approved read path before retry

Inbound loop

Return replies without leaking other conversations

A reply needs account-scoped conversation mapping and tenant-safe external references. The customer application should receive only events it is entitled to associate with its record, not the sender's entire inbox. A response can pause scheduled follow-ups and create a human task, while the original message stays visible for correction. Candidate-data retention and deletion rules remain owned by the ATS context.

Filter events by workspace, account, and linked record
Pause incompatible automation when a person replies

Acceptance

Test identity substitution and stale approvals

The release suite must reject cross-tenant account IDs, reassigned records, departed recruiters, changed message bodies, duplicate idempotency keys, revoked sessions, suppression races, and late replies. It must also prove deletion, audit, conservative action budgets, and a global kill switch. None of those controls clears the separate legal and provider gate; both authorization and conformance are required before sale.

Attempt every sender and recipient substitution across tenants
Verify one approval can produce at most one provider-visible attempt

Questions

Before you build.

Can a CRM service account be treated as the LinkedIn sender?+

No. The product should identify the actual connected professional account and the customer user authorized to act for it. A backend credential can authenticate the CRM to DewEngine, but it must not erase human sender accountability.

What should the ATS store after a message command?+

Store the opaque connector account and command references, the approved content version, relevant candidate or requisition reference, and the truthful outcome state. Do not store provider authorization material or infer recipient delivery from submission alone.

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 ↗