In today’s fast-paced business environment, it’s essential for an organization’s internal applications to be intuitive and well-organized. In this post, we will explore how we can leverage Salesforce’s Lightning Web Components (LWC) and the native
Business Use Case: An Employee Self-Service Portal
Let’s imagine we’re part of a mid-sized company looking to centralize HR and IT resources in a single Employee Portal. We want our colleagues to quickly access:
- HR Section:
- Employee Profile: where they can view and update personal details.
- Payroll: where they can check payslips and download tax documents.
- IT Section:
- Support Tickets: where they can submit or track IT requests.
- System Status: where they can see the current health of mission-critical applications.
Our goal is to use Salesforce as the platform and build a Lightning page component with no external frameworks, minimal or no custom CSS so that users enjoy consistent styling, keyboard accessibility and mobile responsiveness out of the box as per any business requirements.
Post following steps from this blog and implementation our screen will look like as below:

Actual Use Of The Approach
- Use Native Vertical Navigation: Standard Salesforce functionality or components provides
, andthat will help up for very less customizations. These are built on SLDS (Salesforce Lightning Design System), that will be giving us accessibility, focus management and visual consistency without doing anything new implementation or customization. - Define Sections and Items: We will group related navigation items under sections HR differentiating with IT and supply a name attribute to each item, which our JavaScript controller can use to determine which content to display.
- Implement Content Switching: In our JavaScript, we will track the selected item in a reactive property (@track selectedItem) and expose boolean getters (isProfile, isPayroll, etc.) to toggle which content template is rendered we may implement different scenarios as per any requirements.
- Expose on Lightning Pages: Finally, we will configure the component bundle’s XML to make it available on App, Record and Home pages as per our needs, so our Employee Portal can live wherever it’s most convenient.
Code Walkthrough
Below is the exact code we used in our org. That can be copy, paste and deploy as-is. Note that we have set the API version to 64.0, but can adjust this to match the org’s version.
verticalNav.html:
Employee Profile: View and update your personal details.
Payroll: Check your latest payslips and tax documents.
Support Tickets: Submit or track IT support requests.
System Status: See current availability of key applications.
verticalNav.js
import { LightningElement, track } from 'lwc';
export default class VerticalNavigation extends LightningElement {
@track selectedItem = 'profile'; // default view
handleSelect(event) {
// event.detail.name it will give the name of the clicked item
this.selectedItem = event.detail.name;
}
// getters to drive conditional templates
get isProfile() {
return this.selectedItem === 'profile';
}
get isPayroll() {
return this.selectedItem === 'payroll';
}
get isTickets() {
return this.selectedItem === 'tickets';
}
get isStatus() {
return this.selectedItem === 'status';
}
}
verticalNav.js-meta.xml
64.0
true
lightning__AppPage
lightning__RecordPage
lightning__HomePage
Best Practices of Vertical Navigation in LWC
1. Why Vertical Navigation?
Vertical navigation helps us surface multiple categories in a compact, logical structure. In an Employee Portal scenario:
- We keep HR and IT resources separate, so users immediately know where to look.
- We avoid page clutter by loading a single content panel rather than multiple unrelated sections.
- We preserve whitespace and mobile responsiveness.
2. Sections vs. Items
this will group the related items under a shared header that will improve scannability. this will represent a single navigation link. The name attribute should be unique and short; it drives our JS logic.
3. Reactivity and Template Rendering
Using @track selectedItem ensures that when a user selects a new item, the component re-renders the correct block. The boolean getters (isProfile, etc.) make our markup clean:
4. Event Handling
The onselect event on
5. Exposing the Component
In our XML configuration, we expose the component to App, Record, and Home pages. If desired, we can extend it to Utility Bar or Experience Builder by adding additional
Below are the few screenshots once we clicked on different sections on UI:
Employee Profile:

Payroll:

Support Tickets:

System Status:

Advantages of Using in LWC
- Native SLDS Styling: We don’t write custom CSS for active states, hover effects or focus rings. Salesforce maintains SLDS, so our nav always looks on-brand.
- Accessibility Out of the Box: Keyboard navigation and screen-reader announcements come built into these base components.
- Maintainability: By relying on standard markup, future edits (new items, renaming) require minimal code changes or no CSS classes to figure out.
- Performance: Base components are optimized for performance and minimal reflows. Our small JS controller only handles state, not DOM manipulation.
- Consistency Across Products: If we later use the same style in other internal tools, the look and feel remain consistent, reducing training overhead.
Conclusion
By combining this Salesforce’s native
Happy coding and may this pattern serve as a building block for many more internal applications 🙂