Every organization evaluating Salesforce Voice or Agentforce eventually asks a version of the same question: once a call goes into Salesforce, who controls it where is Salesforce data storage? Not who’s licensed to use it, who controls where the audio lives, who can access the transcript, and what happens if a regulator asks for proof.
To get real answers instead of marketing selling points, we sat down with Josh Peck, one of AMC’s developers who works on solving customer use cases day-to-day.
Data Control in Native Salesforce Voice
Q: Let’s start with the question everyone’s worried about. If we go native in Salesforce Voice, do we lose control of our data?
Josh: Not automatically, but you lose some of the flexibility you’d have with a control layer in front of it. Salesforce native voice control means Salesforce owns the telephony stack, call setup, media handling, and where the recording and transcript get written. Your admins still configure retention, access, and encryption settings inside Salesforce. What you give up is the ability to make routing and data-handling decisions before the call ever touches Salesforce.
That distinction matters more than it sounds. If your compliance team needs a call routed to a different destination based on content, or needs a transcript to never touch Salesforce at all for a certain client segment, native Salesforce Voice doesn’t give you that choice. The call is already there.
Q: So what’s different with a control layer like DaVinci in front of it?
Josh: DaVinci sits between your carrier and Salesforce. It doesn’t replace Salesforce Voice, it decides what gets there and how. That means you can make data-residency and compliance decisions, which calls get transcribed, which get routed around Salesforce entirely, which get flagged for stricter handling — before the call becomes a Salesforce record. You keep the option, not just the outcome.
Salesforce Data Storage: who owns what pieces?
Q: Where does call data live once it’s in Salesforce Voice: the audio, the transcript, all of it?
Josh: Salesforce data storage for voice breaks into a few pieces, and people usually assume it’s one blob when it’s not:
- Call metadata (who called, when, duration, disposition) lands as a Salesforce record, usually tied to a Voice Call object.
- Audio recordings are typically stored as files associated with that record, subject to whatever storage limits and retention rules your org has configured.
- Transcripts are generated either by Salesforce’s own transcription service or by a third-party engine you’ve connected, and stored as text tied to the same call record.
Here’s the part that trips people up: Salesforce transcription data ownership isn’t automatically the same as Salesforce data ownership. If you’re using a third-party transcription engine — Amazon Transcribe, Deepgram, Azure Speech, Google Cloud Speech — that vendor processes the audio before the text ever reaches Salesforce. That’s a separate data flow, a separate vendor relationship, and in a regulated environment, potentially a separate agreement you need in place.
How does HIPAA fit into this?
Q: Does going through a control layer instead of native Salesforce Voice make HIPAA compliance easier or harder?
Josh: Easier, generally, because you get a decision point before the call reaches Salesforce. With DaVinci in the path, you can route calls that are likely to contain PHI through a transcription engine you’ve already vetted and covered under BAA. You can also skip transcription entirely for certain call types, without reconfiguring Salesforce itself. Native Salesforce Voice can do some of this with configuration, but the logic lives inside the platform’s own rules rather than a layer you control independently of it.
Salesforce Data Storage and Bringing Your Own Telephony Carrier
Q: Zooming out: what are the real Salesforce Voice pros and cons, no marketing spin?
Josh: Pros:
- Calls, transcripts, and case history live in one system — no separate login to check.
- Native Einstein and Agentforce AI features work directly against the same data model, no integration lag.
- Simpler procurement: one vendor, one contract, one support line for the CRM and voice layer.
Cons: the Salesforce voice limitations worth knowing before you commit:
- Telephony and routing logic are governed by Salesforce’s configuration model, not a neutral layer you control.
- Third-party transcription and AI vendors sit outside Salesforce’s own BAA by default, which creates compliance gaps if nobody catches it.
- Changing carriers, adjusting routing logic, or supporting a hybrid AI/human model often means working within Salesforce’s release cadence rather than your own timeline.
- Number porting and carrier migration are still real projects if you’re moving fully native.
Q: And how does that compare in a Salesforce voice vs BYOC decision?
Josh: Bring Your Own Carrier isn’t really competing with Salesforce Voice, it’s a different layer of the stack. BYOC through DaVinci keeps your existing carrier, SIP trunks, and DID numbers exactly where they are, and gives you a control point that decides what reaches Salesforce, what goes to an AI agent, and what stays on your existing CCaaS. You’re not choosing Salesforce Voice or BYOC. You’re choosing whether Salesforce owns that control point, or you do.
For most compliance-sensitive organizations that distinction is the whole ballgame. Native gives you one throat to choke. A control layer gives you the ability to decide, call by call, what happens before it becomes somebody else’s data governance problem.
Going native in Salesforce Voice doesn’t mean losing control of your data outright, but it does mean accepting Salesforce data storage rules for where that data lives and how it’s covered. If your compliance requirements are strict, or you expect them to keep changing, a control layer in front of Salesforce gives you the room to make those calls yourself — literally.
