Deduplicate Automations Triggered by Inbound Email

Before a new-email trigger can update a CRM, create a task, call an agent, or send a follow-up, give the inbound message a stable identity and the business action a separate idempotency key. Transport delivery is not the same thing as business intent.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 4, 2026.

Streak’s product updates document automations that can fire when new email activity updates a CRM box. This makes a previously manual handoff easier, but it also makes duplicate and ambiguous message ingestion consequential.

Use three identities#

Do not collapse every layer into one “email ID.”

RFC 5322 defines the Message-ID field for message identity. Use it when present, but never assume it is perfect. Scope it to the receiving account or tenant, normalize conservatively, and provide a fallback for missing or malformed values.

A fallback fingerprint might combine immutable provider message ID, canonical sender, received timestamp bucket, subject digest, and body digest. Label it as a heuristic. Two legitimate messages can share content, while one message can be modified by forwarding.

Make the action key explicit#

Generate the business key from the decision boundary:

action_key = hash(
  tenant_id,
  object_id,
  rule_id,
  rule_version,
  message_identity,
  action_type
)

Store it before performing the side effect. A repeated transport event should return the prior result. A changed rule version should not automatically re-run old messages unless a backfill has separate authorization.

Migma’s webhook documentation describes at-least-once delivery with stable event IDs and retries. At-least-once delivery means consumers must expect repetition. Migma’s events documentation also documents idempotent ingestion. These are useful reference contracts; they do not remove the need to define idempotency for your own downstream action.

Decide whether the trigger is message- or thread-scoped#

An email thread can contain several business moments. Choose one policy:

• Message-scoped: every new message is evaluated independently.
• Thread-first-response: only the first qualifying reply triggers the action.
• State-transition: a message triggers only when it changes a CRM field from one state to another.
• Windowed: repeated qualifying messages within a defined interval collapse into one task.

Record the thread identifier, message identifier, rule decision, and prior state. Never infer “one thread equals one intent” for long sales or support conversations.

Separate classification from consequence#

Use a two-stage pipeline:

1. Ingest and store the message envelope and safe content reference.
2. Classify the event under a versioned rule.
3. Write a proposed action with evidence and confidence.
4. Check idempotency and current CRM state.
5. Execute only the authorized side effect.
6. Record result, provider object ID, and any retry.

For an AI classification, persist the model, prompt, allowed fields, and output schema. Do not let message body text expand tool permission. An inbound email is untrusted content, not an instruction hierarchy.

Keep a side-effect ledger#

Write success only after the destination confirms the intended state. A timeout is unknown, not failed. Query by idempotency key or destination object before retrying.

Replay suite#

Run fixtures for:

1. the same webhook event delivered twice;
2. two provider events for the same message;
3. one message synchronized through an alias and primary mailbox;
4. a forwarded copy with a new Message-ID;
5. a reply in an existing thread after the action already completed;
6. a message arriving before its CRM box exists;
7. two workers executing concurrently;
8. a timeout after the destination committed the change;
9. a rule version updated while old events remain queued;
10. adversarial body text asking the automation to ignore policy.

For every fixture, assert both the final CRM state and the count of external side effects. “No error” is not a deduplication result.

Stop conditions#

Quarantine the event when tenant or target object is ambiguous, message identity cannot meet the workflow’s collision tolerance, the rule cannot explain its match, current CRM state conflicts with the proposed transition, or destination state cannot be reconciled after a timeout.

Do not create a second task merely because the first response was slow. Retry the same action identity.

Evidence limits#

Marketing Wiki did not inspect a Streak automation, deliver a Migma webhook, submit an event, or process a live mailbox. The sources establish that inbound-activity triggers and replay-relevant contracts exist. The identity hierarchy, ledger, and replay suite are a portable method, not evidence about either vendor’s runtime duplicate rate.