When an AI voice agent finishes a call, Salesforce should already hold the result: the call logged as a completed task with an outcome, a disposition, and a link to the recording, plus whatever the call changed, whether that is a new or updated case, a follow-up task with an owner and a due date, or corrected fields such as a verified phone number. The test of a good integration is that a rep who opens the record five minutes later understands what happened without listening to the audio. How the agent writes this back varies by org: through Salesforce's APIs where the org allows integration access, or through a browser agent operating the same Salesforce screens staff use where it does not. This post covers what should be written, how the write-back works mechanically, what changes on Health Cloud, and what to check before connecting an agent.
What should an AI voice agent write back to Salesforce after a call?
Four kinds of write-back cover the routine cases. First, the call itself: a completed activity on the contact or lead, carrying the outcome, the disposition, the duration, a link to the recording, and a structured summary of what was said and decided. Second, the object the call was about: a case created for a new service issue, or an existing case updated with what the caller reported. Third, the follow-up: a task with an owner and a due date whenever the call ended with something owed, such as a document to send or a callback to make. Fourth, field updates: a phone number the caller corrected, an email verified on the call, a changed mailing address. The principle behind the list is that Salesforce is the system of record for customer contact, and a call that is not written back is invisible to reporting, to routing, and to the next person who picks up the account.
Want this mapped against your own call and claim volume? Book a 30-minute audit
How is the call itself logged in Salesforce?
Salesforce represents completed calls as activities, and in practice that means a Task record marked complete, related to the contact or lead who called and to the case or opportunity the call concerned. The subject line should say what the call was in plain language, the call result field should carry the disposition from a controlled list rather than free text, and the description should hold the summary and the recording link. The controlled disposition matters more than it looks: activity reports and dashboards group on it, so a manager can see reached versus voicemail versus resolved across hundreds of agent calls only if the agent writes the same values a human team would. In the deployments we run, the summary is structured the same way on each call, with the reason for the call, what was verified, what was done, and what remains open, so a rep can scan it in seconds.
The write-back is where a voice deployment succeeds or fails, because a call that leaves no record in the CRM has to be repeated by a person. Flexbone treats the Salesforce update as part of the call rather than a later step, and maps which fields matter from how the team uses Salesforce today. See AI voice agents.
When should a call create or update a Case?
A call should create a case when the caller reports a service issue that will outlive the call: a billing dispute, a delivery problem, a complaint, a request the agent could not resolve on the line. The agent opens the case with phone as the origin, a plain subject, the description of the issue in the caller's terms, and the contact attached. The harder discipline is updating instead of duplicating. When the caller references an existing open case, the agent should find it and add the new information to that case rather than opening a second one, because duplicate cases split the history and double the queue. That requires the agent to match the caller to the right record first, typically by phone number and email, and to search open cases on the matched contact before inserting. When the caller cannot be matched at all, the case still gets created with what is known, flagged for a person to reconcile.
See what AI can run at your facility. In a 30-minute audit we map the calls, eligibility, and follow-ups Flexbone can take off your team first.
Book an auditHow does the write-back actually happen?
There are two mechanical paths, and which one applies depends on the org rather than on the agent. The first is API-based: the voice agent platform authenticates as an integration user with a scoped permission set and writes through Salesforce's standard APIs, subject to the org's validation rules and duplicate rules like any other integration. This is the cleaner path where the org's edition, security review, and IT policy allow it. The second path exists because integration access is often constrained: a browser agent operates the same Salesforce UI staff use, signing in as a provisioned user, opening the record, logging the call, and filling the same fields on the same page layouts. It inherits that user's permissions exactly, which means it can write nothing a human with the same profile could not, and required fields and validation apply on save just as they do for staff. The same two paths apply to lighter CRMs; we cover the HubSpot version in HubSpot and AI phone agents.
What changes for healthcare organizations on Health Cloud?
Health Cloud is Salesforce's healthcare product, and because it runs on the same platform, the write-back mechanics do not change: calls log as activities, service issues become cases, follow-ups become tasks. What changes is the regulatory posture of the data. Call recordings, transcripts, and summaries in a healthcare organization contain protected health information, so the voice agent vendor operates as a business associate under HIPAA, signs a business associate agreement, and backs it with access controls, encryption in transit and at rest, and audit logging on everything that touches call content. The call volume being written back is real: an MGMA Stat poll found that 45% of practice leaders named eligibility and authorization work, and 31% named scheduling, as their most time-consuming phone tasks. One more distinction matters in these deployments: the EHR usually remains the clinical system of record, so the split between what the agent writes to Salesforce and what it writes to the EHR has to be defined up front rather than discovered later.
What should you check before connecting an agent to Salesforce?
Four checks separate a real integration from a demo. First, ask exactly which objects the agent writes and look at a sample record from a live deployment: a task with a disposition and a recording link reads very differently from a note pasted into a description field. Second, ask how the agent matches callers to records and what happens on no match and on multiple matches, and confirm the write-back respects the org's duplicate rules and matching rules instead of bypassing them. Third, ask what happens when a required field is unknown at the end of the call: the wrong answers are a silent write failure that loses the call from the CRM and a placeholder value that pollutes reporting, and the right answer is a defined review path. Fourth, ask where failed writes surface, because an integration that fails quietly is worse than none. If you want the checklist grounded in your own call types, talk to us and we will walk through it against your org.
An agent that answers calls well but writes nothing back leaves your team reconstructing each conversation from memory. If you are mapping what a voice agent should handle before you wire it to the CRM, start with the overview at AI voice agents.