How to Automatically Log Calls in Salesforce (and What Still Gets Missed)

Log a Call is the button on a Salesforce record, in the activity area of a lead, contact, account, or opportunity, that records a phone conversation that already happened. Under the hood it does not create a special call object. It creates a Task. The Task object has a picklist field called TaskSubtype with the values Task, Email, LinkedIn, ListEmail, Cadence, and Call, and the Salesforce object reference says the field provides standard subtypes to facilitate creating and searching for specific task subtypes and cannot be updated after creation. A logged call is a Task with TaskSubtype set to Call, a Subject such as Call, a Comments field for the notes, a WhoId pointing at the contact or lead, and a WhatId pointing at the opportunity or account. The Task object also carries call-specific fields that most reps never see: CallDurationInSeconds (duration of the call in seconds), CallType (Inbound, Internal, or Outbound), CallDisposition, and CallObject, which the reference describes as the name of a call center. Those fields exist because Salesforce expected telephony systems to fill them in programmatically. That is the whole premise of automatic call logging: something other than the rep creates that Task and fills those fields.

There is no global setting that makes Salesforce notice phone calls happening on a rep's mobile or desk phone. Automatic logging only happens when the call passes through a system that is wired to Salesforce. In practice there are four routes. First, Sales Dialer, Salesforce's own built-in calling. The Trailhead module describes it as letting you call contacts by clicking their phone number in Salesforce, automatically log your calls, and take notes in the app, and the auto-log behaviour is a checkbox: with Auto-log on, Salesforce logged all the call details automatically. Second, Salesforce Voice, the contact-center product formerly called Service Cloud Voice, now documented under Partner Contact Center. It creates a VoiceCall record for each call. Third, a third-party phone system connected through Open CTI, where the softphone vendor's JavaScript writes the Task itself. Fourth, a conversation intelligence or recording platform such as Gong that records the meeting, matches it to Salesforce records, and pushes an activity in through the API. If your reps' calls do not flow through one of these, the honest answer to can Salesforce automatically log calls is no, not for those calls. See the best tools to auto-update your CRM after sales calls for how the tool categories compare.

Both Salesforce-native calling products write a VoiceCall object, which the object reference describes as representing a call in Salesforce Voice, Sales Dialer, or other supported voice connectors. The useful detail is the ActivityId field on VoiceCall: it is a relationship field that refers to Task. So the VoiceCall holds the telephony facts (CallDurationInSeconds, CallEndDateTime, CallType, and for Salesforce Voice a Description text field where the agent can enter a summary of the call), and it links to the Task that appears in the activity timeline. The RelatedRecordId field associates the VoiceCall with an Account, Case, Contact, Lead, Opportunity, and a few other standard objects, so the call lands on the right record without the rep choosing it. Two practical notes from the same reference. Editing VoiceCall records requires Sales Dialer or Salesforce Voice permission sets, so a rep whose profile lacks them can place a call and have nothing editable afterward. And you can add up to 300 custom fields to VoiceCall, which is where teams that want call outcome codes or campaign tags usually put them. Pricing and edition availability for Sales Dialer and Salesforce Voice change often and are not covered here; check the current Salesforce add-on pricing page before planning around either.

If your team already runs on RingCentral, Dialpad, Aircall, Talkdesk, or a contact-center platform, the vendor's Salesforce integration almost certainly uses Open CTI. Salesforce describes Open CTI as a way to build and integrate third-party computer-telephony integration systems with Salesforce Call Center using a browser-based JavaScript API, with the softphone running inside the Salesforce page and no adapter installed on the rep's machine. The method that does the logging is saveLog, which the developer docs describe as saving or updating an object in Salesforce: the softphone passes an entityApiName of Task plus the fields to set (Subject, Status, WhoId, WhatId, CallDurationInSeconds, CallType, CallDisposition), and Salesforce creates the record. This is why most CTI vendors can promise automatic call logging: they fire saveLog when the call ends. The thing to know before building on it: Salesforce states that Open CTI is in maintenance mode and is scheduled for retirement in February 2028, that no new features are being added, and that it is deprecated and unavailable for newly created Agentforce Service orgs, with Salesforce Voice as the recommended path. Existing integrations keep working until then, but if you are picking a phone system in 2026, ask the vendor what their Salesforce Voice plan is.

