Design invitation workflows with explicit human intent

A careful model for relationship invitations, eligibility, notes, pacing, outcomes, and acceptance events that rejects unauthorized or evasive automation.

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

Talk to us ↗Read technical guides →

Relationship action

An invitation changes social state

An invitation is not a harmless database write. It acts through a person's professional identity and asks another person to change a relationship. DewEngine lists invitation.send and relation.accepted only as decision-gated targets. No automation should proceed without an approved provider path, lawful customer purpose, account-owner authority, and a design that leaves the final decision visible and accountable.

Require the acting account and recipient to be shown together
Never turn a search result into an invitation automatically

Eligibility

Check context immediately before approval

The recipient may already be related, have a pending invitation, be suppressed, belong to another owner's workflow, or have declined earlier contact. A stale sequence step cannot decide safely. Re-read customer records, relation observations, account health, purpose, and applicable policy at action time. Unknown state should pause the invitation rather than encourage another attempt.

Deduplicate by account and provider-scoped recipient
Honor manual suppression and prior negative outcomes

Invitation note

Approve exactly what the recipient will see

If an approved contract supports a note, render the final text after personalization and validate it against the actual account capability. Do not assume a note, length, or field merely because another product variant offers one. Bind approval to the content version. Generated text must not fabricate familiarity, employment, or prior conversation, and users need an easy way to edit or decline it.

Show every substituted value before authorization
Return unsupported rather than dropping a note silently

Pacing controls

Budget relationship actions conservatively

Per-account and per-action budgets should account for user-approved activity across all workers. Provider feedback, challenge, restriction, or entitlement uncertainty must stop the queue. Delays designed to imitate human behavior are not an acceptable control. Transparent limits, approval expiration, audit, and a kill switch protect the account more honestly than randomness or distributed evasion.

Reserve budget atomically before a provider attempt
Release or consume reservations according to truthful outcome

State machine

Keep sent, pending, accepted, and unknown distinct

Persist the invitation command before dispatch and distinguish provider acknowledgement from later relationship acceptance. A timeout can leave the send outcome indeterminate; do not retry blindly. An acceptance observation, if authorized and proven, should deduplicate and update the relationship projection without claiming why the recipient accepted. Withdrawal, expiry, or rejection need explicit contracts before being advertised.

Correlate acceptance to account-scoped relationship identity
Avoid deriving sentiment or consent from acceptance

Release evidence

Prove the system can refuse and stop

Tests must cover duplicates, existing relations, pending state, changed recipients, stale approvals, concurrent workers, throttling, restriction, revoked sessions, ambiguous dispatch, late acceptance, tenant substitution, deletion, and kill switches. Qualified legal review and provider or partner authorization remain separate prerequisites. Until both decision and conformance gates pass, this is an educational workflow specification only.

Demonstrate zero action after account stop
Verify one recipient cannot receive duplicate invitations from retries

Questions

Before you build.

Can an ATS automatically invite every shortlisted candidate?+

It should not. Shortlisting is a hiring-workflow decision, not provider authorization or candidate contact permission. Require recruiter review, job purpose, sender identity, suppression checks, and the approved LinkedIn action path.

Does relation.accepted prove the person wants sales follow-up?+

No. It records a relationship-state observation if an approved connector can verify it. It does not establish marketing consent, buying intent, or permission for an automated sequence.

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 ↗

Design invitation workflows with explicit human intent

An invitation changes social state

Check context immediately before approval

Approve exactly what the recipient will see

Budget relationship actions conservatively

Keep sent, pending, accepted, and unknown distinct

Prove the system can refuse and stop

Before you build.

Related guides

Evaluate company search for an authorized LinkedIn product

Replace the company-scraper idea with a lawful CRM intake design

Design a governed lead-intake workflow without automated extraction

Does this match the workflow your users need?