Expanding and Tailoring the Financial Services Workspace
One Workspace. Every Line of Business.
As your Financial Services Operations footprint grows, a natural question that comes up comes up is: do I need a separate workspace for each line of business?
The short answer is no — and building separate workspaces can create fragmented experiences, additional administrative effort, and multiplies your maintenance responsibilities.
The Financial Services Workspace is designed to scale across lines of business through configuration of landing pages, page variants, and navigation – not more workspaces.
A single workspace can serve a Treasury team, a Cards team, and a Complaints team simultaneously — each seeing the right landing experience, the right navigation, and the right record pages for their role. This article explains the underlying model and the areas you need to configure to make it work.
The best practice is to consider there is only one workspace, but the views and experiences within it are relative to the beholder – which can be different lines of business or roles (For example, a contact center agent vs a card disputes analyst or a manager vs individual contributor).
Note: The Financial Services Workspace is the same fundamentally as the CSM/FSM workspace, renamed and customized for FSO. Overall documentation and best practice guidance is interchangeable for either. A great example of tailoring a single workspace!
The Core Principle
Think of the Financial Services Workspace as a single platform experience with persona-aware controls layered on top. Rather than cloning the workspace for each team, you configure conditions that determine what each user sees based on their role, group, or user criteria.
There are three areas where these conditions do the work:
- Landing pages and dashboards — what the user sees when they first log in
- Left navigation menu items — what lists and categories are visible
- Record pages and page variants — what experience opens when a user works a case
Each area is independently configurable, and all three work together to deliver a cohesive, role-appropriate experience without requiring separate workspaces per line of business.
Area 1: Landing Pages and Dashboards
The workspace landing page gives agents and managers an at-a-glance view of their work — open cases, high-priority items, team workload, and key metrics. The content each user sees depends on their role.
The right mental model here is dashboard selection, not separate landing pages per scoped app. Dashboards are the primary mechanism for delivering persona-appropriate landing experiences in the Financial Services Workspace.
To configure this:
- Use dashboards as the landing experience for each persona
- Apply conditions on each dashboard to control visibility (by role, user criteria, or group membership) and apply to case type
- Set a default dashboard per persona so users land in the right place automatically
What if a user belongs to multiple lines of business? The workspace won't automatically infer which experience to prioritize. You need to define precedence using one of two patterns:
|
Pattern |
How it works |
|
Default + picker |
Assign a default dashboard based on primary role; allow users to switch between dashboards as needed |
|
Role hierarchy |
Define a primary persona role, with secondary dashboards available optionally |
If a user matches multiple personas, you must define which landing experience takes priority — the workspace won't resolve this automatically.
Best Practice: Initial landing experience is typically driven by persona attributes (role, group, user criteria), not by the data on a case record. Save data-driven conditions for later in the workflow.
To modify landing page conditions, navigate to All > Platform Analytics > Dashboards, select the relevant dashboard, and edit via UI Builder.
Area 2: Left Navigation Menu Items
The left navigation panel is how agents access their lists — open cases, pending tasks, cases by category, and more. Like dashboards, menu items are conditional: you control exactly which items appear for which personas without cloning the workspace.
To extend navigation for a new line of business:
- Add menu items specific to that LOB
- Apply visibility conditions based on role, group, or user criteria
- Ensure each menu item points to the correct list definition for that work type
Common issue: Treasury (or any LOB) work not appearing in the left nav is almost always a configuration gap, not a workspace limitation. Validate the following:
- LOB-specific menu items exist in the workspace navigation
- Visibility conditions include the correct personas for that LOB
- Menu items point to the correct list definitions
Note: Work does not appear in navigation simply because a case type exists on the platform. You may need to explicitly expose it through navigation and list configuration.
Learn more: Configuring List Categories in the CSM/FSM Configurable Workspace
Area 3: Record Pages and Page Variants
When an agent opens a case, the workspace selects a record page to display. Out of the box, FSO ships with record pages that work well across most scenarios. For lines of business that require a specialized experience, you can create page variants — without rebuilding from scratch.
What is a page variant?
A page variant is a tailored version of a page that shares the same URL path but displays different content, layouts, or components based on specific conditions or audiences. Rather than creating a separate page for each persona or scenario, variants let you serve different experiences from a single URL.
Key concepts:
- Audience: User roles that have access to the variant. If no audience is assigned, every role has access to the variant
- Conditions: Rules that determine when a variant is shown
- Order: Each page variant has an order number. If you have multiple variants of a page, the page with the lowest order number takes precedence and is displayed.
The system evaluates variants in order, starting with the lowest order number. For each variant, it checks whether the user satisfies the conditions and audience. The first variant the user qualifies for is the one they see.
When to use a page variant?
Page variants are appropriate when different personas require a structurally different page with different components, different layouts, or different page templates at the same URL.
Some situations where a page variant is appropriate in the Financial Services Configurable Workspace:
- Structurally different landing pages by persona - When two personas do fundamentally different work and their landing experience needs to reflect that at the page composition level. For example, a customer service agent landing page built around individual case queues and quick actions versus a manager landing page built around team-level KPIs, SLA performance, and escalation views. When the components, widgets, and overall layout diverge significantly enough that a shared layout with conditional visibility would become unwieldy to build and maintain, a variant is the right tool.
- Structurally different record pages by persona or case type - When different personas or case types require a different page structure on the same record, including different fields, tabs, or components, a variant is the right tool. For example, a complaint case or onboarding case may need a different set of fields, layout, and components than a standard case (for a complaint case you might want to have a page layout that places complaint details prominently at the top), or a specialist may need a different record layout than a frontline agent.
When is a variant not needed?
Not every Financial Services Workspace customization requires a page variant.
Several changes can be made directly to the baseline record pages through page level configuration and workspace views & rules.
For list pages, Audiences and UX List Applicability let you surface different lists and list categories to different personas without requiring a variant for the list page.
Example scenarios with recommended configuration:
|
Scenario |
Recommended approach |
|
Add, remove, or reorder form fields for all users |
Page level configuration |
|
Add, remove, or reorder form fields by condition or persona |
Workspace View Rules |
|
Add, remove, or reorder related tabs on a record page |
Page level configuration |
|
Different list pages for different personas |
Audiences + UX List Applicability |
|
Change page layout (rearrange page, add or remove components) |
Page variant |
|
Add new tabs to the sidebar (contextual side panel) |
Page variant |
|
Different landing page layouts for different personas |
Page variant |
|
Show or hide components on landing pages for different personas |
Page variant
|
|
Different record page for different case types |
Page variant |
|
Different sets of audience for a case type record |
Page variant |
Tradeoffs when using variants
|
What you gain |
What you give up |
|
Tailored experiences with consistent URL
|
Upgrade blindness
|
|
Performance
|
Complexity & Maintenance overhead Every variant doubles your testing effort across patch and family releases. Variants can also fall out of sync over time as changes are made to one but not replicated across others. Troubleshooting why a user cannot see a page becomes harder as variants and order rules multiply. |
Best practices for page variants
- Exhaust lighter-weight options first: Before creating a variant, confirm that page level configuration, workspace view rules, or list applicability cannot achieve the outcome. Variants carry ongoing maintenance costs that these tools do not.
- Duplicate, don't start from scratch: Always duplicate the default variant of an out-of-the-box page rather than creating a new variant from scratch. Work in the correct application scope before duplicating or the result will not be editable.
- Ensure each role maps to the intended variant: Avoid assigning multiple variants to the same role unless a deliberate fallback is designed and documented. For instance, if an L1 agent role is assigned both a Front-line case page and the CSM Default Record Page, the platform evaluates both as candidates and surfaces whichever wins based on order and conditions, which may not match your intent. If a fallback is needed, document the intent explicitly to avoid any future confusion with misconfiguration.
- Keep variant count low: Each additional variant increases testing effort across every patch and family release. If a single page is accumulating many variants, treat that as a signal to revisit your approach.
- Document your variant logic: As conditions and audience rules multiply, it becomes difficult to debug why a specific user sees or does not see a page. Maintain clear notes on what each variant does and who it targets.
- Plan for upgrades: When ServiceNow releases updates to baseline pages, custom variants do not inherit them. Build upgrade review into your release cycle so variants benefit from the latest and greatest ServiceNow has to offer.
The recommended approach summary:
- Start with the out-of-the-box record pages and duplicate to customize.
- Add page variants only when a line of business requires a meaningfully different experience (mapped to roles)
- Leverage inheritance rather than rebuilding to future-proof: variants inherit related lists, UI actions, embedded components, and workspace behaviors from the base page
To target a specific LOB experience on a page variant, use conditions such as:
- Role-based conditions
- User criteria
- Data conditions, including case type (which maps to task type under the covers)
For a helpful walkthrough on page variants in UI Builder, see: Configuring Page Variants (Video)
Troubleshooting: Why LOB Work May Not Appear in Lists
This is one of the most frequent implementation questions — and the root cause is almost always with configuration, not workspace limitation. If cases for a new line of business aren't showing up in workspace lists, work through this diagnostic checklist in order.
Step 1 — Data model: Confirm the LOB case type extends from the base Case table (task > case). Workspace lists are built around standard table inheritance. If the case type extends from a custom task table instead, it will not appear in standard list filters.
Step 2 — List definition: Verify the workspace list filter includes the LOB case types. Out-of-the-box lists show all cases extending from Case — but list filters can be modified, and a case type can inadvertently be excluded.
Step 3 — Persona access: Confirm that LOB users have the required roles, user criteria, and read access to the case type table. Cases that exist but aren't accessible due to ACLs will not surface in lists.
Step 4 — Navigation wiring: Ensure a left nav item routes to the correct list or base Case table, and that it is visible to the LOB persona.
If you've completed all four steps and work is still not appearing, revisit the table design. Cases on non-standard task tables require additional list configuration to surface in the Financial Services Workspace.
Explore More:
Now that you understand how to scale the Financial Services Workspace across lines of business, explore how to configure the specific components covered in this article:
- ServiceNow Docs: Configure CSM Configurable Workspace — Full product documentation on workspace configuration including UI Builder, page variants, and navigation
- ServiceNow Docs: Create a Page Variant — Step-by-step guidance for extending record pages without rebuilding from scratch
