Sync Amazon Connect and Salesforce Cases in Real Time

Most contact centers don’t have a “tool problem.” They have a truth problem.

A customer emails support. A Salesforce case gets created. Two days later, the same customer calls in during the holiday rush, and the agent opens Amazon Connect Agent Workspace… only to find a second case started on the call side, missing the email thread, missing prior notes, and missing ownership. Now you’ve got duplicated work, inconsistent updates, and a customer who has to repeat themselves.

Real-time case synchronization between Amazon Connect Cases and Salesforce fixes that. Better yet, it sets the foundation for AI in customer service—because AI can’t route, summarize, or recommend next-best actions reliably if the case record is split across systems.

This post breaks down a practical pattern: bidirectional, near real-time case sync using an event-driven, serverless architecture (EventBridge, SQS, Step Functions, and a bit of Lambda). I’ll also share the “gotchas” teams run into, and how to turn synchronization into a launchpad for AI-powered contact center workflows.

Why real-time case sync matters (especially for AI)

Answer first: If your CRM and contact center case tools drift apart, you get duplicated tickets, broken context, and unreliable automation. Sync keeps one shared customer story.

When cases don’t sync, three things happen fast:

1. Agents lose context. They can’t see prior updates, attachments, or comments without jumping systems.
2. Customers repeat themselves. That’s not a “nice-to-have” problem; it’s a churn problem.
3. AI outputs become less trustworthy. Any AI that depends on case history (summarization, suggested replies, sentiment-based escalation, auto-categorization) degrades when the record is incomplete.

In the “AI in Customer Service & Contact Centers” world, visibility is oxygen. Case sync is data plumbing that makes AI actually useful, not just flashy.

A quick myth to retire

A lot of teams assume sync is “just an integration project.” It’s not.

Synchronization is operational design. You’re defining what counts as the source of truth, which updates win, how conflicts are handled, and what events are worth acting on.

The architecture pattern: event-driven, serverless, auditable

Answer first: Use events to capture changes in either system, queue them, transform them, and apply updates—reliably—on the other side.

The AWS pattern described in the source article is clean because it avoids brittle point-to-point integrations and instead uses managed building blocks:

• Salesforce Platform Events + Flows to emit change events
• Salesforce Event Relay to send those events to Amazon EventBridge (as a partner event source)
• Amazon Connect Cases event streams to emit change events from the contact center side
• Amazon SQS as a buffer/queue
• AWS Step Functions to orchestrate transformation, validation, retries, and branching logic
• AWS Lambda for parsing and mapping where needed

This matters because contact center integrations fail in boring ways: transient API errors, throttling, weird payloads, partial updates, duplicate events. Step Functions + SQS is the “boring reliability” combo you want when your agents and customers are the ones paying the price for dropped updates.

Flow 1: Salesforce → Amazon Connect Cases

Answer first: Salesforce changes emit platform events that get relayed to EventBridge, queued in SQS, and applied to Connect via a Step Functions workflow.

High-level sequence:

1. A case is created/updated in Salesforce.
2. A Salesforce Flow publishes a platform event.
3. Salesforce Event Relay forwards it into Amazon EventBridge.
4. EventBridge routes it to SQS.
5. Step Functions validates and maps fields.
6. Step Functions calls Amazon Connect APIs to create/update a case.

Flow 2: Amazon Connect Cases → Salesforce

Answer first: Connect case events go to EventBridge, get queued in SQS, and then Step Functions calls a Salesforce API destination to publish platform events back into Salesforce.

High-level sequence:

1. A case is created/updated in Amazon Connect Agent Workspace.
2. Connect Cases emits an event stream update.
3. EventBridge receives the event.
4. EventBridge routes it to SQS.
5. Step Functions maps and validates.
6. Step Functions invokes a configured Salesforce API destination.
7. Salesforce receives the event and creates/updates the matching case.

Why Step Functions is doing the heavy lifting

Answer first: Orchestration gives you reliability features you otherwise end up rebuilding: retries, state, branching, and traceability.

In practice, Step Functions becomes your integration control plane:

• Data validation (ignore events you don’t want)
• Idempotency handling (avoid duplicate creates)
• Conditional logic (create vs update depending on presence of IDs)
• Retries/backoff for downstream throttling
• Auditable execution history for troubleshooting

If you’re building for Q4 peaks (and it is December), auditability is not optional. It’s the difference between “we think it synced” and “we can prove what happened to this case.”

What to sync (and what not to): a pragmatic data contract

Answer first: Sync the fields that drive customer experience and operations; don’t sync everything by default.

Teams often start by trying to mirror every field. That’s how you end up with fragile mappings and endless change requests.

Start with a minimum viable case contract:

• Case identifiers
  • Salesforce Case ID
  • Amazon Connect Case ID
  • A shared external correlation key (recommended)
• Customer context
  • Contact/account reference
  • Channel of origin (email/voice/chat)
• Operational fields
  • Status
  • Priority / severity
  • Owner / queue
  • Category / reason codes
• Timeline updates
  • Comments / internal notes (with clear directionality rules)
  • Key timestamps (created, last updated)

Then add only what you can govern.

Directionality rules prevent “sync wars”

Answer first: Decide which system is authoritative for each field to avoid infinite loops and conflicting updates.

