Thanks Sesha. From what I can see, recording policies do not currently support participant data as a matching criterion. So if wrap-up is not an option, the only native policy-driven alternatives would be to express the logic through something a policy can already evaluate, such as queue, user, direction, duration, or customer participation. If the deciding value only exists in participant data at disconnect, I'm not aware of another native policy-only way to drive retention from that today. Hope this helps and someone might add more from the community.
------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------
Original Message:
Sent: 04-02-2026 09:56
From: Sesha Reddy Kalluri Venkata
Subject: How to apply recording retention by participant data that's only available at end‑of‑call (without API‑based delete/export)?
Thank you for the response Phaneedra. We have other use of wrap up codes and will not be able to have agents select the wrap up code required for the policy and the participant data will be updated in the post call flow.
------------------------------
Sesha Reddy Kalluri Venkata
------------------------------
Original Message:
Sent: 04-02-2026 01:01
From: Phaneendra Avatapalli
Subject: How to apply recording retention by participant data that's only available at end‑of‑call (without API‑based delete/export)?
Hi Sesha,
One way you can achieve this while keeping it policy-driven is to map your Participant Data logic to something policies can evaluate typically a wrap-up code. You can set the wrap-up based on your logic at the end of the interaction, and then apply different retention rules in the recording policy using that wrap-up.
Alternatively, if the criteria is known earlier, routing to specific queues and applying policies based on queue can also work.
Hope that helps, and keen to see if others from the community have a different way of approaching this.
------------------------------
Phaneendra
Technical Solutions Consultant