Domain separation and Financial Services Card Operations

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Domain Separation and Financial Services Card Operations

    Domain separation in Financial Services Card Operations allows for the logical grouping of data, processes, and administrative tasks into distinct domains. This enables control over data visibility and access for different users, ensuring that service providers can manage interactions effectively across multiple tenants.

    Show full answer Show less

    Key Features

    • Data Management: Ensures proper data allocation for service provider use cases, enhancing operational efficiency.
    • Runtime Support: Domain separation is active during runtime, affecting user interface, cache keys, reporting, and aggregations.
    • Domain-Separated Tables: Key tables such as Consumer, Account, and Contact are configured for domain separation, along with various credit card-related tables.

    Key Outcomes

    By leveraging domain separation, customers can:

    • Efficiently manage credit card requests through the Customer Service portal and Service Catalog.
    • Ensure that specific tasks and service cases are accurately assigned to agents, facilitating better tracking and resolution.
    • Utilize standard support levels for applications, even if not originally designed for domain separation, enhancing flexibility in configuration.

    Domain separation is supported for Financial Services Card Operations. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.

    Support level: Basic

    • Business logic: Ensure that data goes into the proper domain for the application’s service provider use cases.
    • The application supports domain separation at run time. The domain separation includes separation from the user interface, cache keys, reporting, rollups, and aggregations.
    • The owner of the instance must set up the application to function across multiple tenants.

    Sample use case: When a service provider (SP) uses chat to respond to a tenant-customer’s message, the customer must be able to see the SP's response.

    For more information on support levels, see Application support for domain separation.

    How domain separation works in Financial Services Card Operations

    All Financial Services Operations (FSO) applications are built on top of and use many CSM tables. The key reference tables are the customer tables such as Consumer, Account, and Contact, and these tables are domain-separated.

    Tables

    All tables added in Card Operations are domain-separated:
    • sn_bom_credit_card_base
    • sn_bom_credit_card_cardholder_dispute_intake
    • sn_bom_credit_card_case
    • sn_bom_credit_card_disputes_related_transaction
    • sn_bom_credit_card_disputes_service
    • sn_bom_credit_card_disputes_task
    • sn_bom_credit_card_disputes_transaction
    • sn_bom_credit_card_dispute_intake
    • sn_bom_credit_card_service
    • sn_bom_credit_card_task

    Use cases

    Credit Card Requests
    There are several different ServiceNow base system request types for credit cards, such as:
    • New credit card requests
    • Increase/decrease credit card limit
    • Block/unblock credit card
    • Close credit card
    • Dispute card transactions
    Customers create requests from the Customer Service portal (activated as a separate plugin).
    Front office workers (Branch workers, Call Center) create these requests on behalf of their customers via the Service Catalog and customer interactions.
    Each request type has a dedicated flow that triggers tasks from the parent credit card service case. Examples include:
    • Credit Card Service Cases are assigned to credit card agents, and used to track the overall credit card request and triggers all tasks.
    • Credit Card Tasks are assigned to credit card agents, and used for follow-up tasks that are triggered from credit card service cases.
    • Credit Assessment Tasks are assigned to credit assessment agents, and used in multiple workflows that go beyond credit cards.
    • Document Verification Tasks are assigned to document processor agents, and used in multiple workflows that go beyond credit cards.
    • Card Disputes Tasks are created for disputed transactions and assigned to card dispute agents, and are used to track the resolution progress for the dispute.
    Note:
    Sometimes a ServiceNow® platform feature or application may be able to effectively support service provider use cases even though the domain framework is not being used. In this case, the application may be assigned Basic*, Standard*, or Enhanced* for its domain support level, and include detailed use cases. For example: Before the New York release, Service Catalog had no domain support. But the instance owner was able to configure separate catalogs and items for each customer in a domain-separated instance. This allowed Service Catalog to be used at a Standard support level. To learn more, see domain separation Application levels of support.