Domain separation and the CSM Walk-up Experience application

  • Release version: Yokohama
  • Updated January 30, 2025
  • 3 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 the CSM Walk-up Experience application

    The CSM Walk-up Experience application supportsBasic-level domain separation, enabling logical segregation of data, processes, and administrative tasks into domains. This separation controls user access to data and ensures interactions and records are confined to appropriate domains. While the application leverages the Service Portal, the portal itself does not support domain separation; however, data displayed on portal pages respects domain boundaries based on user context.

    Show full answer Show less

    Domain separation is crucial for service providers managing multiple tenants, ensuring that customer interactions and data remain isolated and secure within their respective domains.

    Key Features

    • Domain-Scoped Queues and Interactions: Walk-up location queues and interaction tickets are domain-separated, allowing only users within a domain to access relevant queues and tickets.
    • Configuration and Administration: Management of walk-up location queue records is domain-specific, enabling domain managers and admins to configure settings only for their domains.
    • Data Access in Service Portal: Although Service Portal elements (portals, widgets, themes) are not domain-separated, the data shown respects domain separation, allowing reuse of portal pages across domains with domain-specific data visibility.
    • Domain Field on Location Queues: The wulocationqueue table includes a Domain field to restrict queue visibility during online check-in to users within the domain.
    • Advanced Work Assignment (AWA) Support: Each location queue must include a routing condition referencing its domain to enable proper AWA functionality.
    • Requester and Fulfiller Domain Context: Requesters can only check in and select reasons within their domain, and interaction records are created in the requester’s domain. Fulfillers see and manage only records within their domain, global domain, or hierarchical parent-child domains.
    • Domain-Separated Tables: The application supports domain separation on key tables including walk-up location queues, reasons, many-to-many location queue reasons, contexts, and interactions.

    Important Considerations

    • The Appointment feature (itilappointment table) is not domain separated, which may expose appointment data across domains in list views.
    • Administrators should configure walk-up location queues and related tables carefully per domain to meet user needs and maintain data separation.
    • Separate Service Portals should be created for each managed service provider (MSP) customer to maintain domain separation at the portal level, given that portal components themselves cannot be domain separated.

    Practical Impact for ServiceNow Customers

    Implementing domain separation within the CSM Walk-up Experience application allows ServiceNow customers—especially MSPs—to securely manage multiple tenants on a single instance. It ensures that customer interactions, queues, and administrative configurations are isolated by domain, preserving data security and compliance. However, customers must be aware of limitations around Service Portal components and the appointment booking feature when planning their domain separation strategy.

    By configuring domain-specific queues, routing conditions, and respecting domain restrictions on users and fulfillers, customers can deliver a seamless multi-tenant walk-up experience that safeguards data visibility and operational boundaries.

    This section is an overview of domain separation as it pertains to the CSM Walk-up Experience application and how it relates to Service Portal pages, interaction queues, and configurations. 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.

    Overview

    Domain separation in the CSM Walk-up Experience application is supported at the Basic level. However, the application depends on the Service Portal, which is not supported for domain separation. Domain separation pertains to the CSM Walk-up Experience application in the following ways:

    • Walk-up location queues support domain separation to define which end users can access each location queue.
    • The Interaction table supports standard domain separation for data security. Interaction tickets are opened for a specific domain.
    • Walk-up location queues and interactions support domain separation. Therefore, fulfillers also work within a domain-separated environment when addressing interaction tickets associated with a location queue.
    • Management and administration configurations reside in the walk-up location queue records. Therefore, those configurations are available to the respective domain managers and admins.
    • While the Service Portal pages are not domain separated, the CSM Walk-up Experience application's portal pages retrieve data within the user’s specific domain. Therefore, those pages can be reused across different service portals designed and configured for separate domains. The admins must build each portal themselves.
    • The Domain field is available on the wu_location_queue table. Setting domain here ensures users only see queues that are part of their domains during online check-in.
    • For Advanced Work Assignment routing to operate, each wu_location_queue must include a work item routing condition. This condition explicitly adds a reference to the domain the queue is part of.
      Note:
      The appointment booking feature is not domain separated. Since Appointment [itil_appointment] table data is not domain separated, list views could reveal data across domains.

    How domain separation works in the CSM Walk-up Experience application

    For this application to be the most effective, walk-up administrators should configure walk-up locations accordingly. Configure the wu_location_queue record to meet a user need, which affects the requester experience. Each domain configured to the location queue record has its own set of rules. The same applies to other tables within the Walk-up application as well.
    Note:
    Elements of the Service Portal platform such as settings, portals, and widgets cannot be domain separated. However, the data within the widgets displays based on how the domain is configured. The recommended approach is to set up separate portals for each MSP customer.
    Elements of the Service Portal that are used as part of the walk-up experience are as follows:
    • Portal (Walk-up)
    • Pages ( walkup_online_checkin, walkup_queue_on_site, walkup_home, walkup_survey, walkup_check_in )
    • Theme (Walk-up theme)
    • Widgets (Online check-in experience, walk-up queue on site, walk-up check-in, walk-up exit survey, walk-up home, walk-up schedule)

    To learn more, see Domain separation and Service Portal.

    For data separation, the CSM Walk-up Experience application uses the walk-up user (Requester/Walkup login user) domain to determine in which domain the requester data should be placed.

    • Requesters can check in only in locations for which they have visibility.
    • Requesters are able to select the Reasons that belong only to their own domain.
    • Interaction records are created in the Requester’s domain.

    For the Fulfiller side, the application uses the domain of the walk-up user (walk-up technician/ manager/ admin) to determine which records are visible.

    • By domain separation rules, Fulfillers can work only on interactions that are visible to them.
    • Fulfillers are able to configure only walk-up location records that belong to their domain, are in the global domain, or have the parent-child hierarchy.
    • The same visibility rules apply for the Many to Many [wu_m2m_location_queue_reason]tables that control the mapping between a location and reason.
    • The walk-up context records also have domain separation support. This support ensures technicians to view detailed requester information only for the records that are visible by domain separation rules.

    Domain-separated tables

    As part of the CSM Walk-up Experience, records in the following tables can be domain separated.

    • Walk-up location queues [wu_location_queue]
    • Walk-up reasons for visit [wu_reason]
    • Walk-up reasons [wu_m2m_location_queue_reason]
    • Walk-up contexts [wu_context]
    • Interactions [interaction]