How to Design an Email-to-Ticket Workflow Without Missing Requests

A production flow should include these stages:

1. Receive the event: use a webhook or cursor-based polling to retrieve new mail from configured mailboxes. Webhooks reduce latency; scheduled polling provides reconciliation.
2. Persist an inbox event: store the required metadata and payload before acknowledging receipt. Enforce a unique constraint on mailbox_id + provider_message_id.
3. Enqueue work: publish a job containing inbox_event_id; avoid copying sensitive message data when it is unnecessary.
4. Normalize and validate: check the recipient, message type, attachments, size, and required fields. Invalid messages enter a review state rather than being deleted.
5. Classify: business rules determine queue, priority, request type, and owner. AI should only propose structured data with confidence; low-confidence results need an explicit fallback.
6. Create the ticket idempotently: send a stable idempotency key or check the existing mapping before calling the API.
7. Store the outcome: persist ticketId, state, timestamps, and an audit event. Only now is processing complete.
8. Notify: acknowledge the requester after the ticket exists; do not promise an SLA until the applicable policy is known.

Create dedupe_key = hash(tenant_id, mailbox_id, provider_message_id, action_type) and enforce a database unique constraint. A worker claims the record, checks for an existing mapping, calls the ticketing system with an idempotency key when supported, and stores ticketId.

If the ticket API succeeds but the worker crashes before storing the result, a retry can create a duplicate. Prefer provider-side idempotency. When unavailable, use an external-reference field with a unique constraint or query for that reference before creating again. Do not deduplicate by subject and sender: two legitimate requests may look identical.

When a database update and message publication are separate operations, use a transactional outbox. Write the state change and outbox event in one transaction, then let a separate publisher send it to the queue. Consumers still need idempotency because delivery can be repeated.

Grant read access only to required mailboxes and the minimum ticket-creation scope. Keep credentials in a secret manager with rotation and auditing. Logs should not retain full message bodies or attachments by default; mask personal data and enforce retention rules.

Never let email content directly authorize sensitive actions such as refunds, permission changes, or command execution. Rules must verify the sender or domain, request type, and business context; high-risk actions require approval. Scan attachments for malware, restrict file types and sizes, and retain a quarantine state for investigation. SPF, DKIM, or DMARC results can contribute risk signals, but they should not be the sole proof of identity or authorization.

Should we use webhooks or polling?

Use both: webhooks for near-real-time processing and cursor-based polling for reconciliation and recovery. Polling needs a durable checkpoint and an overlapping window protected by deduplication.

Is marking an email as read enough to confirm ticket creation?

No. Completion requires a stored mapping from the email to ticketId. Read state is mailbox metadata and can change outside the workflow.

How many retries are appropriate?

There is no universal number. Set the policy according to dependency recovery time, SLA, and API limits. Use jittered backoff, then route to the DLQ. Validation errors should not be retried like network failures.

Should AI classify and assign tickets automatically?

It can, but it should return schema-validated data, confidence, and a rationale. Low-confidence or sensitive requests need a default queue or human review. AI must never decide to discard an email.

How can we prove the workflow does not miss requests?

Automatically reconcile the email provider, inbox event table, and ticketing system. Monitor unmapped records and oldest-record age, then run recovery drills. Reliability must be demonstrated through evidence, not only a successful workflow status.