From First Contact to Resolution: How FSO Orchestrates Work
In this article, we will provide an introduction and overview to the foundational building blocks that power the orchestration of work for your customers in Financial Services Operations:
- Interactions – how customer contact is captured across channels
- Case Types – what kind of work is being done
- Service Definitions – which specific service is being requested
- Tasks – how the work gets broken down and fulfilled
Together, these four concepts form the backbone of how FSO classifies, routes, and fulfills customer requests. Once you understand how they relate, everything else from workspace configuration to AI-powered routing, becomes simpler to expand from this core foundation.
Interactions: Where Every Customer Contact Begins
An Interaction is a record created when a customer engages directly with your institution through channels such as a phone call, chat session, email, or branch visit. It captures the initial customer touchpoint where the customer’s intent may still need to be understood.
Interactions are typically created before any case or work record is initiated and provide a place to capture the conversation, identify intent, and determine the appropriate action.
Self-service digital requests usually do not create an Interaction because the customer's intent is already known, and the request can move directly into a case or work process.
Think of an Interaction as the front door to service. It captures who the customer is, what channel they used to engage in, and why they're reaching out. From there, agents can create one or multiple cases to actually fulfill the request. Every time a customer "interacts" with an agent, you would not want to create a case every time, as it doesn't accurately reflect a unit of work (case) and the associated tracking such as status or SLAs would be difficult to manage.
Interactions exist in FSO on a table (appropriately named "Interaction"), and they act as a precursor to a case. As they are a table, in the Financial Services Workspace, Interactions appear in the Interactions list and are linked to their associated cases. An Interaction can be created automatically via an inbound channel (like a Virtual Agent chat) or manually by a Requester such as a branch worker or call center agent. From that Interaction, agents can also launch the Service Selector to quickly create the right type of case.
Interactions vs. Cases — An Interaction captures the interaction event. It's a record of what happened and when on that synchronous or asynchronous conversation. A Case captures the work; it's the record that gets routed, fulfilled, and resolved. One Interaction can result in multiple cases (e.g., a customer calls about both a card dispute and an address change).
FSO supports omnichannel Interactions out of the box, including phone/call center, chat (including Virtual Agent), email, walk-in/branch and social media. Interactions can also be associated with specific accounts, contacts, and consumers — as well as being assigned to specific contact center agents. All interactions are tracked centrally, giving agents full context regardless of how a customer reached out.
Case Types: Defining the Work
A Case Type represents the processes and data needed to resolve a specific type of customer issue. It defines the table structure, roles, business rules, workflows, and workspace experience for a given domain of work.
Example: A card dispute case type has different fields, fulfillment steps, and agent roles than a complaint case type — even though both are "cases" at the platform level.
The Case Type Hierarchy
FSO implements a hierarchical model, building up from the ServiceNow platform foundation:
|
Level |
Description |
|
CSM Case (Platform) |
The base case table in ServiceNow Customer Service Management. All FSO cases inherit from this. |
|
FSO Base Case |
Extends CSM Case with financial services-specific data model, roles, and business rules applicable to banks and insurers. |
|
Primary / Domain Case Type |
Extends FSO Base Case for a specific domain or Line of Business (e.g., Card Disputes, Complaints, Deposit Operations, Business Client Onboarding). |
|
Product / Line of Business Case Type (Example) |
Further extends the domain case type for a specific product or service line. |
When to Create a New Case Type
FSO best practice is to map your use case to an existing domain case type and extend it rather than building from scratch. Consider creating a new case type when:
- The process and tasks required differ significantly from any existing case type
- The request requires capturing different data attributes
- Different teams with different access requirements will fulfill the request
- Regulatory or compliance requirements necessitate separation
Best Practice: Even if you only have one case type today, always implement using the case type pattern. This may just be extending from the FSO Base Case table with your single custom case type, but this ensures your implementation can easily adopt new case types from FSO applications or custom builds in the future.
A Note on FSO Base Case vs. CSM Base Case
FSO domain case types extend from the FSO Base Case (sn_bom_case), which itself extends the CSM Case (sn_customerservice_case). The FSO Base Case adds financial services-specific fields, roles, business rules, and workflows— such as Financial Account reference fields, the Customer 360 view with financial accounts and transactions, and FSO-specific UI actions — that are shared across banking and insurance domains.
However, some FSO applications such as Complaint Management, extend from the CSM Case table (CSM Base --> FSO Complaint Base --> FSO Complaint Case) rather than the FSO Base Case. This is by design. Complaint management is a cross-industry capability, and extending from CSM Case keeps it flexible for institutions that may handle complaints across both financial and non-financial service lines.
In practice, this means your implementation may include case types from both hierarchies. Not only is that perfectly fine -- it’s further utilizing the value of FSO including CSM! Both share the same CSM platform foundation, both work in the Financial Services Workspace (built-on CSM Workspace), and both support the same Service Definition and Service Selector patterns. The key is to extend from the right base for your use case: use FSO Base Case when you need the financial services data model and FSO-specific business logic, and CSM Case when the use case is more generic or cross-industry. The platform supports both, and many production FSO implementations use a mix.
Service Definitions: Describing What You Offer
A Service Definition describes a specific service that a financial institution offers in support of a product or case type. Where a Case Type defines the domain and structure of work, a Service Definition defines a specific, named service within that domain, — complete with its own workflow, SLAs, and creation method, — such as playbooks, record producers, or forms.
Example: Within the Credit Card Service case type (sn_bom_credit_card_service), individual Service Definitions might include "Unblock a card," "Increase credit limit," and "Reissue a card." Each has its own intake form, flow, and SLA — but all share the same Credit Card Service case type table.
What Makes Up a Service Definition?
Each Service Definition can include:
- Service Definition Record – names the service and links it to a case type
- View access controls – controls which fields appear on the case form for this specific service
- Playbook – drives the fulfillment workflow and the steps agents follow
- SLAs – service-level agreements specific to this service
- Record Producer – an optional intake form for end users or agents to submit the request (available in the Financial Services Workspace as of the Zurich release)
- Service Category – groups related service definitions for easier navigation and access control
The library of Service Definitions can include FSO-specific definitions for each product and line of business, which you can use as-is or extend for your specific needs, as well as CSM service definitions such as general inquiries.
When to Use a Service Definition vs. a New Case Type
This is one of the most common questions when implementing FSO:
|
Scenario |
Recommendation |
|
New use case within an existing domain or same fulfiller team |
Create a Service Definition |
|
Different process, different state model, or different team |
Create a new Case Type |
|
New service within an existing product area (Product area: Cards → Service: Unblock a card) |
Create a Service Definition |
|
Strict access separation required between use cases |
Consider a new Case Type |
Tasks: How the Work Gets Done
If a Case represents the what — the customer's request — then Tasks represent the how — the individual steps required to fulfill that request. Tasks are the units of work that get assigned to back-office agents, specialists, and cross-functional teams to actually resolve a case.
Think of tasks as the operational heartbeat of a case. A customer may call to request a loan deferment, — that creates a single case. But fulfilling that request might require a loan agent to review the account, a credit agent to reassess risk, and a document agent to collect and verify supporting paperwork. Each of those is a separate task, assigned to the right team, tracked independently, and connected back to the parent case.
The Task Table Hierarchy
Just as FSO uses hierarchical case types, tasks follow their own table hierarchy:
|
Level |
Description |
|
Industry Task (sn_ind_task) |
The base task table at the industry level, providing foundational task structure. |
|
Financial Task (sn_bom_task) |
Extends Industry Task with FSO-specific fields and business rules. All FSO tasks — inquiry tasks, claim tasks, credit tasks, loan tasks — inherit from this table. |
|
Domain-Specific Task |
Further extends Financial Task for a specific application domain (e.g., Deposit Task, Loan Task, Treasury Task, Complaint Service Task, Credit Task, Document Task). |
This hierarchy mirrors the case type hierarchy, ensuring that tasks inherit the right data model, roles, and business logic for their domain.
How Tasks Are Created
Tasks in FSO are typically generated in a few different ways:
Playbook-driven (automated): When an agent updates a case and triggers a workflow, the associated playbook automatically generates the required tasks and routes them to the appropriate back-office teams using assignment rules. As one task is completed, the next task in the sequence is created automatically. This is the primary method — it ensures consistency and keeps the case moving through its lifecycle without manual intervention.
Ad hoc (manual): Agents can also create tasks directly from the Tasks tab on a case for any work that falls outside the standard playbook flow. This gives teams flexibility to handle exceptions without disrupting the structured process.
Flow Designer: Flows can create tasks as actions within automated processes, triggered by conditions or decision points. You can create custom flows and FSO ships with predefined flows for each application that generate tasks behind the scenes — where playbooks drive the sequential lifecycle, flows handle the conditional logic (e.g., dispute exceeds a threshold → create a review task).
Business Rules: Business rules on case or task tables create tasks in response to specific data changes — a field updates, a state transitions. For example, setting "Legal impact" to "Yes" on a complaint automatically generates a legal review task. Best suited for event-driven task creation rather than sequential orchestration.
Task Plan Templates: Templates define a reusable set of tasks that get applied to a case in bulk — all at once, each with its own assignment group and order. Useful when a case type has a standard, repeatable set of steps that don't require conditional branching, such as a fixed onboarding checklist.
Example: In a loan deferment case, the workflow automatically generates a loan task for account review, a credit task for risk reassessment, and a document task for collecting customer paperwork. Each task is assigned to the appropriate team via assignment rules — the loan agent, credit agent, and document agent, respectively. A new task is created when the previous one closes, moving the case through its stages.
Tasks and Playbooks
Tasks are tightly connected to Playbooks — the guided workflows that walk agents through case resolution. The playbook defines stages (such as Initiate, Due Diligence, Fulfillment), and within each stage, activities generate the specific tasks that need to be completed.
Tasks generated during playbook activities appear in the Tasks tab on the case, giving both the case owner and task assignees full visibility. Agents can work on tasks either from the playbook view (seeing the task in context of the overall case flow) or directly from their task list in the Financial Services Workspace.
Tasks vs. Cases — Key Distinctions
A Case is the customer-facing record. It tracks the overall request, owns the SLA, and represents the unit of work from the customer's perspective. A Task is the internal, operational record. It represents a specific step assigned to a specific team or agent — often invisible to the customer but essential to fulfilling the case.
One case typically spawns multiple tasks across different teams. A case can also spawn child cases when the scope of work crosses into a different case type domain entirely (e.g., a failed standing order case might create a child "Modify standing order" case). The distinction matters: use tasks when the work is a step within the same domain; use child cases when the work requires a different process, state model, or fulfillment team.
Common Task Types Across FSO Applications
FSO applications come with pre-built task types tailored to each domain:
|
Application |
Task Types |
|
Deposit Operations |
Deposit tasks (authorization, fulfillment, account updates) |
|
Loan Operations |
Loan tasks, Credit tasks, Document tasks |
|
Card Operations |
Credit card tasks, Document tasks |
|
Complaint Management |
Complaint service tasks, Quality control tasks |
|
Treasury Operations |
Treasury tasks, Document tasks |
|
Insurance Servicing |
Policy service tasks, Underwriting tasks, Document tasks |
|
Claims |
Claim adjuster tasks, Document Collection tasks |
|
Client/Business Lifecycle |
Lifecycle tasks, KYC tasks, Document Verification tasks |
Notice that Document tasks appear across nearly every application — this reflects FSO's shared Document Management capabilities, which handles document collection and verification as a horizontal capability regardless of domain.
A Note on FSO Financial Task vs. CSM Task
Similar to the case table hierarchy, FSO has its own task table lineage. The Financial Task (sn_bom_task) extends the Industry Task (sn_ind_task), which itself extends the platform Task (task) table. FSO domain-specific tasks — such as Deposit Tasks, Loan Tasks, Treasury Tasks, and Credit Tasks — all extend from Financial Task, inheriting FSO-specific fields and business rules tailored to financial services operations.
The CSM Task (sn_customerservice_task) follows a separate lineage, extending directly from the platform Task table. CSM Tasks are used for general customer service fulfillment — things like follow-up actions, general inquiries, or cross-industry work that doesn't require the financial services data model.
Just as with case types, your implementation may use both. FSO playbooks and workflows generate Financial Tasks for domain-specific fulfillment steps (loan review, document verification, credit assessment), while CSM Tasks may be used for more general follow-up work or when integrating with broader CSM processes. Both task types appear in the Financial Services Workspace, both support assignment rules and SLAs, and both can be linked to a parent case. The choice comes down to whether the task requires FSO-specific fields and business logic or whether a general-purpose CSM task is sufficient.
How They All Work Together
Here's how all four concepts connect in a typical agent workflow:
- A customer contacts the bank → an Interaction is created
- The agent launches the Service Selector from the Interaction
- The Service Selector presents available Service Definitions, organized by service category
- The agent selects a service (e.g., "Cancel personal standing order") → a Case is created on the appropriate Case Type table
- The case opens with the associated form view, record producer, or playbook to create the case — and SLA for that specific service
- The playbook triggers a workflow that generates Tasks — routed to the appropriate back-office teams (deposit agents, document agents, credit agents) via assignment rules
- As each task is completed, the next task is generated automatically, advancing the case through its playbook stages until resolution
Each layer adds precision: the Interaction captures the customer contact; the Case Type ensures the right team and data structure; the Service Definition ensures the right workflow and experience; and Tasks break the work into assignable, trackable steps that drive the case to completion.
What's Next
Now that you understand the foundational model, explore how to configure and extend these capabilities:
- Configuring Playbooks for FSO Applications – Review, customize, and extend the playbooks that drive task generation and guided case resolution across your lines of business.
- Enable and configure the Financial Services Service Selector in FSO – Empower agents to create any case or service request from anywhere in seconds—reducing errors and accelerating time-to-resolution.
- Streamlining Case Intake with Record Producer Launch – use Record Producers within the Financial Services Workspace for richer, service-specific intake that streamlines the agent and admin experience.
- Now Assist for CSM – Service Recommendations – Utilize AI to suggest the right service definition in the Service Selector based on context
- ServiceNow Docs: Service Definitions in FSO – Product documentation on configuring and extending service definitions
- ServiceNow Docs: Case Types in FSO – best practices and developer guidance for implementing and extending case types
