PlatformIntermediate

Salesforce Console Integration Toolkit

Q: When do organizations use Salesforce Console Integration Toolkit?

A regional utility with a Classic support desk: Agents work outages alongside cases. A custom console component opens each outage record as a subtab under the case that raised it.

Q: What is the most important tip for working with Salesforce Console Integration Toolkit?

Check which API version your script include points at. Salesforce supports each toolkit version for a minimum of three years , and older ones may stop working.

Q: Where does a Salesforce Console Integration Toolkit method deliver its result?

Toolkit methods are asynchronous, so your script keeps running and the console invokes your callback once the result exists. Reading the value on the next line returns undefined, which is why nearly every method in the API takes a callback argument.

Q: A partner-hosted page renders as a console tab in Salesforce Classic, but every toolkit call silently does nothing. What should you check first?

Externally hosted code needs its domain listed under Allowed Domains when an admin edits the console app in Setup, otherwise the browser blocks the cross-origin calls. Nested iframes make the problem worse rather than better, since toolkit methods do not work inside them at all.

Q: Which statement about running toolkit code inside a Lightning console app is accurate?

Salesforce bridged version 42.0 and up so existing Visualforce pages and web tabs survive a move off Classic. The support is partial: record IDs return as 18 characters, tab IDs shift from formats like scc-pt-1 to ones like ctab1, and some method families are not supported.

The Salesforce Console Integration Toolkit is a browser-based JavaScript API that gives developers programmatic control over console apps in Salesforce Classic.

Hear it

§ 01

Definition

The Salesforce Console Integration Toolkit is a browser-based JavaScript API that gives developers programmatic control over console apps in Salesforce Classic. Code written against it opens primary tabs and subtabs, sets tab titles, reads tab IDs, and closes or refreshes tabs without reloading the whole page.

You load it as a script into a Visualforce page, or into a third-party page shown as a console tab. From there you call its methods from custom buttons, console components, or the embedded page itself. Salesforce still ships and supports it, and the Summer '26 documentation sits at API version 67.0.

It is the older of the two console APIs. For Lightning Experience, the Lightning Console JavaScript API replaced it, and that is where new console customization belongs.

§ 02

In plain English

👋 Study buddy

“Think of the Classic console as a browser with its own tabs living inside one Salesforce page. This toolkit is the remote control for those inner tabs. Your code can tell the page to open a tab, rename one, or shut one. The person using it never loses their place.”

§ 03

Worked example

scenario · real-world useSalesforce Console Integration Toolkit

A regional telecom support team runs a Classic console app called Care Desk. When an agent opens Case 00042318, a custom console component calls the toolkit's getFocusedPrimaryTabId method to find the tab holding that case. The component then calls openSubtab, passing the returned tab ID and a Visualforce page URL of /apex/OutageLookup?caseId=500Ax000001AbCd, with the subtab title set to Outage 4471. The outage record loads beside the case instead of on top of it. The agent reads it and closes the subtab. The case is still open and still scrolled to the same place. The unsaved note in the Description field survives too. Preserving that state is the whole point of the toolkit.

§ 04

How the toolkit hooks into a Classic console app

Tabs are almost the entire API

The Classic console workspace is a parent-and-child structure. A primary tab anchors whatever an agent is working, usually a case or an account. Subtabs hang underneath it for the related records they open next. That shape decides how you call the API. A subtab cannot float on its own. You pass the parent primary tab's ID when you open one. That is why most scripts begin by asking the console which primary tab has focus. The IDs that come back are console handles, not record IDs. Store the one your callback hands you and reuse it for every later call against that tab. One naming detail trips people up. A third-party page opened as a tab is named External Page unless you pass the tabLabel argument.

Loading the script and clearing the domain

