Primary Tab
A Primary Tab is the main browser-like tab in the Salesforce Classic console that holds one main work item, such as a case, account, or contact.
Definition
A Primary Tab is the main browser-like tab in the Salesforce Classic console that holds one main work item, such as a case, account, or contact. Each primary tab can contain its own set of subtabs that display related records, so an agent keeps the parent record and everything attached to it inside a single workspace. Selecting a record from a list or navigation item opens it as a primary tab.
Primary tabs are a Salesforce Classic feature. The Console in Lightning Experience uses workspace tabs and subtabs to cover the same need, so primary tabs mostly come up when you maintain a Classic console app or plan a move to Lightning.
Primary tabs, subtabs, and life after the Classic console
How a primary tab anchors an agent's workspace
A primary tab represents the record an agent is actively working, and it sits along the top tab bar of the Classic console. When the agent opens a case, that case becomes a primary tab. Anything the agent opens from inside that case, such as the related account, contact, or a Knowledge article, opens as a subtab attached to that same primary tab. The result is a parent-and-children grouping that keeps context together. Salesforce does not cap how many tabs you can display at once, so an agent handling several customers can keep a separate primary tab open for each one. Switching between primary tabs swaps the entire working context, including all of that tab's subtabs, without forcing the agent to reload or hunt for related data. This model was built for high-volume service work, where reps move quickly between many open items and cannot afford to lose their place. The tab bar gives a constant visual map of every record in flight, and each tab carries small status indicators that surface unsaved changes or errors so nothing slips through unnoticed.
What separates a primary tab from a subtab
The split between primary tabs and subtabs is fixed, and understanding it prevents confusion when you configure or use a Classic console. A primary tab is always the top-level item, the thing the agent set out to work on. A subtab is always a child of one specific primary tab and shows a record related to that parent. You cannot promote a subtab into a primary tab or push a primary tab down into the subtab bar. Salesforce states that tabs maintain their status as primary tabs or subtabs, so dragging only reorders them within their own bar. Several behaviors reinforce this hierarchy. Clicking a custom button, or changing a record's type, owner, or territory, does not spawn a new tab. Instead the current tab goes to the item you selected, which keeps the tab count predictable. Subtabs let an agent flip between an account and its contact without leaving the account's primary tab. This is the main reason the console feels faster than standard navigation for support teams, since related data stays one click away rather than a full page load behind.
Navigating, pinning, and popping out tabs
The Classic console gives agents several ways to manage a crowded tab bar. You can drag a tab to a new position along its bar to group related work the way you prefer. Frequently used primary tabs can be pinned, which moves them to the front of the bar and strips their text to save horizontal space, leaving just the icon. Tabs can also be bookmarked, which sends them to the History component in the footer for later recall. If an agent closes something by accident, the console can reopen up to ten recently closed tabs, either from a menu or with a keyboard shortcut. When an administrator enables multi-monitor components, agents gain a stronger option. They can pop a primary tab out of the browser entirely and drag it to any spot on the screen, including a second monitor, then dock it back through the same menu. This suits agents who watch a live case on one display while researching the account on another. Keyboard shortcuts speed all of this up, and the whole point is to let a rep rearrange their space to match how they actually work a queue.
The developer side: the Classic Console Integration Toolkit
Primary tabs are not only a point-and-click feature. The Salesforce Console Integration Toolkit exposes JavaScript methods that open, focus, and control tabs from custom components and Visualforce pages. Methods such as openPrimaryTab open a new primary tab at a given URL, while openSubtab and openSubtabByPrimaryTabName open a subtab inside a named or referenced parent. Helper methods like getPrimaryTabIds and getSubtabIds return the identifiers of open tabs so your code can target a specific one. Others focus, refresh, or set the title of a tab by ID. Teams used these methods to build screen-pop behavior, so an inbound call could open the matching case as a primary tab with the caller's account already loaded as a subtab. That automation is a big part of why the Classic console shortened handle times. When you move a console to Lightning, this toolkit does not carry over unchanged. The Lightning equivalent is the workspace API, with methods like openTab, openSubtab, and getFocusedTabInfo, so any custom tab logic has to be rewritten against the new interface during migration.
Where primary tabs fit today: Classic versus Lightning
Primary tabs belong to the Salesforce Classic console, and Salesforce now points new console work toward the Console in Lightning Experience. In a Lightning console app, records open in workspace tabs, and related records opened from inside a workspace tab open as subtabs, which mirrors the primary-tab pattern closely. The naming changes from primary tab to workspace tab, and navigation rules in the Lightning app decide whether a related record opens as a fresh workspace tab or as a subtab. Lightning also adds patterns the Classic console never had, such as split view for working a list and a record side by side. Salesforce is direct that the two are not yet identical. The documentation notes that Lightning console apps do not yet have full parity with Salesforce Classic console apps, and it calls out examples like push notifications and custom keyboard shortcuts that were not available in Lightning at the time of writing. That gap is the practical reason to understand primary tabs.
Why primary tabs still earn space in a migration plan
Treating primary tabs as a settled legacy idea is the safe way to scope console work. A Classic console can carry years of muscle memory, custom buttons, and integration code wired to the primary-tab and subtab structure. None of that moves to Lightning by flipping a switch. When you audit a Classic console for migration, list every primary-tab behavior agents rely on, such as screen pops that open a case tab, multi-monitor pop-outs, and any Integration Toolkit calls. Then map each one to its Lightning counterpart, or flag it as a gap to redesign. Some map cleanly, since workspace tabs and subtabs behave much like primary tabs and subtabs. Others, like push notifications, were not at parity and need a different approach. Doing this mapping before the cutover keeps agents productive on day one rather than fighting an unfamiliar layout. So even though no new build should start on Classic primary tabs, the term stays useful for anyone maintaining, training on, or retiring a Salesforce Classic console.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Primary Tab.
Hands-on resources to go deeper on Primary Tab.
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 does a Primary Tab represent in the Salesforce Classic console?
Q2. What is the relationship between Primary Tabs and subtabs in the Classic console?
Q3. What is the current status of Primary Tabs as a Salesforce concept?
Discussion
Loading discussion…