Planned capability

Workflow automation

Automate the handoff, not the human relationship

Design reply-aware messaging and mailbox workflows around an explicitly connected account, durable command state, and evidence from the provider. DewEngine's target is a controllable execution layer for product-owned rules, not a campaign engine that invents recipients or decides when contact is appropriate.

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

Talk to us ↗Read technical guides →

Planned boundary

The automation surface is a design contract

Cross-channel automation on this route is planned and not callable. The repository proves pieces of command durability and webhook delivery in development, but it does not contain released messaging or email automation connectors.

Current evidence: The control plane can persist tenant-scoped commands, lease outbox work, record provider attempts, and deliver signed webhooks. Only a narrow Google Calendar create path has connector evidence; Gmail and messaging actions remain outside that implementation.
Target contract: A workflow references one connected account, one stable recipient or conversation identity, and an application-supplied policy decision; Every step exposes accepted, provider-confirmed, indeterminate, suppressed, or failed state without converting queue acceptance into delivery; Inbound replies and account-health changes can stop pending work before another channel step is eligible
Known limits: DewEngine will not supply lead lists, consent, sequence strategy, or a guarantee that a provider delivers or surfaces every reply; Provider pacing, mailbox reputation, opt-out law, message windows, and application-level suppression remain constraints even after a connector exists
Release gates: Ship at least one released mailbox connector and one authorized messaging connector with normalized reply evidence; Prove crash-safe dispatch, ambiguity reconciliation, account-level pacing, suppression, and duplicate prevention under injected faults; Publish exact event coverage and a provider-specific limits matrix before enabling customer workflow traffic

Product model

Make workflow state visible at every step

A sequence should be represented as application-owned intent plus DewEngine execution receipts. The product selects the connected account and channel; the command ledger records what was requested; the connector records what the provider actually acknowledged. That separation lets an operator inspect a stalled step without mistaking a queued job for a delivered message.

Keep content, audience eligibility, and timing decisions in the calling product
Return provider evidence and canonical state as separate fields

Implementation path

Commit intent before provider dispatch

The planned write path starts with an idempotency key scoped to workspace, account, and action. A transaction stores the command and outbox job before a worker contacts the provider. If the network outcome is uncertain, the worker must reconcile through a safe provider read or hold the command for review instead of blindly repeating a human-visible send.

Use deterministic markers where an authorized provider contract permits reconciliation
Treat a provider acceptance response as acceptance, never recipient delivery

Reply handling

Stop from durable inbound evidence

Reply-aware logic needs a normalized inbound event tied to the correct provider account and native thread. A webhook may wake the workflow, but the stored message or thread state should decide whether later steps are cancelled. Duplicate, delayed, edited, and deleted observations must not restart work or erase the audit trail.

Deduplicate inbound observations by account-scoped provider identity
Record which reply caused each pending action to become ineligible

Policy controls

Put suppression ahead of convenience

Before dispatch, the calling application should provide an affirmative eligibility result based on consent, relationship state, workspace rules, and prior responses. DewEngine's planned enforcement layer can add account pacing, kill switches, and provider-window checks, but it cannot repair a workflow whose business rule authorized unwanted contact.

Recheck suppression after a lease is acquired, not only when a sequence is created
Give operators a reversible hold before any uncertain action is retried

Operational proof

Release only after silence and failure are testable

A credible release needs fixtures for duplicate callbacks, expired credentials, provider throttles, ambiguous timeouts, delayed replies, and worker crashes. Metrics must distinguish queue age, provider attempt age, inbound sync lag, and suppression outcomes. Without those signals, apparent automation speed would hide the cases most likely to send twice or continue after a response.

Run fake-provider fault suites before consented real-account conformance
Document unsupported events so a missing callback never implies no reply

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.

Does this page describe a bulk email or messaging sender?+

No. It describes a future execution boundary for actions that a customer's product has already authorized. Recipient sourcing, consent, campaign logic, content review, and lawful use stay with that product, while provider capabilities and limits remain explicit.

What happens when a send times out after dispatch?+

The planned command should enter an indeterminate state. A connector may reconcile using a deterministic provider marker when the provider supports a safe read; otherwise the action is held for operator resolution rather than dispatched a second time.

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 ↗