Conversation intelligence platforms log calls from the other direction. They do not sit inside Salesforce; they record the Zoom, Meet, or dialer call, transcribe it, match participants to Salesforce contacts and the open opportunity, and then write to Salesforce. Gong's Salesforce integration FAQ describes two generations of this. Older integrations push a Task for each call, which is why the integration user needs write permission to Task. Newer setups push each call to a custom Conversation object and its children instead, and Gong notes that it performs one API call per recorded call, which creates approximately 25 additional child records, covering participants, topics, trackers, and rep stats. That volume matters: a team doing a few hundred calls a week is adding thousands of records a month, which is why Gong lets admins set a filter in the Salesforce integration settings so only the calls you need are exported. The upside is that these tools log calls that Salesforce could never see on its own, including video meetings. The limit is the same as every other mechanism in this article: what gets written is metadata about the call. The content of what was agreed stays in the transcript. We go deeper on the Gong path in our Gong Salesforce integration guide.

Einstein Activity Capture (EAC) is the feature people most often assume handles this, and it does not. Salesforce's considerations page is explicit that EAC syncs only emails and calendar events linked to the primary email address on the user's Salesforce record. It connects to Gmail or Microsoft 365, captures sent and received emails and calendar events, and shows them on the activity timeline. Phone calls are not in scope. A few other EAC facts worth knowing before you lean on it for activity reporting: email attachments do not sync, it can take up to 24 hours after initial setup before data appears in standard reports, captured emails and events are stored on Hyperforce and AWS infrastructure rather than in your Salesforce database unless Sync Email as Salesforce Activity is turned on, and users cannot delete emails that EAC adds. So if a calendar event for a customer call exists in Google Calendar, EAC will log that event. It will not know whether the call happened, how long it ran, or what was said. For the call itself you still need one of the four mechanisms above.

Once a Task or VoiceCall exists, Salesforce Flow can react to it. A record-triggered flow on Task where TaskSubtype equals Call can update a Last Call Date field on the account, create a follow-up task three days out, or post to a Slack channel. That is deterministic and safe to run unattended, because it only uses the structured fields the dialer wrote. The newer option is Einstein Conversation Insights (ECI), which adds invocable actions to Flow for pulling the call transcript and generated insights. Salesforce's own post-call automation guidance is careful about this. It says to wait until transcripts and insights are available before using them in flows, that this can take hours for processed transcripts, that video calls must be over a minute long to be processed, and that conversation actions should run asynchronously and be placed before database saves. Salesforce ships two example flows: Get Call Transcripts to Ground Data for Emails and Post Call Recap Emails, the second of which is a template that needs customising before reps can use it. Notice what those examples do: they draft an email. They do not change the opportunity. That restraint is deliberate, and it points at the real gap.

Every mechanism above answers the question did a call happen, with whom, for how long. None of them answers what did we agree to. On a typical customer call a CSM or SE commits to three or four things: send the security questionnaire by Thursday, loop in the solutions architect, push the renewal close date to the end of the quarter because procurement is slow, move the opportunity to Negotiation. The dialer logs a 34-minute outbound call. The transcript holds the four commitments. The CRM shows none of them until the rep types them in, and after the third back-to-back call of the afternoon, most reps do not. The tempting fix is to let a model read the transcript and write the fields directly. The problem is that stage, amount, close date, and owner are the fields that feed the forecast, and a model that misreads we might slip to next quarter as a confirmed close date change has just corrupted the pipeline with no one noticing. The pattern that holds up in practice has three steps: draft, approve, write. The model reads the transcript and drafts the proposed changes as a list, each one paired with the sentence that justified it. The rep approves, edits, or rejects each line in one place, which takes seconds because the reading is already done. Only approved changes are written to Salesforce, and every write is logged with who approved it, from which call, against which source sentence. Low-risk items such as the call log itself, meeting notes, and internal tasks can flow without approval. Anything that changes the meaning or money of a record waits for a human. We laid out the field-by-field split in AI CRM updates.

Start by getting the call logged at all, which means routing calls through Sales Dialer, Salesforce Voice, a CTI integration, or a recording tool, and confirming that reps have the Task edit permissions those tools require. Then decide which commitments matter for your team. For sales it is usually next step, next meeting date, stage, and close date; for customer success it is follow-up tasks, renewal risk notes, and tickets. Define which of those may be written automatically and which need a review. Wire the transcript source (ECI, Gong, Zoom, or Meet) to an extraction step that drafts the changes, put the drafts in front of the rep in a single queue, and write only what they approve, with an audit trail. Run it on real calls for two weeks, measure how many drafts were accepted unchanged, and only then widen the auto-write list. Mindlyft builds this as a post-call workflow for CS, SE, and TAM teams: calls in, drafted Salesforce updates and follow-ups out, reviewed in our ASTRA console before anything is written. We build the first workflow free so you can see it on your own calls and your own Salesforce org, and after that it is a subscription. If you want that, talk to us.