Domain separation and EMR Help

  • 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 EMR Help

    The EMR Help application supportsdomain separation, allowing ServiceNow customers to logically segregate data, processes, and administrative tasks into distinct domains. This separation controls user access and visibility, ensuring data integrity and privacy across multiple tenants or service providers. Domain separation is implemented at runtime and affects the user interface, caching, reporting, rollups, and aggregations.

    Show full answer Show less

    This capability is especially relevant for service providers using EMR Help to manage IT service requests from multiple tenant customers within Electronic Medical Record (EMR) systems.

    Key Features

    • Domain-separated configuration tables: Includes request definitions, request parameters, and their mappings, enabling domain-specific configurations.
    • Domain-separated transactional data: Tasks and related request data created via record producers or REST APIs are assigned to specific domains.
    • Domain determination logic: For EMR Help service portals, the domain is set based on the logged-in user’s session. For Remote help request API calls, administrators can specify domain assignment using parameters such as taskfor (taskfor user) and callerid (caller), ensuring correct domain association of the task and request data.
    • Support for multiple tenants: The instance owner configures the application to operate across multiple domains, suitable for service provider scenarios.

    Domain Separated Tables

    • Remote Request Definition (snindrmthelprequestdefn)
    • Remote Request Parameter (snindrmthelprequestparam)
    • Request Configuration Mapping (snindrmthelpdefnparamdatamap)
    • Remote Request Data and child tables (snindrmthelprequestdata)
    • Task (task)

    Practical Implications for ServiceNow Customers

    By enabling domain separation in EMR Help, customers can:

    • Ensure secure and isolated data handling for each tenant or service provider within a shared instance.
    • Control visibility and access for users based on their domain affiliation.
    • Maintain accurate reporting and analytics that respect domain boundaries.
    • Configure requests and parameters tailored to specific domains, improving service management efficiency.
    • Use API parameters to programmatically assign tasks and requests to the correct domains, facilitating automated workflows across tenants.

    This functionality is critical for organizations managing multiple customer environments or service providers on a single ServiceNow instance, helping maintain compliance and operational clarity.

    Domain separation is supported for EMR Help. 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.

    EMR Help domain seperation overview

    The EMR Help application includes domain separation for configuration tables (request definition, request parameters, and definition to parameter mapping) as well as domain separation for transactional data like tasks and associated request data coming in from the EMR system.

    Domain separation is enabled in the following aspects of the EMR Help application:

    • Data stored in the Remote Request Data [sn_ind_rmt_help_request_data] table is domain separated.
    • Tasks created when raised either from a record producer or using a REST API are domain separated.
    • Request parameters can be created for use in different domains.
    • Request definitions can be created for use in different domains.
    • Request definition mappings can be created for use in different domains.

    How domain separation works in EMR Help

    For customers using an EMR Help service portal within their EMR systems to raise ServiceNow IT service requests, the domain is set from the logged-in user’s session, in the task created, and the associated request data.

    For customers using the Remote help request API, an administrator can domain separate a task and the associated remote request data by sending any of the following parameters in the task_parameters object while creating the request.

    • Task for user (task_for)
      Note:
      Valid for all task types.
    • Caller (caller_id)
      Note:
      Valid only for the Incident [incident] table.

    For incident, the task’s domain is set from the caller_id parameter if specified in the request body. When the caller_id parameter isn't specified, the task’s domain is set as the domain of the user specified in the task_for parameter. If neither of these parameters are specified in the request body, the task's domain is set from the domain of the authenticated user invoking the Remote help request API.

    Domain separated tables

    • Remote Request Definition (sn_ind_rmt_help_request_defn)
    • Remote Request Parameter (sn_ind_rmt_help_request_param)
    • Request configuration mapping (sn_ind_rmt_help_defn_param_data_map)
    • Remote Request Data (sn_ind_rmt_help_request_data) and its extended child data tables
    • Task [task]