Genesys Cloud - Developer Community!

Hello everyone,

We're facing a specific requirement from one of our customers and would appreciate your recommendations.

The customer requires that all personally identifiable information (PII) stored in Participant Data be encrypted after the interaction has ended. However, during the interaction, these values must remain available in the agent's screen script.

Our initial idea is to trigger a Workflow after the conversation ends, encrypt the sensitive Participant Data values, and then update the conversation with the encrypted values.

We have a few questions:

• Has anyone implemented a similar solution?
• Is using a Workflow to update Participant Data after the interaction the recommended approach, or is there a better alternative?
• Are there any limitations or best practices we should be aware of when updating Participant Data after the conversation has ended?
• What encryption method would you recommend for this scenario?

We initially considered using RSA, but the encrypted output becomes significantly larger than the original value, which could become a problem when storing Participant Data. Have you had better results using another encryption algorithm (for example, AES or another approach) while still maintaining strong security?

Any recommendations or real-world experiences would be greatly appreciated.

Thank you!

Hi Thiago, some things to consider:

• You asked about limitations working with Participant Data like that... There is only one thing that comes to mind, but I haven't had to deal with this issue for a few years, so no entirely sure if it still works like that... But... When you update a participant data after the conversation ends (Which will happen in your case if you make that update using a trigger/workflow, etc.), the updated value does not get updated into the Analytics APIs, the value in those keep what the participant data had at the time the conversation ended.... Like I said, not sure if this still works like that, so you might have to test, but keep it in mind.

• A different approach you could consider is encrypting the data before sending the conversation to the Agent (basically, encrypt it from the start, as soon as you write the Participant Data), and then decrypt it on the Script itself before displaying it to the agent)... This way it will always be encrypted in all stages, and you just decrypt the extracted value while using it on the Script.

Hello everyone, this is a very common and important requirement, especially for customers with strict data privacy and compliance mandates, and you are definitely on the right track with your initial thinking. Based on community discussions and Genesys documentation, using a Workflow triggered after a conversation ends is indeed a viable and recommended approach for redacting or encrypting Participant Data. Many organizations have implemented similar solutions to automatically mask or remove PII from Participant Data after an interaction is complete, with the goal of ensuring that this sensitive information remains available to agents during the interaction via their screen scripts but is not stored in a readable format afterward.

Your idea to use a Workflow is a strong one, and the most common pattern described by other Genesys Cloud users involves a few key components working together. First, you create a trigger in Genesys Cloud that fires when a conversation ends, with a frequently used topic for this being v2.detail.events.conversation.{id}.acd.end. This trigger then initiates a Workflow, and within that Workflow you invoke a Data Action. This Data Action uses the Genesys Cloud public API endpoint PATCH /api/v2/conversations/{conversationId}/participants/{participantId}/attributes to update the Participant Data attributes. This is a practical, documented approach that has been successfully used in production environments.

However, before you proceed, it is crucial to understand a significant limitation related to analytics. A key point from the official documentation states that analytics does not save attributes that are set after the conversation completes, and if the conversation and segments are already complete, analytics cannot reopen the conversation to save the changes. This means that while the Participant Data on the interaction record itself will be overwritten with the encrypted or masked value, this change will not be reflected in your Analytics and Reporting views. If you need to report on the original values, you will have to find a way to store them elsewhere before they are overwritten.

Regarding your question on encryption algorithms, your observation about RSA is accurate in that the encrypted output can become significantly larger than the original value, which is a consideration. While there is no specific Genesys documentation detailing a recommended algorithm for this exact use case, you have a couple of options to consider. The platform itself relies on AES-256 encryption for protecting data at rest, and AES is a symmetric encryption algorithm that is very efficient and produces an output of the same size as the input after padding, with its performance and straightforward key management making it a good candidate for this scenario. A practical strategy would be to use AES to encrypt the Participant Data values and then store the Base64-encoded AES-encrypted string in the Participant Data field. Alternatively, Genesys Cloud also offers a feature called Secured Customer Data, which allows you to store attributes encrypted with your own AWS KMS symmetric key. With this feature, you do not manually handle the encryption in your Workflow; instead, you configure the Genesys Cloud platform to encrypt the data at rest using your key, and it is worth exploring if this native capability could meet your requirement. It is important to note that you cannot assign secured customer data directly in a Set Screen Pop action, so you would still need to manage the data in your script workflow for agent visibility.

To summarize, you can use a Workflow triggered by a conversation-end event to update Participant Data after the interaction ends, and this is a documented and successful approach for redacting or encrypting PII. The primary limitation is that updates made after the conversation ends will not be saved to Analytics, so any reporting needs on the original data must be handled separately. For encryption, AES is a strong, efficient choice and aligns with the platform's own encryption standards, while the native Secured Customer Data feature with AWS KMS is another option worth investigating for easier management. While the community has validated the technical approach, it is always wise to test this thoroughly in a non-production environment to fully understand the behavior and ensure it meets your customer's specific compliance and reporting requirements. I hope this helps you move forward with your solution, and good luck with the implementation.

Looking at this from a different angle.  Why do you need that PII in participant data to begin with?

Hi Vaun, I'm assuming he doesn't actually need it, but when passing the inputs to the script they will be created as Participant Data by default.

If the assumption above is true, one other thing that you might consider @Thiago Miyaguchi, is trying to use "Conversation Attributes" instead of Participant Data.

It's kind of a new feature, and I haven't personally worked with it... But I believe the data in there doesn't currently get exposed anywhere (like participant data). So you might be able to just store all the information that you need in those attributes and then read everything on the script through Data Actions... This way there is no participant data storing all that and you don't need the encryption at all. (Of course, assuming the customer doesn't mind the value being stored in the Conversation Attribute APIs without encryption).

Hello, I have not solved the same scenario but something similar.
In you case I would solve it with the following steps;

• On the launch of the script run, as part of start page run a custom action
• In the custom action have the following steps
  • save the participant data into a new variable(s) and display these variable within the script for the agent
  • execute data-action(s) to encrypt and update the original participant data

The above should solve your issue, as reported by others, about the analytics data and also encrypt the PII fields while the call is on-going. Unless you have a large number of fields to encrypt & update, I believe the above should work.

Hope this helps.

Regards