Interaction Log
An Interaction Log is a Salesforce Classic console feature that gives agents a note-taking panel in the footer of a primary tab, then saves what they type as a Task on the record's Activity History related list.
Definition
An Interaction Log is a Salesforce Classic console feature that gives agents a note-taking panel in the footer of a primary tab, then saves what they type as a Task on the record's Activity History related list. It appears in the Salesforce Console (the Service Console and the Sales Console), where an agent can jot notes during a call or chat without leaving the open record. The log always includes an "Enter your notes here..." field, and admins can add other editable Task fields such as a subject, a status, or a custom disposition picklist.
This is older console plumbing, tied specifically to Salesforce Classic. Lightning Experience does not use Interaction Logs. The equivalent work in a Lightning console happens through the Activity Timeline and the Log a Call action, which write the same underlying Task records. If you are building a contact center today, treat the Interaction Log as legacy and plan note capture around Lightning activities instead.
How the Interaction Log captured agent notes
A footer panel on the primary tab
The Interaction Log lived in the footer of a Salesforce Console primary tab, not as a separate page or a Lightning component. When an agent opened a record like a Case or a Contact in the console, the log sat at the bottom of the screen, ready for typing. The agent never navigated away from the open conversation to take notes, which was the whole point. Note-taking stayed inline with the call or chat. The log was only available on records that have an Activity History related list, so accounts, contacts, leads, opportunities, and cases qualified. Records without that related list, such as Solutions or Reports, did not show the log. Salesforce console apps were also unavailable to portal users, so the log could not be assigned to a portal profile. These constraints came straight from where the feature stored its data: a Task. If a record could not hold a Task in its Activity History, it could not hold an interaction log either.
Notes are saved as Tasks
Every Interaction Log entry became a standard Task. That single fact explains most of the feature's behavior. The notes the agent typed went into the Task, the subject and status fields on the log were Task fields, and the saved record landed in the Activity History related list of the open record. There was no separate "interaction" object behind the scenes. The log was a thin, console-friendly wrapper around the Activity model that the rest of Salesforce already understood. Because the data was a Task, everything downstream of Tasks worked without extra effort. Reports and list views that filtered on Tasks picked up interaction notes automatically. Validation rules on the Task object fired when an agent saved a log, which is how teams enforced required disposition codes. Roll-up patterns, activity reporting, and assignment behavior all applied. An admin who already knew the Task object knew most of what the Interaction Log did, because the two are the same data under different chrome.
Interaction Log Layouts control the fields
Admins did not configure the log on a page layout the way they configure most things. The fields came from a separate Setup area called Interaction Log Layouts. An admin created a new layout, named it, and chose which editable Task fields to include. The "Enter your notes here..." field was added to every layout automatically and could not be removed, since notes were the reason the feature existed. Custom Task fields were fair game here. A contact center that wanted a Caller Disposition picklist created it as a custom field on Task, then added it to the interaction log layout so agents saw it in the footer. One layout could be marked as the default for the whole org. After building the layouts, the admin used Log Layout Assignment to map each layout to a user profile, so different teams could see different fields. All of this required the Customize Application permission, which is why it sat with admins rather than support managers.
Turning the log on for a console
Creating an interaction log layout did not make the log appear. It also had to be turned on for the page layouts used in the console. An admin edited a record's page layout, opened Layout Properties, and selected the Interaction Log checkbox. Only then did the footer panel show up when that record opened in a console. Turning the setting on or off did not take effect on records that were already open, so agents had to close and reopen a tab to see the change. This two-step setup, build the interaction log layout and then enable it on the page layout, tripped up a lot of admins. Forgetting either half left agents staring at a console with no log. The split existed because the page layout decided whether the panel appeared at all, while the interaction log layout decided which fields filled it once it did.
Softphone and CTI integration
The Interaction Log paired naturally with telephony. When a softphone built on Open CTI was present in the console, an agent on a call could click Add Call Data to pull call details into the log before saving. The result was a Task that combined the agent's typed notes with structured call metadata, all on the related record's Activity History. This is the workflow most people picture when they think of an interaction log: answer a call, type while you talk, save a record of it. Clearing the panel did not destroy saved work. If an agent clicked Clear Log to wipe the notes or subject, any notes that had already been saved stayed put as Tasks in the Activity History. The clear action reset the footer for the next interaction rather than deleting history. When a contact appeared on a subtab, the console even pre-filled that contact into the log's Name field, though the agent could change it before saving.
Why it is legacy, and what replaced it
The Interaction Log is bound to the Salesforce Console in Salesforce Classic. Lightning Experience consoles do not have it. As orgs moved to Lightning, the feature stopped being the way agents capture call and chat notes, even though the documentation for it still exists under the Classic console pages. Salesforce did not port the footer panel to Lightning. It pointed the same job at a different surface. In a Lightning console, agents work the Activity Timeline on the record. The Log a Call action and other activity actions open a composer where the agent types notes and call details, then saves a Task that appears in the timeline. The data model is identical to the Classic log, since both write Tasks, but the experience is the Lightning composer rather than a fixed footer. Service Cloud Voice goes further, pre-filling call records and transcripts so the agent edits rather than types from scratch. If you are designing note capture now, build around Lightning activities and treat the Interaction Log as documentation for older Classic orgs.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Interaction Log.
Hands-on resources to go deeper on Interaction Log.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the Interaction Log?
Q2. Why does the Interaction Log matter?
Q3. Where does the Interaction Log appear?
Discussion
Loading discussion…