Genesys Bot Flow Losing Slot Values After Handoff to Architect Inbound Flow

Architect & Flows
1

This is driving me absolutely crazy and I think it might be a legitimate platform bug.

We built a Digital Bot Flow that collects three slots from the customer via web messaging: accountNumber, issueCategory, and preferredLanguage. The bot flow works perfectly - I can see all three slot values populated in the conversation variables when I look at the bot debug logs.

But when the bot transfers to our Architect Inbound Message Flow using the Transfer to ACD action, only accountNumber survives. The other two slots arrive as NOT_SET in the inbound flow.

Here is how we are mapping the variables in the Transfer to ACD block:

Flow.accountNumber = Slot.accountNumber
Flow.issueCategory = Slot.issueCategory  
Flow.preferredLanguage = Slot.preferredLanguage

All three flow variables are defined as String type in the receiving inbound message flow. We verified the variable names match exactly (case-sensitive). The first slot always works, but the second and third just vanish.

We are on version 2024.11.0 in the APAC Sydney region. Has anyone run into this pattern where only the first mapped variable survives a bot-to-flow transfer?

2

This is a documented limitation in the current Digital Bot Flow transfer mechanism. When the bot hands off to an Architect flow, the participant attributes are serialized and passed via the conversation context. There is a known issue where attributes containing certain characters in the value - specifically colons, pipes, and semicolons - cause the serialization to truncate the remaining attributes.

The reason accountNumber always works is because it is the first in the serialized payload, before the truncation point. Check the actual values being passed in issueCategory and preferredLanguage. If the customer typed something like “billing: refund” as their issue category, the colon would break the serialization.

The recommended workaround is to sanitize all slot values in the bot flow before transfer by stripping special characters using the Replace() expression function.

3

Oh wow, we had this EXACT problem last month! The sanitization fix works but there is actually a cleaner solution that Genesys released in the November patch.

Instead of passing variables through the Transfer to ACD block directly, use a Data Action inside the bot flow to write the slot values to the conversation’s participant attributes via the Platform API before the transfer happens. That way the values are already persisted on the conversation object and the receiving flow can read them with GetConversationAttribute().

Here is the API call we use in the data action:

PATCH /api/v2/conversations/{conversationId}/participants/{participantId}/attributes
{
  "attributes": {
    "accountNumber": "{{Slot.accountNumber}}",
    "issueCategory": "{{Slot.issueCategory}}",
    "preferredLanguage": "{{Slot.preferredLanguage}}"
  }
}

This completely bypasses the transfer serialization issue and the attributes survive reliably every single time.

4

We migrated from Zendesk to GC last quarter and hit this same wall during UAT. The participant attributes approach is definitely the way to go long-term.

One additional thing to watch out for: if you are using the GetConversationAttribute() function in the receiving Architect flow, make sure you are reading from the correct participant. The bot creates its own participant record, and the attributes you wrote via the PATCH call are on the bot participant - not the customer participant.

In our receiving flow, we had to iterate through Conversation.participants and find the one with purpose: customer to read the attributes correctly. It took us two days to figure out why GetConversationAttribute() was returning null even though the PATCH was successful.