Best practices for setting up conversation schemas

AI-generated summary

Genesys Cloud's Get Conversation Data action in workflows retrieves attributes assigned to conversations using conversation ID and optional participant ID as inputs, storing retrieved values in flow variables and branching logic based on success or failure. The action enables personalizing customer experiences and routing interactions by accessing conversation data. Conversation schemas should store transient, interaction-specific context that varies between conversations, such as order details and delivery addresses, while persistent customer information like phone numbers and home addresses should be stored in External Contact records. Key use cases include filtering conversations by product codes to track metrics and tagging interactions with identifiers like flight numbers for reference. The conversation schema APIs are designed for historical search use cases rather than real-time decision-making; customers should avoid using these APIs for routing or other applications requiring subsecond availability if they cannot tolerate occasional intermittent lags of up to 5% or multiple hours. Organizations are limited to 50 active and inactive schemas; disabled schemas remain readable via API by schema version reference, but writing to their fields is no longer possible. Scripts and flows must be updated to use active schemas before disabling to prevent breaking changes.

The following use cases and the ideal setup example help you identify which conversation data is best suited for storing in conversation schemas instead of participant data.

Use cases

Supervisor: Filter conversations and view metrics by product code to track trends in handle time and volume.
Agent: Tag conversations with a flight number to easily find and reference past interactions related to that specific flight.

Example

A customer, John Doe, calls XYZ Pizza Shop to order some pizza. The customer’s delivery address is 25 Canadiana Drive, Toronto, ON. John Doe’s phone number is +1-555-123-4567 and his home address is 23 Main St, New York, NY.

The ideal setup resembles the following:

Conversation record links out to the External Contact record – John Doe’s phone number and his home address are stored in his External Contact record. This persistent context must be stored in the customer profile.
Order details and delivery address are stored in the conversation attribute record, which is linked to the conversation record by its conversation ID. This information (context) is transient, can change from one conversation to another, and must be stored in conversation attributes.

Considerations for conversation schema API usage

The APIs that are made available by the conversation schema service are designed to support historical search use cases where the downstream service or the user is not expecting subsecond availability of the data. Therefore, it is recommended that customers avoid using these APIs for real-time decision making (such as routing) if their application cannot tolerate an occasional (up to 5%) intermittent lags (of up to multiple hours). These APIs are not inherently designed to support such use cases.

All active and inactive schemas count toward the 50-schema limit for the organization. Although records created with a disabled schema remain accessible for reading via the API by referencing the schema version, writing data to the fields is no longer possible. Before disabling a schema, ensure that your scripts and flows are first updated with using an active schema to avoid breaking changes.

[NEXT] Was this article helpful?

Get user feedback about articles.

Best practices for setting up conversation schemas View summary

Use cases

Example

Considerations for conversation schema API usage

[NEXT] Was this article helpful?

Best practices for setting up conversation schemas