A practical stance I’ve found works:

• Salesforce is authoritative for account/contact metadata, entitlement, and SLA fields.
• Amazon Connect Cases is authoritative for agent interaction notes, call disposition, and contact center operational data.
• Status and priority can be shared, but only if you define precedence and conflict handling.

Also: make explicit decisions about attachments and PII. Many organizations choose not to sync attachments cross-system until security and retention are settled.

Common failure points (and how to avoid them)

Answer first: Most sync projects fail due to duplicates, loops, throttling, and unclear ownership—not because of missing tech.

Here are the issues I’d plan for on day one.

1) Duplicate creates and event replays

SQS and event-driven systems are designed for reliability, which means you can see duplicate deliveries.

Fix it with:

• Idempotency keys: treat “create” as “upsert” using a shared correlation ID.
• A mapping store: persist the Connect Case ID ↔ Salesforce Case ID relationship.
• Step Functions guards: “If ID exists, update; else create.”

2) Infinite loops

If a Salesforce update triggers a Connect update, which triggers a Salesforce update… you’ve built a case ping-pong machine.

Fix it with:

• An event origin marker (for example, updatedByIntegration=true or a source system field)
• Filtering rules: “ignore events created by the integration user”

3) API throttling during seasonal spikes

Holiday volume can turn a safe integration into a backlog factory.

Fix it with:

• SQS buffering (already in the pattern)
• Step Functions retry/backoff
• Controlled concurrency for Lambda and workflow executions
• Operational dashboards: queue depth, age of oldest message, failure rate

4) Field mapping drift

The integration works… until someone changes a picklist value or adds a new required field.

Fix it with:

• A versioned mapping layer (even a simple config file)
• A “dead-letter” pathway for invalid payloads
• Tests for picklist/value translation

Turning synchronization into AI-powered service workflows

Answer first: Once cases sync in real time, you can apply AI consistently across channels, teams, and touchpoints.

This is where the “AI in Customer Service & Contact Centers” series theme really shows up: synchronization isn’t the end goal. It’s the enabler.

Smarter routing and prioritization

With shared case context, you can:

• Trigger AI-based triage on new cases (category prediction, urgency detection)
• Route to the right queue based on combined signals: channel + customer tier + sentiment + defect codes
• Escalate when AI detects phrases correlated with churn or regulatory risk

Even without fancy models, better data improves routing logic.

Better summaries, less after-call work

If both systems see the same comments and timeline updates, you can standardize:

• AI-generated case summaries (same summary available to agents and back-office)
• AI-suggested internal notes formatting (“what happened / what we tried / next step”)

The practical win: less swivel-chair work, faster handoffs.

Customer journey visibility you can actually act on

When a case created via email in Salesforce is visible to voice agents inside Connect, you’re building a real omnichannel narrative.

That enables:

• Consistent messaging across channels
• Cleaner escalation paths
• More reliable analytics (time-to-resolution, transfer reasons, reopen rates)

A real-world lens: three use cases worth copying

Answer first: Product defects, omnichannel continuity, and financial disputes benefit immediately because they require cross-team coordination.

The source article calls out three strong scenarios. Here’s how I’d frame them operationally:

1. Product defect management

   • Support logs the issue during a call in Connect.
   • Salesforce gets the case instantly for product/engineering workflows.
   • AI can later cluster similar defect cases to spot patterns earlier.

2. Omnichannel support continuity

   • Email starts in Salesforce.
   • Phone follow-up lands in Connect with the full thread visible.
   • AI summaries keep the history readable when the timeline gets long.

3. Financial dispute resolution

   • Agents capture dispute details while on the call.
   • Finance starts work from Salesforce without waiting for manual handoff.
   • Automation can enforce required fields and compliance checkpoints.

Each one shares the same theme: sync reduces customer effort and internal latency.

Implementation checklist (what I’d verify before go-live)

Answer first: Treat go-live like a production system: security, observability, and failure handling first—then features.

Here’s a checklist you can use even if you’re following a reference repository/template.

• Security & access

  • Integration user permissions are least-privilege
  • Secrets are managed properly (no hardcoded tokens)
  • PII handling rules are documented

• Reliability

  • Idempotency is implemented for creates
  • Retries/backoff are configured
  • Dead-letter queues exist and are monitored

• Observability

  • Dashboards for Step Functions failures and SQS depth
  • Alerting on “age of oldest message”
  • Correlation IDs logged end-to-end

• Data governance

  • Field authority rules agreed (who owns status? priority?)
  • Conflict resolution behavior tested
  • Picklist/value mappings locked and versioned

• Operational readiness

  • Runbooks: what to do when messages pile up
  • A replay strategy for failed events
  • A rollback plan for mapping changes

A simple rule: if you can’t explain how the system behaves when Salesforce is down for 30 minutes, you’re not done.

What to do next

Real-time case synchronization between Amazon Connect and Salesforce is one of those projects that pays off twice: once in agent productivity, and again when you start rolling out AI features that depend on clean, complete case history.

If you’re planning AI in your contact center for 2026—customer intent detection, sentiment-aware routing, auto-summaries, proactive outreach—start by making sure your case data doesn’t fracture across systems.

Where is your “source of truth” drifting the most right now: status and ownership, customer context, or the comment timeline?