Domain separation and Insurance claims

  • 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 Insurance claims

    Domain separation in Insurance claims allows ServiceNow customers to logically separate data, processes, and administrative tasks within the application into distinct domains. This separation controls user access and visibility, supporting multi-tenant environments where service providers manage claims for multiple customers. The feature is supported at a Basic level and includes separation within the user interface, cache keys, reporting, rollups, and aggregations.

    Show full answer Show less

    Key Features

    • Run-time domain separation: Ensures that data is correctly partitioned per domain during application use.
    • Multi-tenant setup: Instance owners configure the application for multiple tenants, enabling isolated data and process management.
    • Domain-separated tables: Important tables such as Claim Case, Claim Task, Claim Adjuster Task, Incident Configurations, and various policy and incident tables are domain-separated to maintain data isolation.
    • Integration with Customer Service Management (CSM): Domain separation extends to key customer tables (Consumer, Account, Contact) used by Insurance claims, ensuring consistent data partitioning.
    • Support for service provider use cases: For example, ensuring that when a service provider responds to a tenant-customer’s chat message, the customer can view the response within their domain context.

    Practical Use Cases

    • Case Intake: First notice of loss (FNOL) intake agents collect and input claim information on behalf of customers, creating domain-specific claim cases for specialists to process.
    • Claims Analysis: Claims specialists review policy details, request additional documentation, manage reserve funds, modify coverage exposures, and make claim approval or denial decisions—all within the appropriate domain.

    Why This Matters

    Domain separation in Insurance claims enables organizations, especially service providers managing multiple tenants, to securely segregate data and processes. This ensures compliance, privacy, and tailored workflows per tenant while maintaining centralized application management.

    Additional Considerations

    The domain separation framework supports different levels of application support (Basic, Standard, Enhanced), depending on how domain separation is leveraged. Some ServiceNow platform features may offer effective multi-tenant support even without full domain framework use, as seen with Service Catalog before the New York release.

    Domain separation is supported for Insurance claims. 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 Insurance claims

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

    Tables

    The following tables in Insurance claims are domain-separated:
    • Claim Case [sn_ins_gen_claim_case]
    • Claim Task [sn_ins_gen_claim_task]
    • Claim Adjuster Task [sn_ins_gen_claim_adj_task]
    • Claim Incident Configuration [sn_ins_claim_incident_config]
    • Itemized Loss/Expense [sn_ins_claim_incident_item]
    • Baggage Incident [sn_ins_claim_baggage]
    • Trip Incident [sn_ins_claim_trip]
    • Personal Travel Policy [sn_bom_pt_ins_policy]
    • Commercial Travel Policy [sn_bom_ct_ins_policy]

    Use cases

    Case Intake

    The first notice of loss (FNOL) intake agents can intake information for an insurance claim on behalf of a customer.

    When the customer calls to file a claim, the intake agent gathers important information that is related to the claim. This can include a description of the incident, itemized losses, and any supporting documentation.

    After collecting the initial details, they open a claim case for a claims specialist to work on.

    Claims Analysis

    A claims specialist works on a claim that they receive through the workspace dashboard.

    The specialist reviews the policy details. If necessary, they can request and review the additional information or documentation from the claimant.

    The specialist sets the reserve funds, modifies the coverage exposures and reserve funds over time, and can also view all activity that is associated with handling the claim.

    The specialist can also make claim approval or denial decisions based on the available evidence.

    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.