You include one JavaScript file before you call anything. From a Visualforce page hosted by Salesforce, the include is a relative path such as /support/console/67.0/integration.js. The number is the API version, and the Summer '26 docs use 67.0. From a page hosted elsewhere, you point at the same file on your My Domain Visualforce host. External hosting adds a second requirement that has nothing to do with your code. In Setup, an admin opens Apps, edits the console app, and enters the external domain under Allowed Domains, with no http or https prefix. Salesforce used to label that section Whitelist Domains, so older write-ups send you looking for the wrong words. Skip the step and the browser blocks the cross-origin calls, and your toolkit calls fail quietly instead of throwing anything you can read.

Results arrive in callbacks, not on the next line

Most toolkit methods are asynchronous. They hand control straight back to your script and deliver the answer later, through a callback function you pass in as an argument. The documentation puts the trade plainly: the client-side process continues instead of waiting for a response. So a call that opens a subtab returns nothing useful right away. The tab ID and the success flag turn up inside the callback, whenever the console is ready. Developers with synchronous habits write a line that reads the result immediately after the call, and they get undefined every single time. Error handling makes this worse. Toolkit errors are emitted in a way that does not halt JavaScript processing, so a broken call can look exactly like nothing happening. Keep the browser devtools console open while you build.

Third-party cookies are the current sore spot

This is the failure that catches Classic console teams today, and it has nothing to do with Salesforce code quality. Salesforce states it plainly in the toolkit best practices. Visualforce pages cannot load in Salesforce Classic console apps when a browser has third-party cookies disabled. Browser vendors have spent years tightening those defaults, and plenty of users toggle the setting themselves. The result is a console that works on one machine and shows blank tabs on the next, with your JavaScript entirely innocent. Two smaller traps sit nearby. Toolkit methods do not work in nested iframes. A custom quick action in a feed still works on its own, because the feed sits in a single iframe. Switch on Development Mode in that org and the feed iframe ends up nested inside the Development Mode one, so the methods stop working. And passing an invalid URL to a tab method can open duplicate tabs, so check URLs for validity before you hand them over.

Running toolkit code inside Lightning Experience

Salesforce did not cut the toolkit off at the Lightning boundary. From API version 42.0 upward, many toolkit methods keep working from Visualforce pages and third-party web tabs inside Lightning console apps. Anything below 42.0 is not supported there at all. Support is partial, and the gaps are documented. Record IDs come back as 18-character case-insensitive values in Lightning, where Classic returned 15-character case-sensitive ones. Tab IDs change shape too, from strings like scc-pt-1 to ones like ctab1. Several arguments are ignored. Whole method families are missing, including name-based navigation, sidebar components, macros, and session timeout. Use this support to keep an existing console running while you move off Classic. Do not build new features on it.

Support policy, and what to build instead

The toolkit is not retired, and nothing on the Salesforce active retirements list points at it. It does sit under a version clock. Salesforce supports each toolkit version for a minimum of three years from its first release. Only the current release receives enhancements. Versions more than three years old may not be supported. Pinning a script include at a version from years back and forgetting about it is how a working console breaks on an ordinary Tuesday. For new work the answer is the Lightning Console JavaScript API, which is organized into three libraries. The Workspace API handles tabs and subtabs, the Utility Bar API opens and resizes utilities, and the Navigation Item API drives the console menu. Workspace and Utility Bar are callable from Lightning web components, while Navigation Item remains Aura only.

§ 05

How organizations use Salesforce Console Integration Toolkit

A regional utility with a Classic support desk

Agents work outages alongside cases. A custom console component opens each outage record as a subtab under the case that raised it.

A mid-market insurer partway through a Lightning rollout

It keeps its Visualforce console pages on toolkit API version 42.0 or above. The same tab-handling code then runs for claims staff still in Classic and for the teams already moved.

A 300-seat outsourced contact center

It embeds a vendor knowledge portal as a console tab and adds the vendor domain under Allowed Domains. The tab is retitled with whatever article the agent opened.

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Salesforce Console Integration Toolkit.

Salesforce Console Developer Guide (opens in new tab)Salesforce
Lightning Console JavaScript API (opens in new tab)Salesforce

Keep learning

Hands-on resources to go deeper on Salesforce Console Integration Toolkit.

Was this entry helpful?

Help us write better definitions. Quick reactions or detailed edit suggestions.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.