Set Participant Data action

This action is available in the Data category of the task editor’s Toolbox. Architect can assign attributes, or participant data, to voice or digital participants. An attribute is a piece of information about a participant that travels with it throughout the interaction. In Architect, a participant is the caller on an inbound voice or digital flow, or the recipient on an outbound flow.

About attributes

In contrast to flow variables, participant data attributes persist between transfers from one flow to another. For example, the participant’s telephone number (Call.Ani) does not persist if the interaction transfers to another flow. But if you store the information into participant data, other flows can access that data.

Each participant attribute is a name and value string that the flow author configures. To set an attribute, specify its name and a string value to assign to the attribute. Participant data attributes are most useful to store information that you want to persist beyond the current flow. For example, information that you want to access from a different flow or information that leaves the current flow altogether. With participant data, a third-party integration such as Genesys Cloud for Salesforce can receive screen pop URL information that you set via participant data.

Notes:
  • Attributes are case-sensitive. If you use an existing attribute in another part of the flow, ensure you match the case of the original attribute.
  • For bot flows, these limitations apply. If you reach the limit, the session closes and the flow follows the configured error handling path.
    • The number of Set Participant Data action executions per bot session is 50.
    • The number of attributes that the flow sets during a bot session is 50.
    • The maximum length of an attribute value is 256 characters.
  • Because Set Participant Data requires an actual conversation with a conversation ID, the action does not work with the Architect Test option.
  • Genesys Cloud does not save attributes analytics after the conversation completes. If the conversation and segments are complete, analytics cannot reopen the conversation to save the changes. For example: 
    1. The incoming interaction and the inbound flow are active and some participant data is written in the flow, synchronized in Conversation Services and Analytics Services.
    2. The system transfers the interaction to a queue and it waits. The in-queue flow is active and some participant data is written in the flow, synchronized in Conversation Services and Analytics Services.
    3. The interaction routes to a queue and an agent accepts it. The agent script contains some participant data, synchronized in Conversation Services and Analytics Services.
    4. The customer disconnects and the agent reaches the wrap-up state. The agent script, triggered by the output variable in the script, includes more participant data, synchronized in Conversation Services, but not Analytics Services.
    5. The agent completes the wrap-up and the interaction view closes for that agent. Over API, another participant data for that interaction and that agent participant is set and synchronized in Conversation Services, but not Analytics Services.

    The Set Participant Data action in a task assigns an attribute value on an interaction participant. For example, if you have a Call Data action that looks up information for a participant, use the Set Participant data action to save the results of what the Call Data action finds. If Architect transfers the interaction to another flow, the second flow can recall the information through the Get Participant Data action so that the data action does not need to repeat.

    Note: When a Get Participant Data action recalls an attribute, ensure that the attribute name exactly matches the Set Participant Data name from the prior flow. Architect does not automatically complete participant data names across flows. To ensure a precise match, copy and paste the case-sensitive names.

    In voice flows, if a Set Participant Data Action sets a participant attribute value during an interaction, then the set value is read on subsequent Get Participant Data action interactions, even though the set value does not update in the cloud until flow termination. For example:

    1. If the flow issues a Get Participant Data action with “Foo” as the attribute name, the cloud returns “Hello” so that the variable bound to “Foo” in the Get Participant Data action is set to “Hello.”
    2. The flow then issues a Set Participant Data action with “Foo” as the attribute name and “Goodbye” as the value.
    3. The flow then repeats and issues a Get Participant Data action with “Foo” as the attribute name. The cloud returns “Hello” as before, as updates made via Set Participant Data are queued and only sent to the cloud just before to termination. However in this case, the variable bound to “Foo” is set to “Goodbye” because Get Participant Data uses any queued-for-update values before it uses what the cloud returns.
    Note: Unlike voice flows, bot flows do not maintain a queue for update list. Instead, Architect directly updates the participant data to the cloud.

    Action Description and use

    Name

    Type a distinctive name for the action. The label you enter here becomes the action’s name displayed in the task sequence.

    Add attribute to set

    Click next to Attribute and add a Name/Value pair configuration for an attribute. Multiple attributes (“participant data”) can be created and saved in a single Set Participant Data action.

    Attribute Name

    Assign a name to the attribute. The attribute name is a string literal and cannot be blank (empty). This name must exactly match for a Get Participant Data action to retrieve the value.

    Value To Assign

    Attribute (participant data) values are string literals or expressions, such as built-in variables, flow variables, or task variables you have created. Use the literal editor or expression editor to assign a string, variable, or expression value to the attribute. 

    Notes:
    • In voice flows, sometimes the attribute value of a participant changes while the participant proceeds through a flow that also changes the attribute value. The updates made via the Set Participant Data action are queued in memory until just before flow termination. However, bot flows send attributes immediately.
    • Updates go to the cloud in one batch. If multiple Set Participant Data action interactions occur by a flow against the same attribute, the value set in the last interaction wins.