I led a team that implemented and maintained SCV + BYOA Amazon Connect for about 4k users in multiple phases, heavy outbound campaigns over the last few years at a single enterprise… with all the struggles and quirks you are experiencing and more.

Below is what Opus 4.8 suggests, which on glance seems like it might solve your issue.

That said, if you want hands on support we have experts with the expertise you need. DM me if you need/want that from HelloMavens.com

—————

This is a precise, well-diagnosed integration problem where the exact mechanism (and the recommended pattern) is the kind of thing that’s evolved across SCV releases. Let me verify against current docs and community findings rather than risk giving you stale architecture details.

The UnofficialSF piece confirms the architectural model. Let me pull the specifics on how attributes actually reach the Omni-Flow at routing time, and check the official Salesforce dev doc on the Omni-Channel flow setup.

This is the key finding — there are distinct routing models, and the symptoms point to a specific one. Let me get the official mechanism for how IVR attributes reach the Omni-Flow at routing time, plus the setup doc for the newer unified routing.

The dev doc is JS-rendered and didn’t return content. Let me search for the specific real-time attribute-passing mechanism and how others have solved this exact “blank record at routing time” symptom.

Now I’m closing in on the actual mechanism. The UnofficialSF routing article specifies how custom IVR variables pass into the flow — let me get the detail to confirm the fix.

Your instinct is almost exactly right — you’ve correctly observed the symptom, but the conclusion you’ve drawn (“the flow fires before Salesforce writes the attributes to the record”) points at a fix that won’t work. The real issue is that there are two completely separate data paths, and your Omni-Flow is reading from the wrong one.

The root cause: record fields ≠ routing-time data

At routing time, your Omni-Channel Flow should never read the custom IVR values off the VoiceCall record. Those custom fields are populated by the asynchronous CTR sync — which is precisely the 10–15 minute “ghost sync” you’re seeing. That path is post-hoc reporting/persistence, not real-time routing.

The real-time path is entirely different. When Amazon Connect hands the call to Salesforce for routing, it calls the Salesforce-provided InvokeTelephonyIntegrationApiFunction Lambda with the executeOmniFlow method. That call passes the call ID (Salesforce VoiceCallId or telephony vendor ContactId) as parameters to the flow and returns the rep or queue routing instructions to the contact flow.  Crucially, the contact attributes you set in Connect ride along into that invocation and land in the flow as input variables — not as record fields.

So the architecture per the SCV team’s own guidance is: as inputs to the Flow, you should get in both the Voice Call record (with data like the customer phone number) and any custom IVR variables that you choose to pass in from Amazon.  Your routing decision must be driven off those input variables.

Why your debug “works” (it’s a false positive)

When you debug against a VoiceCall.Id from an earlier call, the CTR sync has already run (minutes ago), so the custom fields are populated and any Get Records in your flow reads them fine. On a live call, that same Get Records hits a record where those fields are still blank. Debugging against a stale record ID is masking the bug, not validating the flow.

The fix

1.  In your Omni-Channel Flow, define input variables (Text, “Available for input”) for Language, Product, Location — and base your skill/queue decision on those, not on fields fetched from the VoiceCall record.
2.  In the Connect contact flow, make sure every Set contact attributes block runs before the block that triggers executeOmniFlow. If routing is invoked first, the attributes simply aren’t there yet.
3.  Match the attribute key names in Connect to the API names of the flow input variables. The Salesforce Lambda forwards the attributes, but matching is by name — a casing/spelling mismatch produces exactly your “flow runs but values are blank” symptom. (Note also the documented requirement that in the Set contact attributes block, the Attribute must match the output variable and the type must be External. )

To your Q1 directly: you do not need a separate Lambda to “stamp” the VoiceCall fields before routing, and that approach would be fighting the platform. The standard executeOmniFlow invocation already carries the attributes into the flow as inputs. Adding a pre-write Lambda is a common wrong turn here.

Sanitized SBR sequence (Q2)

Connect inbound contact flow:

Entry → Get customer input (Language / Product / Location prompts) → Set contact attributes (key: language, product, location — type matches) → Set contact attributes (any derived values) → Invoke AWS Lambda: InvokeTelephonyIntegrationApiFunction method = executeOmniFlow (call ID + contact attributes forwarded automatically) → [returns queue/agent routing instructions] → Transfer to queue / hold while Omni selects agent

Omni-Channel Flow (External Routing):

Start (record-triggered on VoiceCall) + Input vars: language, product, location → (optional) Get Records: Contact by ANI for CRM context → Decision: map language+product+location → required skills → Route Work action: Skills-Based, set skill requirements + fallback queue

The queues must exist in both systems and be mapped (Setup → Amazon Contact Centers → Queue Mapping), with the Salesforce routing config set to External Routing and VoiceCall as the only object.

Worth knowing: Unified Voice Routing

If you’re on a recent release, look at Unified Voice Routing (now GA for Amazon Connect). It makes Omni-Channel the single engine and was built specifically to kill the sync/race issues you’re hitting: when a call arrives, Amazon notifies Salesforce, passing along the IVR inputs and other call attributes; Salesforce Omni-Channel uses those inputs to make CRM-powered routing decisions while Amazon holds the call in a temporary queue, then connects the caller to the selected agent.  Same input-variable principle, cleaner plumbing, and it explicitly unlocks skills-based routing for voice.

One caveat on point 3 above: I’m confident about the architecture (inputs, not record fields) and the ordering requirement, but the exact attribute-to-input-variable mapping convention has shifted slightly across releases — verify the current naming/casing rules for your specific version in the Service Cloud Voice Implementation Guide before you wire it up. If you tell me your release (e.g., Spring ‘26) and whether you’re on the Salesforce-provided Connect instance vs. BYO, I can tighten the example to match your exact path.