Domain separation and EMR Help
Summarize
Summary of Domain Separation and EMR Help
The EMR Help application supports domain separation, allowing you to organize data, processes, and administrative tasks into distinct domains. This feature helps control user access and visibility of data, which is essential for managing multiple tenants effectively.
Show less
Key Features
- Runtime Domain Separation: Supports separating user interface elements, cache keys, reporting, rollups, and aggregations.
- Configuration Tables: Domain separation applies to request definitions, request parameters, and their mappings.
- Transactional Data: Tasks and associated request data from the EMR system are domain separated.
- Task Creation: Tasks initiated via record producers or REST APIs maintain domain separation based on user sessions.
Key Outcomes
By utilizing domain separation in EMR Help, you can ensure that service providers can respond to tenant customers while maintaining data integrity and security. The application allows administrators to specify domains through parameters like taskfor and callerid, ensuring accurate data handling across different user scenarios.
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.
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]