Web Messaging Widget - CONTEXT_PRESERVATION loss on architect transfer

Genesys Cloud WFM
1

The JavaScript messenger SDK - version 2.1.0 - is dropping custom data attributes during a transfer initiated from an Architect flow. We’ve confirmed the CONTEXT_PRESERVATION flag is set to true in the transfer activity.

Initially, the custom attribute custom.event.contact.sync populates correctly. However, after transfer to the queue, the attribute is missing. Similar to the Java handoff issue detailed in a recent community post, the deployment snippet seems to be the source of the problem.

The Architect flow use a Transfer to Agent activity with the following configuration: Queue ID - 12345, Skill Requirement - Any. The flow performs a transfer operation. It worked previously, and we haven’t altered the deployment snippet directly. There’s been a platform update.

2

That CONTEXT_PRESERVATION flag is…optimistic. We’ve seen it fail consistently when architect flows are involved - especially with custom data. It’s not a boolean switch so much as a suggestion to the platform.

The problem isn’t necessarily the transfer itself, it’s how Architect handles serialization. It strips anything it doesn’t explicitly recognize.

Try this - instead of relying on the SDK passing the attribute, push the data as a custom event before the transfer. Then retrieve it on the queue side. It adds a step, sure, but it’s more reliable.

Here’s a sample payload for the custom event - you’ll need to adjust the eventType and eventData to your needs. This goes in a “Send Event” activity before the transfer:

{
 "eventType": "contact.sync",
 "eventData": {
 "custom.event.contact.sync": "your_data_here"
 }
}

Then, in the queue’s interaction routing or agent desktop configuration, you’d access it via the Interaction Data section. Not 100% sure but, that’s where we’ve had the most success.

We hit a similar issue last year with a Salesforce sync - Architect was chopping off the account ID. It wasn’t a rate limit issue, surprisingly, but a data type mismatch during the transfer. For what it’s worth, Salesforce expects a string, and Architect was passing a number.

4 Likes
3

yeah the earlier reply covers it - CONTEXT_PRESERVATION is…a wish more than anything lol. we ran into this too, and it almost always comes down to how architect is serializing. it’s super picky about what it passes along.

if it helps, try pushing the data as a custom event before the transfer. but also - and this is where it gets kinda annoying - you might need to re-attach it in the target queue’s entry event. something like this:

{
 "type": "CustomEvent",
 "name": "contact.sync",
 "data": {
 "value": "${custom.event.contact.sync}"
 }
}

make sure the EVENT_TYPE is exactly “CustomEvent” and the NAME matches what you want to call it on the other end. it’s a pain, but it’ll bypass architect trying to ‘help’ by dropping stuff it doesn’t recognize. we usually trigger this from a DATA ACTION right before the TRANSFER activity.

1 Like
4

The earlier reply is right. It’s a known gap with how the transfer activity handles the payload.

To fix it, use a data action in Architect right before the transfer to explicitly set the attribute on the conversation.

{
 "attributes": {
 "custom.event.contact.sync": "value"
 }
}

Then call PATCH /api/v2/conversations/{conversationId}/customattributes to lock it in.

5

Watch out for the rate limits if you go the Data Action route for every transfer.

Hitting PATCH /api/v2/conversations/{conversationId}/customattributes too fast during a spike will trigger 429s. Batch the updates or add a small delay in the flow.