Hi Kevin,
Interesting use case - this comes up quite a bit with R2S when external access needs to be more granular than what the platform natively exposes.
Beyond the usual retention/tagging ideas, one approach you might want to consider is controlling exposure at the policy and retrieval layer rather than the recording itself:
🔐 Option 1: Policy-based exclusion (if using selective exposure via R2S config)
If your R2S integration is driven by policies (recording export criteria, filters, or API queries), you could:
- Apply a specific tag, wrap-up code, or participant attribute to that interaction
- Then explicitly exclude that attribute in the R2S export/query logic
👉 This way, the recording:
- Remains fully available inside Genesys Cloud
- Never gets exposed downstream to the third party
🧩 Option 2: Use Division / Permission Segmentation (often overlooked)
If your organization uses Divisions, another alternative is:
- Move or associate the interaction to a restricted division
- Ensure your R2S integration credentials or OAuth client are scoped only to certain divisions
💡 This is powerful because it:
- Doesn't modify the recording itself
- Uses native access control boundaries instead of data manipulation
🕒 Option 3: Delay + selective deletion in R2S layer
If recordings are already being pushed:
- Check if your R2S flow allows post-processing filters or delayed sync
- You could implement logic to:
- Identify the recording ID
- Prevent indexing or remove it only from the R2S repository (not Genesys Cloud)
⚠️ Important consideration
Genesys Cloud itself doesn't currently support a "hide from R2S but keep internal" toggle at recording level, so the key is:
Control who can fetch or receive the recording, not the recording object itself.
✅ Practical recommendation
If you want the least intrusive and most scalable solution, I'd go with:
Tag + exclusion at the integration/API query level
It's simple, auditable, and avoids restructuring permissions unless necessary.
Curious to know how your R2S integration is currently pulling recordings (bulk export, event-driven, API polling, etc.), as that can open up even more precise controls.
------------------------------
Cesar Padilla
INDRA COLOMBIA
------------------------------