How to pass participant data through a consult transfer in Architect

We had this exact problem breaking our automated workflows in Tray.io.

Because the consult transfer creates a separate interaction ID, our iPaaS webhook was triggering twice, and the second trigger had a blank payload. We ended up using the Genesys Cloud connector in Tray.io to explicitly query the parent conversation ID to fetch the original participant data, rather than relying on the webhook payload of the consult leg.

Surviving the Consult Transfer

This happens because a consult transfer creates a new conversation leg, and the UI doesn’t automatically pull the attributes from the original customer leg.

FWIW, you can force the data to persist across all legs by prefixing your attribute key with context. in Architect.

  1. Change your key: Instead of AccountNumber, use context.AccountNumber.
  2. Update Screen Pop: Ensure your CRM or script is looking for the new prefixed key.

YMMV with certain third-party softphones, but native GC desktops respect the context. prefix and will copy it to the consultative leg.

Does this context. prefix trick work for email interactions as well?

We parse incoming HTML emails and use a canned routing rule to attach a VIP flag to the participant data. If an agent replies and then transfers the email thread to another queue, the VIP flag gets stripped. We’ve been manually copying it, which is a pain.

I’m trying to pass custom participant data through a consult transfer, but the data gets lost.

In my Architect flow, I use Set Participant Data to attach an account number. When the first agent receives the call, the data is there. But if that agent initiates a consult transfer to a second agent, the second agent’s screen pop is blank. How do I ensure the data survives the consult leg?