Is there a clean way to access participant attributes set by Web Messaging inside an Architect Inbound Message flow?
I am building a .NET reporting dashboard that correlates web chat sessions with specific CRM IDs. The frontend team sets a custom attribute crmId during the startChat call. I can see this attribute in the conversation details via the /api/v2/conversations/messaging/{id} endpoint. The JSON payload returns correctly:
{
"participants": [
{
"attributes": {
"crmId": "CUST-12345"
}
}
]
}
However, when I try to access this data within the Architect flow using the “Get Participant Details” block, the crmId field is missing from the output object. I have tried mapping conversation.participants[0].attributes.crmId directly in a Set Variable block, but it resolves to null. I also attempted to use the conversation:read scope in my .NET SDK authentication, but that only affects the API calls, not the Architect context.
I suspect the attribute might be nested differently or requires a specific Data Action to expose it. I have checked the documentation for Get Participant Details, but it does not explicitly mention custom attributes set via the Web Messaging SDK.
Is there a specific JSON path or Data Action configuration required to surface these custom attributes in the Architect flow? I need this data to route the message correctly before my backend service processes it. My current flow fails because the routing logic relies on this crmId being present.
I have verified that the attribute is being sent from the client side and is visible in the Genesys Cloud UI under the conversation details. The issue is strictly within the Architect flow execution. Any code snippets or configuration examples would be helpful.
Thank you.
Check your data source configuration in Architect. The issue usually stems from how you are referencing the attribute path rather than the API availability. When Web Messaging attributes are pushed via the startChat or sendEvent client-side methods, they are stored within the participant’s attributes object. However, Architect does not automatically expose these nested JSON properties as simple variables like crmId. You must use the correct data path syntax.
In your Set Data or Condition step, do not just type crmId. Instead, reference the participant’s attributes object directly. If you are processing the inbound message, the participant is typically the one who initiated the chat. The path should look like this:
{
"path": "participants[0].attributes.crmId"
}
Warning: Array indices in Architect data paths are zero-based, but if you have multiple participants (e.g., a system participant and the customer), ensure you are targeting the correct index. The customer is usually at index 0 or 1 depending on whether the system bot is counted first in the specific flow context. To be safe, iterate over participants if the index is unstable.
Here is how I handle this in my Python automation scripts when validating these flows via the API, which mirrors the internal data structure:
from genesyscloud import platform_client
# Fetch conversation to verify attribute presence
conv = platform_client.conversations.get_conversation_by_id(conversation_id)
if conv.participants:
for p in conv.participants:
if p.attributes and 'crmId' in p.attributes:
print(f"Found CRM ID: {p.attributes['crmId']}")
In Architect, if the attribute is not appearing, verify that the Web Messaging widget is actually sending the attribute in the attributes payload, not as a separate custom header. The frontend must send it as part of the participant definition. If you are using the sendEvent method, ensure the event data is being mapped to the participant attributes in a prior step, as events are ephemeral unless explicitly saved to the participant profile.
My usual workaround is to grabbing the attribute directly from the participant object in the data source since nested JSON doesn’t auto-expose.
{{conversation.participants[0].attributes.crmId}}
Just make sure the index matches the web user, not the system bot.