Sometimes it’s easier to start from the user’s need or the design requirement, and then determine which navigation component fits best. The table below maps common navigation needs in a workspace to the recommended components to use, with reasoning:
| Requirement | Recommended Component | Explanation |
|---|---|---|
| Allow user to multitask between multiple records or views | Workspace tabs | When users need to have several records or pages open simultaneously and switch quickly, use Workspace tabs. Workspace tabs (built into the Workspace shell) let each record or page have its own tab in the UI, preserving state. This is ideal for agents handling multiple cases at once or referring to one page while working on another. It prevents losing context – e.g., an agent can open a new incident in a separate tab while still viewing an ongoing case. Make sure the workspace is configured to open items in new tabs for this to work. |
| Present multiple sections of content on one page (not record-specific) | Tabs (Tab set) | When a single page needs to show different content sections or functional views that are related but distinct, a generic Tabs component is appropriate. For instance, a dashboard might have an “Overview” tab and a “Metrics” tab, or a form might have “Summary” vs “Details” tabs for optional info. Tabs allow the user to switch context within the page without navigating away. Choose Tabs whenever you find yourself considering multiple panels or accordions but want a clearer, single-click switch between them. Avoid using tabs for step-by-step processes or if there’s only one section to display. |
| Organize a lot of information within one record | Record Tabs | If a record (like an incident or customer record) contains multiple categories of information (forms, related lists, attachments, etc.), use Record tabs on the record’s page to break it up. Each tab can host a related list or a section of the form, helping users find the info they need without scrolling endlessly. Record tabs keep the context tied to the same record, which is important for clarity. Use this when there are logically distinct groups of fields or related data; for example, “Details” vs “Related items” on a record. If the record info is very minimal, you might not need tabs at all – a single page would do. |
| Navigate between various lists of records | List Menu (with List component) | If the user needs to quickly jump between different lists (queries) of records – for example, different queues or categories – the List Menu is the best choice. It provides a consistent left-hand navigation for lists (much like email folders in an email client). Use it to house both predefined list views (admin-set favorites) and user-created filters under a “My Lists” section. The List Menu should be paired with a List component that displays the content of the selected list. This setup is great for workspaces where an agent frequently switches contexts, like from “All Open Cases” to “My Cases” to “High Priority Cases” with a single click. It avoids having separate pages for each filter and keeps navigation quick. |
| Avoid overwhelming the user with too much at once | Use Tabs or separate pages, as needed | This is a more general guideline: if a single page or record has too much content, consider using navigational components to segment it. For example, use Record Tabs to split up a record form that’s very large, or use Tabs or multiple pages if one screen is too crowded. Conversely, if the content is minimal, do not introduce extra navigation. For instance, don’t use a Tabs component if there’s nothing meaningful to separate – one well-designed page is better. Similarly, don’t add a List Menu if the user only ever needs one list view. The goal is to provide just enough navigation to make the UI clear without unnecessary clicks. |