01
Product boundary
Generate assistance, not automatic authority
Software can assemble context, suggest a draft, and identify missing information. It cannot decide that a professional account may contact a person. The LinkedIn message surface in DewEngine is decision-gated and unimplemented. Any future workflow needs an approved access contract, a lawful customer purpose, explicit sender authority, and a recipient eligibility check that automation cannot bypass.
- Let users decline a suggestion without penalty
- Keep draft generation available even when provider sending is disabled
02
Context quality
Use only attributable personalization inputs
A person's confirmed company, an existing CRM relationship, and a recent customer-owned conversation can be useful context. Inferred email, guessed interests, sensitive traits, or stale role data should not enter copy as facts. Each variable needs a source and observed time. If evidence conflicts or is missing, omit the claim instead of creating false familiarity.
- Show source context beside the generated sentence
- Block unverified claims about prior contact or shared experience
03
Template design
Separate stable intent from recipient-specific wording
Store the campaign purpose, sender, requested response, and prohibited claims as a controlled brief. The generated or templated text is a versioned artifact for one recipient. This separation lets reviewers see whether personalization changed the meaning. It also prevents a harmless template label from approving content that a later model or placeholder expansion materially altered.
- Version the prompt, inputs, output, and human edits
- Require new approval after any material regeneration
04
Approval interface
Show the message in its conversation context
Before authorization, display the final content, acting account, recipient identity, relationship state, recent relevant messages, suppression, and ownership. The user should be able to edit, skip, or reassign. A draft prepared yesterday may be obsolete after a reply or colleague action, so execution must re-evaluate eligibility and invalidate stale approvals when context changes.
- Place the send decision beside the evidence it depends on
- Cancel queued drafts after recipient or sender identity changes
05
Execution truth
Keep content quality separate from delivery state
A polished draft says nothing about whether the provider accepted it. Use an idempotent durable command and distinct acknowledged, rejected, throttled, and indeterminate outcomes. Do not tell the CRM that a message was delivered or read without direct approved evidence. Replies should stop incompatible follow-ups and route to the responsible person rather than feed an endless generation loop.
- Never automatically resend after an ambiguous timeout
- Make manual cancellation win against queued work
06
Review checklist
Test factuality, restraint, and lifecycle failure
A future release would need provider and legal approval, consented account conformance, factuality review, sensitive-data filters, sender and recipient substitution tests, stale-context invalidation, suppression races, idempotency, account restriction, deletion, action budgets, and kill switches. Metrics should include edit and rejection rates, not merely send volume. This educational guide does not represent an active LinkedIn feature.
- Audit samples for fabricated familiarity
- Prove a revoked account cannot execute an approved draft