Salesforce Console Integration Toolkit
The Salesforce Console Integration Toolkit is a browser-based JavaScript API that gives developers programmatic access to the Salesforce console in Salesforce Classic.
Definition
The Salesforce Console Integration Toolkit is a browser-based JavaScript API that gives developers programmatic access to the Salesforce console in Salesforce Classic. Code written with it can open primary tabs and subtabs, set tab titles, read tab IDs, refresh or close tabs, and run other console actions without a full page reload.
It is a Classic-era tool. You load it into a Visualforce page or an allowlisted third-party domain, then call its methods from custom buttons, console components, or embedded pages. For Lightning Experience, Salesforce now provides the Lightning Console JavaScript API, which is the recommended path for new work.
How the toolkit drives the Classic console
What the toolkit actually controls
The toolkit exists to let you "implement custom functionality for the Salesforce console," and most of that functionality centers on tabs. The Service Cloud Console in Salesforce Classic uses a tabbed workspace. A primary tab holds a main record or page, and subtabs sit underneath it for related records the agent opens while working that case or account. The toolkit method set maps almost one to one onto these structures. You can open a new primary tab or subtab that displays a given URL, set the title of a primary tab or a subtab, return the ID of the current primary tab or subtab, and close a specified tab. Because the API talks to the console shell directly, these actions happen in place. An agent stays inside the same console session instead of losing context to a page refresh. That single behavior, keeping the workspace intact while pages change underneath it, is the whole reason the toolkit exists and the reason agents found the Classic console fast to work in.
Visualforce pages versus third-party domains
The toolkit ships as a JavaScript file you include before you call any of its methods. How you reference that file depends on where your code runs. Inside a Visualforce page hosted by Salesforce, you include the script with a relative path, for example a script tag pointing at /support/console/61.0/integration.js. The number in that path is the API version, and you should point at a current version rather than an old one. When your code lives on an external site, say a third-party web tab, you include the same file using a fully qualified URL on your My Domain Visualforce host. The third-party route has one extra requirement. An administrator must add the external domain to the console allowlist of approved domains, otherwise the browser blocks the cross-origin calls and the toolkit does nothing. Getting this include path and allowlist right is usually the first thing that trips up a new console customization, so it is worth checking before you debug your own JavaScript.
Asynchronous calls and callback functions
Toolkit methods do not block the browser. They run asynchronously, which means your client-side code keeps going instead of freezing while it waits for the console to respond. To read a result, you pass an extra argument called a callback function. The documentation puts it plainly: asynchronous calls let the client-side process continue instead of waiting for a callback from the server, and once the result is ready the server invokes the callback method with that result. In practice you call something like a method that opens a tab, and you hand it a small function that runs after the tab opens. That callback receives an object telling you whether the action succeeded and any IDs you asked for. This pattern feels familiar to anyone who has written event-driven JavaScript, but it catches people who expect a return value on the same line. If you try to use the result immediately after the call instead of inside the callback, it will not be there yet. Almost every toolkit method follows this shape, so learning it once carries across the whole API.
Where it fits, and where it does not
Salesforce frames the toolkit as an option for advanced administrators and developers, not an everyday point-and-click feature. A common job for it is to display Visualforce pages or third-party content as tabs in the console, so an agent can pull an external system into the same window as the case they are handling. That keeps the workflow in one place. The toolkit is browser-based though, which sets a hard boundary. It customizes the console interface and the tabs inside it. It does not run server logic, manage transactions, or move data between systems on its own. When a process needs that kind of work, Salesforce points you at SOAP API, Visualforce, and Apex instead, depending on whether you need web services, a custom page, or business logic. A realistic build pairs them. The toolkit handles the tabs and the on-screen behavior, while an Apex controller or web service behind a Visualforce page does the actual data work. Treating the toolkit as a UI layer, not an integration engine, keeps projects pointed at the right tool.
Why it is legacy now
The toolkit is tied to Salesforce Classic, and console work has moved to Lightning Experience. The successor is the Lightning Console JavaScript API, which gives programmatic access to Lightning console apps and integrates with Aura components and Lightning web components. It is organized into three libraries: a Workspace API for primary tabs and subtabs, a Utility Bar API for opening and resizing utilities, and a Navigation Item API for the navigation menu. Salesforce did build a bridge rather than a wall. Toolkit methods at API version 42.0 and above are supported inside the Lightning Console JavaScript API, so a Visualforce page or third-party web tab that points at a current toolkit script can keep working in Lightning Experience. The support is not total. Methods the toolkit offers that Lightning does not support return a failure error message, tab ID formats changed, and some features like custom styling and icons carry restrictions. Old code may run, but it should not be where you start. New console customization belongs on the Lightning Console JavaScript API.
Support policy and version lifecycle
The toolkit is not retired, but it sits under a clear lifecycle that matters for planning. Salesforce commits to supporting each Salesforce Console Integration Toolkit version for at least three years from the date of its first release. Only the current release receives enhancements. Earlier versions may or may not get fixes, and versions older than three years may stop being supported. When a version is scheduled to lose support, Salesforce gives an advance end-of-life notice at least one year ahead. Two habits follow from this. First, do not pin your script include to an old API version and forget it, because that version can age out from under a running customization. Point at a current version and revisit it on a release cadence. Second, treat any toolkit-based console as code you are maintaining, not extending. Keep it patched and working, but route genuinely new requirements to the Lightning Console JavaScript API so you are not adding to a Classic surface that is winding down. The lifecycle rules are generous, yet they still expect you to keep moving forward.
Enabling and wiring up the Console Integration Toolkit
You do not turn the toolkit on with a single switch. You enable the Service Cloud Console app, load the toolkit script where your code runs, and, for external code, allowlist the domain so the browser permits the calls. These steps prepare a Classic console to accept toolkit customizations.
- Confirm Service Cloud and a console app
The toolkit only works against a Salesforce console in Salesforce Classic with Service Cloud, on Enterprise, Unlimited, Performance, or Developer Edition. Make sure a console app exists and the agents who need it have access.
- Include the toolkit script
In a Visualforce page, add a script tag with a relative path such as /support/console/61.0/integration.js before your own code. From a third-party domain, use the fully qualified My Domain Visualforce URL to the same file. Use a current API version.
- Allowlist any external domain
If your JavaScript runs on a site outside Salesforce, an admin must add that domain to the console allowlist of approved domains. Without it the browser blocks the cross-origin toolkit calls and nothing happens.
- Call methods with callbacks
Invoke toolkit methods such as opening a primary tab or setting a tab title, and pass a callback function to read each result. Test inside the console, not a standalone browser tab, because the methods only respond within a console session.
The /support/console/<version>/integration.js file you reference; the version segment is the toolkit API version and should be kept current.
The console setting where admins list external domains permitted to call the toolkit; required for any third-party-hosted code.
The extra argument passed to each asynchronous method; the console invokes it with a result object once the action completes.
- The toolkit is Salesforce Classic only. In Lightning Experience, use the Lightning Console JavaScript API; only toolkit methods at API version 42.0 and above bridge into Lightning, and some return a failure error message.
- Results arrive in the callback, not as a return value on the same line. Reading the result immediately after the call gives you nothing.
- Third-party code fails silently if the domain is not on the console allowlist. Check the allowlist before debugging your own JavaScript.
- Pinning the include path to an old API version is risky. Versions more than three years old may lose support after a one-year end-of-life notice.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Salesforce Console Integration Toolkit.
Hands-on resources to go deeper on Salesforce Console Integration Toolkit.
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 Console Integration Toolkit?
Q2. Is it for Lightning?
Q3. What should new development use?
Discussion
Loading discussion…