A caller reads a synthetic account code. In the saved playback, the code is silent, the request remains clear, and the transcript does not leak it. That is useful evidence. One preview is not.
Test Dynamics 365 call recording redaction as an end to end privacy control. Prove what is detected, muted, stored, unsupported, and what happens when audio cannot be matched safely to the transcript. Release only after stored evidence passes.
Define the protection you are promising
Microsoft's September 2026 Contact Center update describes post-call redaction that mutes model-identified sensitive audio, aligns transcript findings to recording intervals, and prevents a recording from proceeding when the sensitive transcript cannot be mapped safely to audio. It also describes stronger processing for stored voice interactions (Microsoft release notes).
That is not a promise that every spoken secret disappears everywhere. Write the boundary before testing. Name the call flow, agent version, workstream, recording mode, sensitive variables, stored transcript, stored audio, telemetry, exports, and every external destination. If the team cannot state which artifact should be redacted, it cannot recognize a leak.
Choose one task from your support operation. Use a non-production environment and invented values that resemble the protected format without belonging to anyone.
Build a small test pack with known answers
Create synthetic values for each supported sensitive field. Add nearby controls that must remain audible, such as a harmless order reference or product name. Then add negative cases that look similar but should not trigger. Redaction that mutes half the conversation is not safer if it makes the record unusable.
- 1Set the boundaryName the protected value, supported path and every stored artifact.
- 2Use synthetic speechTest invented values plus harmless lookalikes, different voices and timing.
- 3Run the full callWait for post-call processing instead of approving a live preview.
- 4Inspect every copyReview audio, transcript, trace, export and connected destinations separately.
- 5Release or stopApprove only when privacy and service reviewers accept the same evidence.
Include different speakers, pace, accent, background noise, corrections, and a sensitive value at the start of the first answer. Microsoft's Copilot Studio guidance documents a timing limitation in which the first response to the first question might not be redacted. It also says the test panel keeps unredacted values in Dataverse tracing so makers can inspect configuration. Never use real secrets in that panel (Microsoft sensitive data guidance).
| Evidence area | What to test | Passing evidence | Release blocker |
|---|---|---|---|
| Detection | Supported synthetic values and harmless lookalikes | Sensitive values are found while useful lookalikes remain | A critical value is missed or harmless speech is broadly muted |
| Audio timing | Values spoken quickly, slowly and after a correction | The complete sensitive interval is silent and adjacent words remain clear | Part of the value remains audible or useful context disappears |
| Transcript and logs | Stored transcript, trace and approved telemetry | Protected values are absent where the design promises protection | A value appears in a stored or exported artifact |
| Failure path | Interrupted processing and unmatched timing | The recording is withheld or clearly fails for review | An unsafe recording appears complete or successful |
| Recovery | Corrected setup followed by the same test pack | The original failure and rerun are both traceable | The team cannot identify which version produced the evidence |
Run the supported path and the unsafe alternatives
Start with the deterministic supported path. Collect the value through a Question node and mark its variable as sensitive. Verify that sensitivity follows the variable when it moves between supported topic inputs and outputs. Run the full call, wait for post-call processing, and inspect the stored result.
Then deliberately test the edges. The current Microsoft guidance says values received from connectors, HTTP calls, or Power Automate are not automatically redacted. Explicit writes to Dataverse are not protected by the variable setting. Generative orchestration and sending sensitive information to generative AI are also unsupported for this control. Those are not minor caveats. They define where the call design must stop, change path, or add a separately governed protection.
Keep the redaction test separate from broader voice AI quality testing. A call can sound natural and still store private audio. It can also protect the private interval while failing the customer's task. Both controls need to pass.
Inspect every copy after the call
Do not approve from the live transcript alone. Listen to the stored recording from before, through, and after every sensitive interval. Check the stored transcript, conversation record, authorized export, diagnostic trace, and any connected archive or analytics destination. If a shared inbox exposes the conversation to the next owner, verify what that person can hear and read.
Use two reviewers. The privacy reviewer checks that the protected value is gone. The service reviewer checks that enough context remains to understand the request, decision, and next action. Record exact evidence by test case, artifact, environment, build, reviewer, and time.
Do not copy a synthetic secret into screenshots or tickets. Refer to the test case identifier and expected class instead.
Treat the limits as design rules
Microsoft says sensitive variables are kept out of standard transcripts and platform logs, but external destinations remain the operator's responsibility. It also warns that enabling sensitive-property logging in Application Insights writes those values to logs. Keep that option off unless an approved diagnostic procedure specifically requires it, and clear the resulting data under the same procedure.
Do not assume whole-call transcript redaction from recording redaction. Microsoft's current table explicitly notes that Dynamics 365 Contact Center whole-call transcripts do not redact sensitive data in that scenario. If your design needs both audio and text protection, test each artifact and supported path independently.
This is also a boundary for AI workflows. Do not send a value into an unsupported model or tool path and expect the original sensitive flag to protect every destination.
Release one call flow with a named rollback owner
Start with one agent, one workstream, one recording mode, and a small trained group. Publish the approved test pack and rerun it after agent changes, connector changes, logging changes, platform updates, or a failed redaction event.
A privacy owner approves exposure controls. A service owner confirms the record is still useful. An administrator owns rollback and disables the flow when a blocker appears. If you need help mapping the stored copies and handoffs around the call, review the implementation path before expanding the rollout.
Frequently Asked Questions
Can we use a real card number to test redaction
No. Use invented values reserved for testing. The test panel and unsupported destinations can preserve unredacted values, so real secrets create unnecessary exposure.
Does muted audio prove the transcript is safe
No. Audio, whole-call transcripts, traces, Dataverse writes, exports, and external systems have different boundaries. Inspect each artifact separately.
What should happen when redaction cannot map text to audio
Treat it as a failed privacy control. The safe result is a withheld or clearly failed recording that a named owner investigates, not a recording that appears complete.
When should we rerun the test pack
Rerun after changes to the agent, sensitive variables, workstream, recording settings, connectors, logging, exports, or platform version, and after any redaction failure.
Want help applying this guide?Ask the DripTell team
From reading to action
Want help applying this to your business?
Share your details. We will read the article you are on and start with a useful answer for your team.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy
