Amazon Connect: Chat That Survives a Region Switch, Profiles Shaped to the Role

Two Amazon Connect announcements from late October share a theme that is easy to miss if you read them separately: continuity. Persistent chat now carries across Global Resiliency Regions, so a customer can resume a chat in a paired Region with the transcript intact. And Customer Profiles layouts in the agent workspace can now be built per role, so each agent sees the profile fields their work actually needs. One change protects the customer's thread when infrastructure fails over. The other protects the agent's attention when the profile holds more data than any one person should see. Both are about designing continuity in advance, because neither can be improvised in the moment it is needed.

What changed

• Persistent chat across Global Resiliency Regions (announcement date October 23, 2026). AWS extended persistent chat to Amazon Connect Customer Global Resiliency. A customer who starts a chat in one linked Region, such as N. Virginia, can later continue it in the paired Region, such as Oregon, with the full transcript, contact metadata and chat attachments carried over for the agent. Adopting it requires onboarding to Global routing. AWS states it is available in all AWS Regions where Global Resiliency is supported, and the announcement states no licensing or pricing changes.
• Role-specific Customer Profiles layouts (announcement date October 22, 2026). Administrators can now choose which Customer Profiles data agents see in the agent workspace and how it is laid out. Layouts are built and saved in Profile Explorer from widgets such as contact history, contact information and calculated attributes like lifetime value, then assigned to agents in place of the legacy Customer Profiles view. Layouts can include an AI Profile Summary of the customer profile. AWS lists N. Virginia, Oregon, Cape Town, Seoul, Singapore, Sydney, Canada (Central), Frankfurt and London for Profile Explorer.

For the full release records, see Amazon Connect release intelligence, the Global Resiliency persistent chat update and the Customer Profiles layout update. The official sources are AWS What's New on persistent chat (opens in a new tab) and AWS What's New on Customer Profiles layouts (opens in a new tab).

Pattern 1: Put chat in the failover test plan

Persistent chat across Regions closes a gap that failover plans used to accept quietly. Voice failover was the tested path; chat was the channel that restarted. A customer mid-conversation when a Region switch happened lost the thread, repeated themselves to a new agent, and — if the issue was urgent — called instead, which is exactly the surge a failover is supposed to absorb. Carrying the transcript, metadata and attachments across the paired Region removes that restart, but only for instances onboarded to Global routing. That precondition is the part to act on: continuity now depends on a routing decision made long before any incident.

Start by confirming the precondition. If your instance is not onboarded to Global routing, the feature is not available to you, and the announcement is a planning input rather than a capability. If you are onboarded, add a cross-Region chat-resumption test to your next failover exercise — not as a footnote to the voice test, but as its own scenario. Start a chat in the primary Region, exchange several messages, attach a file if the journey supports it, then trigger the switch and confirm the agent in the paired Region sees the full transcript, the contact metadata and the attachment. Test the failure modes too: a chat that switches mid-typing, a customer who resumes hours later rather than seconds later, and a chat whose attachments reference files the paired Region must still be able to serve.

Then connect the test to the systems that hold the rest of the customer's story. A carried-over transcript is only half the continuity; the other half is the case. If your CRM is Salesforce or ServiceNow, the chat should still land against the same case record after the switch, and the agent should not have to re-ask for the order number or the account ID that the transcript already contains. Fold that check into the same exercise: confirm the case link survives the Region switch, and confirm the survey tools downstream — Qualtrics or Medallia — still attribute the conversation to the same journey, so a failover does not look like a fresh contact in your satisfaction data.

Pattern 2: Design profile layouts like an access decision

The Profile Explorer change looks like a layout tool, but it is really an access decision wearing a design interface. A single generic profile view forces every agent to hunt through the same fields regardless of their queue. Role-specific layouts fix that — a billing agent sees payment history and lifetime value, a technical support agent sees contact history and device information — but they also decide, field by field, who sees what. That is a data-minimization decision, and it should be made deliberately rather than by whoever builds the first layout.

Begin with the roles, not the widgets. For each agent role, list the profile fields the role actually needs to resolve its contacts, and just as importantly, list the fields it does not need. A collections agent does not need the same view as a retention specialist, and neither needs the full profile. Build one layout per role from that list, using the available widgets — contact history, contact information, calculated attributes like lifetime value — and resist the temptation to include a field "just in case." Every extra field is a field an agent can misread, a customer can ask about, and an auditor can question.

The AI Profile Summary deserves its own decision before it goes into any layout. A generated summary of the customer profile can save an agent real time at the start of a contact, but it is a summary of data the agent may not otherwise see, which means it changes the access picture even when the underlying fields are hidden. Decide per role whether the summary is appropriate, document that decision, and test it with real profiles before replacing the legacy view. The legacy view is the fallback; keep it available until the new layouts have been exercised on live contacts, and treat the first weeks as a pilot with explicit feedback from the agents using them.

Pattern 3: Continuity is a design property, not a feature

The two announcements connect at a level neither states outright. Persistent chat continuity protects the customer's thread across infrastructure failure. Role-specific layouts protect the agent's context at the start of every contact. Both reduce the same cost: rework — the customer repeating themselves, the agent hunting for context, the case losing its history. And both only work if they are designed before they are needed. A failover test written during an incident is not a test. A profile layout built after agents complain is not a design.

Treat them as one program with a shared checklist. Confirm Global routing onboarding and schedule the cross-Region chat test. Define the profile fields per role, build the layouts, and decide on the AI Profile Summary per role. Validate both against the systems around them: CRM case linkage surviving a Region switch, survey attribution surviving a resumed chat, and HRIS role data matching the layout assignments so a role change actually changes what an agent sees. Two announcements, one discipline: decide what continuity means for your customers and your agents, then build it before the day you need it.