Domain separation and Field Service Management

  • 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 Field Service Management

    Domain separation in ServiceNow provides a structured approach to manage complex, multi-tenant organizational environments by logically grouping data, processes, and administrative tasks into isolated domains. This ensures that users only see data relevant to their domain, enhancing security and operational efficiency.

    Show full answer Show less

    In the Field Service Management (FSM) application, domain separation is driven primarily by the Company entity. Each company is assigned to a domain, and all associated work orders, tasks, and related entities are created within that domain. When FSM is integrated with Customer Service Management (CSM), the Account field becomes mandatory and drives the domain assignment for work orders and tasks.

    How Domain Separation Works in Field Service Management

    • All companies must be assigned to a domain to enable domain separation.
    • The Company field on the Work Order form is mandatory in domain-separated instances.
    • Work orders and their tasks inherit the domain of the assigned company or account.
    • If the domain of a work order changes, the domains of associated tasks update accordingly.
    • Changing the company or account on a work order modifies its domain and the domain of related tasks, but not other related entities.
    • Domain separation applies to dispatcher and assignment groups; these groups are filtered by the domain and must match the work order or task domain.
    • The parts sourcing process, including part requirements, transfer orders, and asset availability, respects domain separation.
    • FSM’s configuration settings (e.g., task assignment methods) apply globally and are not domain-specific.

    Practical Considerations for ServiceNow Customers

    • Domain separation setup for FSM requires coordination with ServiceNow support.
    • Work orders created from Incident, Problem, or Change requests inherit the company and domain from the original record; if no company is present, the company field remains mandatory.
    • Users benefit from secure, relevant data visibility and controlled access aligned with their domain.
    • Domain separation ensures proper segregation of operational data and workflows across multiple tenants or business units within the same instance.

    Why It Matters

    For ServiceNow customers managing multiple tenants or organizational units, domain separation in FSM enhances data security, governance, and operational clarity by isolating data and processes per domain. This enables efficient service delivery tailored to each company's or account's context, reducing data exposure risks and improving user experience.

    Domain separation provides a structured and efficient way to manage complex, multi-tiered organizational environments. It allows for tailored access and control, ensuring that users see only the data relevant to their domain, enhancing security and efficiency.

    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.

    Domain separation and Field Service Management overview

    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. In the Field Service Management application, you can use the Company entity to drive domain separation. Assign a domain to each company and then any work orders and tasks created for a company are created within the company domain. Other entities and tasks related to work orders, such as dispatcher and assignment groups, part requirements, and transfer orders, are driven by the company and work order domains.

    How domain separation works in Field Service Management

    Domain separation for Field Service Management uses the Company entity to drive the domain structure. To use domain separation, all companies must be assigned to a domain.

    When using Field Service Management in a domain separated instance, the Company field is a mandatory field on the Work Order form. When you create a work order for a company, the work order is created in the company domain. Any tasks created for the work order are also created in the company domain.

    When using Field Service Management integrated with Customer Service Management in a domain separated instance, the Account field is a mandatory field on the Work Order form. When you create a work order for an account through a customer service case, the work order is created in the account domain. Any tasks created for the work order are created in the same domain as the work order. In the event that the domain of the work order changes, the domain of the work order tasks is also updated.

    Modifying the company or account on a work order also modifies the domain of the work order and work order tasks. The domains of other related entities are not automatically updated. The company or account can be changed until the work order is qualified.
    Note:
    Field Service Management is configured at the application level and does not support domain-specific configuration. For example, if you select use dynamic scheduling as your task assignment method, this method is used to assign tasks in all domains.

    Setting up domain separation in Field Service Management

    To set up domain separation for Field Service Management, contact ServiceNow, Inc.

    Work orders created from Incident, Problem, or Change

    For work orders created from an incident, problem, or change request the following will occur:
    • The company on the work order is inherited from the original record.
    • The domain of the work order is inherited from the company.
    • If the original record does not include a company, the Company field is still a required field on the Work Order form.

    Groups

    Qualification, dispatcher, and assignment groups are filtered based on the domain of the work order and work order tasks. The group domain must match the work order or work order task domain.

    Parts process

    The parts process, which includes sourcing and using assets, is also domain separated.
    • Part requirements are created in the work order domain.
    • Transfer orders and transfer order lines created for a part requirement are created in the part requirement’s domain.
    • When sourcing a part, the following are available:
      • Assets are available for a work order or work order task based on the part requirement domain.
      • Assets are available based on the part requirement domain.
      • Stockrooms are available based on available assets.