Before a recent engagement with a telco's contact centre, the floor was running cases out of a standard Sales-style app. An agent would open the Cases tab, click into a case, and get thrown onto a full detail page that swallowed the sidebar. Switching to the next caller meant hitting back, losing the context they'd just built up, and hunting again for the contact, the account, the asset. With fifty agents each clearing sixty to eighty cases a day, that thirty-second lookup per case was a real tax, and it showed up directly in their average handle time.
The fix wasn't a new integration or a clever automation. It was the Service Console itself, configured properly. Once cases opened as workspaces with the related contact, account, asset and a Knowledge sidebar loading alongside them, lookup time dropped to a few seconds and handle time fell by close to a fifth. That's the thing about the console: it looks like cosmetic layout work, but the way you wire up tabs, subtabs and components is one of the largest levers you have on agent productivity. It's also where I see the most well-intentioned implementations go wrong.
This is a walk through how I actually set the console up for a support team, the decisions that matter, and the gotchas that only surface a few weeks after go-live.
Console Navigation is the whole point
The first decision is the navigation style on the Lightning app, and it's not a toggle to skim past. Standard Navigation gives you flat tabs: open a new record and it replaces whatever was in the tab. Console Navigation gives you workspace tabs and subtabs, and that distinction is the entire reason you're here.
A workspace tab is the parent. Each case an agent is handling opens as its own workspace, running across the top tab bar. A subtab is the child: when the agent clicks the contact lookup inside that case, the contact opens as a subtab underneath the case workspace, not on top of it. The case stays put. Close the workspace and every subtab beneath it closes with it. That single behaviour is what keeps an agent from losing their place mid-call.
When I configure the app I order the object tabs the way agents actually move through their day. Home first for the shift dashboard, then Cases, Contacts, Accounts, Assets, Knowledge, and reporting at the end. The utility bar carries the things agents reach for constantly: the softphone via Open CTI, History, the Macros panel, Notes, a To Do list. Worth knowing that the Service Console is desktop-only and lives entirely inside Lightning Experience. There's no mobile console and no embedding it elsewhere, so a field team on tablets needs a different answer.
Split View is the other navigation feature I reach for early. It puts a list on the left and the detail on the right in a single screen, which suits agents who live in a "My Open Cases" list all shift. The catch worth flagging to the client up front: Split View only applies to list views, not to related lists, and it doesn't persist. An agent toggles it on, closes the tab, reopens it, and it's gone. The workaround is to pin the list view tab, because pinned tabs hold their state across sessions.
Pinned tabs, default tabs, and the state you'll lose
Pinning is underrated. A pinned workspace tab stays anchored on the left of the bar and survives "Close All Tabs", and it persists across logins. I have agents pin their "My Open Cases" list view on their very first login so they always have a fast route home. You can only meaningfully pin one list view tab per user, so spend it well.
Separately, set the app's first-tab behaviour deliberately. You can have it load the last visited tab or a predefined one. For the telco I set it to a predefined Home tab so the shift dashboard comes up immediately and the floor lead can read real-time metrics without anyone navigating there.
Now the part clients always ask about and rarely like the answer to: tab persistence after a crash. Salesforce can remember an agent's open tabs and restore them, but only on a deliberate logout. When Chrome crashes with eight case workspaces open, the browser's memory is gone before the server ever knew about it, and there is no built-in restore. Agents who are used to "reopen last tab" in their browser find this genuinely annoying. The honest options are to accept it and train agents not to hoard more than about five workspaces, or to commission a custom component that snapshots tab state every couple of minutes and writes it somewhere it can read back on login. I usually steer clients to the discipline option first, because it's free and it also keeps the console fast. Past a dozen or so tabs the console starts to lag on an 8GB laptop, and the hard ceiling is twenty-five workspaces with thirty-five subtabs each.
The Highlights Panel is just your Compact Layout
This is the single most common misunderstanding I clear up. The Highlights Panel that sits across the top of a record, the strip that should let an agent absorb the key facts in about a second, doesn't have its own field configuration. It renders whatever the object's primary Compact Layout tells it to.
So when a bank wanted its ATM dispute cases to surface the dispute reference, the ATM identifier, the disputed amount and the status the instant a case opened, the work happened in Compact Layouts, not in the page builder. I built a Compact Layout for the ATM Dispute record type listing case number, subject, the dispute reference, the ATM lookup, the amount, status and priority, in that order, because the field order in the Compact Layout is the left-to-right order in the Highlights Panel. Then I assigned it to that record type specifically.
A few things I've learned to do every time. Build a separate Compact Layout per record type and assign it explicitly; if you leave everything on one default, an internet-outage case and an ATM dispute show the same useless strip of fields. Check field-level security before adding any custom field, because the Highlights Panel will happily render a field the agent's profile can't read and show a blank where the value should be, which generates a confused support ticket of its own. And keep it tight: five fields plus at most two action buttons. Cram in the full seven plus custom actions and the panel wraps onto a second line on a 1280px screen and looks broken. The same Compact Layout also drives the hover preview on lookups, so a clean one pays off in more than one place.
For everything below the highlights, I lean on the Related List - Single component rather than the catch-all Related Lists, picking the five related lists agents actually use and giving each its own column treatment, with Quick Links for fast jumps on dense pages. And where the status field maps to a real process, the Path component earns its place by forcing required fields and surfacing step-by-step guidance as the case moves.
Quick Actions and macros: where the clicks disappear
The last layer is the repetitive work. Quick Actions and macros are how you stop nibbling away at handle time one click at a time.
A Quick Action lives on the Highlights Panel and does one focused thing. At a hospital client, nurses needed to book follow-up appointments from inside a patient case. A "Create a Record" Quick Action targeting the appointment object, with the patient and doctor pre-filled from the case via predefined field values and a four-field form for the actual booking, turned a multi-step navigation into one modal. Predefined values are the real power here, but watch the data types: a formula that returns a string into a date field fails with an error the agent can't decode, so wrap with the right conversion functions and test before pushing.
Macros are for sequences on a single record. The telco's "close internet-slow case" macro selects the standard email template, inserts the relevant Knowledge article, sets status and resolution type, sends the email and saves, all from one keystroke. Because it sends mail it's an irreversible macro, so Salesforce prompts before running it. When the same fix applies to fifty cases after an outage, a Bulk Macro clears them from a list view in seconds, within the hundred-record-per-run limit. The thing to keep front of mind, and to tell the client plainly, is that a macro is not Apex. It runs as the agent and respects validation rules, field-level security and sharing exactly as a manual click would, and when a bulk run partially fails it tells you how many records failed but not which ones, so build a report to catch the stragglers.
Tying it all together is page assignment. Lightning Record Pages activate by app, then app plus record type, then app plus record type plus profile, with the most specific match winning. That's how the hospital gives doctors a page with lab results and prescriptions and nurses a page with schedules and vitals off the same record type. When a client swears their nurse page isn't showing, the answer is almost always a user sitting on the wrong profile, or an assignment ticked but never saved.
Get these layers right and the console stops being a screen agents fight and becomes the thing that quietly makes them faster. The principle I keep coming back to with clients is that console configuration is workflow design wearing a layout's clothes: every tab, field and action should map to a real step an agent takes on a real call, and anything that doesn't is just something else for them to scroll past.
Implementing or optimizing Service Cloud? Our Salesforce team runs discovery, designs the case process, and configures Service Cloud, Omni-Channel, and Knowledge on production engagements. Get in touch ->
See our full platform services for the stack we cover.
