Domain separation and Financial Services Card Operations

  • Release version: Xanadu
  • Updated August 1, 2024
  • 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 (FSO) allows ServiceNow customers to logically separate data, processes, and administrative tasks into distinct domains. This separation controls user access and visibility, supporting multi-tenant service provider scenarios. The instance owner is responsible for configuring the application to operate across multiple tenants, ensuring that data is routed correctly to each tenant’s domain.

    Show full answer Show less

    FSO supports domain separation at runtime, covering user interface, cache keys, reporting, rollups, and aggregations, enabling secure and efficient handling of credit card-related workflows in a multi-tenant environment.

    Key Features

    • Domain-separated tables: All FSO-specific tables such as credit card services, tasks, assessments, and document service tasks are domain-separated to maintain data isolation across tenants. Key customer reference tables like Consumer, Account, and Contact from Customer Service Management are also domain-separated.
    • Credit card request types: The solution supports six request types: new credit card, increase, decrease, block, unblock, and close credit card requests. These requests can be initiated by customers via the Customer Service portal or by front office workers through the Service Catalog and customer interactions.
    • Workflow and task management: Credit card service cases manage overall requests and assign tasks to credit card agents. Tasks are categorized into credit card tasks, credit assessment tasks (also used in Loan Operations), and document service tasks (used across workflows beyond credit cards).
    • Support level: Domain separation support for FSO is classified as Basic, meaning the application provides essential domain separation functionality suitable for service provider use cases.
    • Non-domain-separated properties: Two system properties related to credit card reservation hours are not domain-separated, which may be relevant for configuration considerations.

    Practical Implications for ServiceNow Customers

    • Implementing domain separation in FSO helps secure tenant data and ensures compliance with multi-tenant operational requirements.
    • Enables service providers to respond to tenant customers via chat or other channels while maintaining appropriate data visibility and segregation.
    • Supports comprehensive credit card lifecycle management through dedicated request types and workflows, improving operational efficiency in financial services contexts.
    • Requires instance owners to configure domain separation settings properly to leverage multi-tenant support effectively.

    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 FSO integrations 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_service
    • sn_bom_credit_card_task
    • sn_bom_credit_asmt_task
    • sn_bom_document_task
    • sn_bom_credit_card
    Note:
    There are two system properties that are not domain-separated for Card Operations:
    • sn_bom_credit_card.reserverd_hours_to_unblock_credit_card
    • sn_bom_credit_card.reserverd_hours_to_update_credit_limit

    Use cases

    Credit Card Requests
    There are six different ServiceNow base system request types for credit cards:
      • New Credit Card Requests
      • Increase Credit Requests
      • Decrease Credit Requests
      • Block Credit Card Requests
      • Unblock Credit Card Requests
      • Close Credit Card Requests
    Customers create these 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.
    • 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, such as Loan Operations.
    • Document Service Tasks are assigned to document service agents, and used in multiple workflows that go beyond credit cards, such as Loan Operations.
    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.