---
sourceDocument: Australia Healthcare and Life Sciences
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/healthcare-life-sciences

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Healthcare and Life Sciences

ft:clusterId :

    - hcls

bundleId :

    - hcls

workflow :

    - Customer and Industry


---

# Understand Service Model Foundation in Healthcare Operations

# Understanding Service Model Foundation in Healthcare Operations {#ariaid-title1}

Release version: Australia  
Updated July 24, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Understanding Service Model Foundation in Healthcare Operations

The Service Model Foundation (SMF) is the underlying framework for Healthcare Operations Core in ServiceNow, providing a consistent data model shared across industries.
It structures key entities such as organizations, locations, and healthcare-specific profiles to support case management and operational workflows in healthcare environments.
Show full answer Show less  

## Service Model Foundation Data Structure

The SMF location tables form a hierarchical extension model:

* **Organization Core** (base table)
* **Business Organization** (extends Organization Core)
* **Internal Organization** and **External Organization** (both extend Business Organization)

Two additional related tables are:

* **Common Location \[cmnlocation\]**: Stores physical address details and is referenced by Organization Core.
* **Healthcare Organization \[snhclsorganization\]**: Holds healthcare-specific information in a one-to-one relationship with Business Organization. It acts as a profile and should not be used as the primary organization record.

**Important:** Internal and External Organization records represent the actual locations or organizations requesting or providing services, not the healthcare organization profile.

## Internal vs External Organizations

* **Internal Organizations** represent entities within the owning organization, such as hospital units or floors.
* **External Organizations** represent entities outside the owning organization, like affiliates or private practices accessing shared services.

## Configuring Service Organization Fields on Cases

Healthcare Operations cases have two key service organization fields:

* **Requesting Service Org:** The organization requesting support; critical for case visibility and must be populated.
* **Supporting Service Org:** The organization fulfilling the case; usage depends on the implementation.

**Best Practice:** Display the Internal or External Organization in the requesting service org field on cases, not the healthcare organization, to ensure proper visibility and functionality.

## Locations and Address Management

The **Common Location** table stores physical address data platform-wide. In healthcare use cases, the **Healthcare Location \[snhclslocation\]** table extends this with healthcare-specific location details and should be configured rather than customizing the common location table directly.

## Bulk Importing Location Data

When importing location data in bulk, a business rule on Organization Core creates a new common location record if the location reference is empty. To avoid duplicate address records, especially when multiple units share the same address, it is essential to:

* Preload or verify existing addresses in the common location table.
* Use a single import set targeting the healthcare organization table with a custom column indicating internal or external status.
* Implement an onBefore transform script to create either Internal or External Organization records linked to the healthcare organization record.
* Look up existing common location records for addresses and reuse them when possible instead of creating duplicates.

This approach simplifies management by using one import set while maintaining data integrity and avoiding redundant location records.

## Key Takeaways for ServiceNow Customers

* Understand the SMF hierarchy to correctly configure organizations and locations in Healthcare Operations.
* Use Internal and External Organization tables as primary location entities, not the healthcare organization profile.
* Correctly populate requesting and supporting service organization fields on cases to preserve out-of-box visibility and workflow.
* Manage physical addresses via the common location table and extend with healthcare location profiles for healthcare-specific data.
* Follow best practices in bulk imports to prevent duplicate location records and streamline data integration.  
Understand how the Service Model Foundation (SMF) tables relate to each other so that you configure cases, locations, and bulk imports correctly for Healthcare Operations Core.

## The Service Model Foundation data model {#understanding-service-model-foundations-hco__section_smf_data_model}

Healthcare Operations Core is built on the Service Model Foundation (SMF) framework, the same platform framework used across industries such as banking, retail, and manufacturing. For the platform-wide overview of these tables, see
[Service Model Foundation overview](https://www.servicenow.com/docs/access?context=csm-industry-data-model&version=australia&pubname=australia-customer-service-management&ft:locale=en-US).

The SMF location tables form an extension hierarchy. From parent to child:

* **Organization Core** \[sn_customer_service_organization\] is the base table in the hierarchy.
* **Business Organization** \[sn_csm_business_location\] is an extension of Organization Core.
* **Internal Organization** \[sn_csm_business_location_internal\] and **External Organization** \[sn_csm_business_location_external\] are both extensions of Business Organization.

{#understanding-service-model-foundations-hco__ul_smf_hierarchy}

For the complete field-level reference for these tables, see [Service Model Foundation tables and
plugins](https://www.servicenow.com/docs/access?context=csm-data-model-tables&version=australia&pubname=australia-customer-service-management&ft:locale=en-US).  
Note:  
These tables were previously labeled **Service Organization** , **Business Location** , **Internal Business Location** , and **External Business Location** . Only the display name changed---the table names
(`sn_customer_service_organization`, `sn_csm_business_location`, `sn_csm_business_location_internal`, `sn_csm_business_location_external`) and the Business Location
plugin itself are unchanged. If you see the older names in existing configuration steps, integrations, or an instance that hasn't picked up the rename yet, they refer to the same tables. For the complete list of renamed entities
and field labels, see [Service Model Foundation renamed Entities](https://www.servicenow.com/docs/access?context=renamed-entities&version=australia&pubname=australia-customer-service-management&ft:locale=en-US).

Two additional tables relate to this hierarchy by reference rather than by extension:

* The **common location** \[cmn_location\] table is referenced from Organization Core through a location reference field. It stores the physical address of a record.
* The **healthcare organization** \[sn_hcls_organization\] table has a one-to-one, bidirectional relationship with Business Organization.

{#understanding-service-model-foundations-hco__ul_smf_refs}  
Important:  
The primary record for a location is Internal Organization or External Organization---not the healthcare organization.

Because the documentation and configuration steps focus heavily on the healthcare organization table, it's commonly mistaken for the primary record. In reality, Internal Organization and External Organization are the tables
that are considered the requesting organization or location---not the healthcare organization.

The healthcare organization is like a profile: a one-to-one repository of healthcare-specific fields and information about its linked Internal or External Organization record. It's against best practice to add
healthcare-specific information directly to the Business Organization tables. That information belongs on the healthcare organization record. For more information, see [Setting up healthcare locations and healthcare organizations](https://www.servicenow.com/docs/kAyklfqIeZAuzgUPjQG0OA "Understand how healthcare locations and healthcare organizations function and should be organized to set up your care teams and the physical locations they operate in correctly.").

## Internal Organization and External Organization {#understanding-service-model-foundations-hco__section_ibl_ebl}

Whether a location is internal or external depends on its relationship to the organization that owns the ServiceNow instance.

* **Internal Organization** records are internal to your organization. For example, the hospital that owns the ServiceNow instance, the units within that hospital, or the individual floors and rooms within the hospital.
* **External Organization** records are external to your organization, such as those for private practices or healthcare affiliates that consume your healthcare services. For example, an affiliate might log into your organization's Epic environment through Epic Community Connect. To report EMR issues requires an External Organization record in ServiceNow, along with the corresponding membership setup.
{#understanding-service-model-foundations-hco__ul_ibl_ebl}

## Service organization fields on cases {#understanding-service-model-foundations-hco__section_case_service_orgs}

The Healthcare Operations case \[sn_hco_case\] form has two service organization fields. Configure them correctly to preserve out-of-box case visibility. For the platform-wide pattern this is based on, including the shared-visibility
model and how CSM and ITSM divide the work, see .

Requesting service org
:   Represents the organization that needs support (the requester). This out-of-box field is used in every SMF implementation and drives shared case visibility. If the requesting service org isn't populated on the case, none of
    the shared visibility works.

Supporting service org
:   Represents the organization that's fulfilling the case (the fulfiller). This field isn't used in every implementation.
{#understanding-service-model-foundations-hco__dl_service_orgs}  
Note:  
A common configuration error is displaying the healthcare organization on the case form. Display the Internal or External Organization record through the out-of-box requesting service org field instead. Because the healthcare
organization is only a profile, showing it on the case doesn't establish the visibility that the requesting service org field provides.

## Common locations and Business Organization {#understanding-service-model-foundations-hco__section_cmn_location}

The common location \[cmn_location\] table represents the physical address of a record and is used across the ServiceNow platform. Because several tables contain *location* in their name, it's commonly assumed that one table
extends another, but they don't. Organization Core holds a reference field to the common location record.

For healthcare use cases, configure the healthcare location \[sn_hcls_location\] table rather than customizing the common location table directly. The healthcare location is a profile for an individual location---a repository of fields
and information that aren't available on the common location table. For more information, see [Setting up healthcare locations and healthcare organizations](https://www.servicenow.com/docs/kAyklfqIeZAuzgUPjQG0OA "Understand how healthcare locations and healthcare organizations function and should be organized to set up your care teams and the physical locations they operate in correctly.").

## Importing location data {#understanding-service-model-foundations-hco__section_import_location_data}

When you bulk import location data, a business rule on Organization Core creates a new common location record whenever address fields are added and the common location reference field is empty. If multiple units at the same
hospital share a single physical address and you import address details on each Business Organization record, this business rule creates duplicate common location records---one for every Internal or External Organization record
that you import.

To avoid duplicates, look up and reuse existing common location records instead of letting the business rule create new ones. Reusing existing records also matters for customers migrating from ServiceNow IT Service Management, who
likely already have common location records---and incidents related to them---that should be reused.

Use the following process to import location data:

1. Load or confirm the addresses in the common location \[cmn_location\] table. If the customer already has address records, such as from an existing ITSM deployment, no action is needed in this step. Otherwise, import the addresses into the common location table first.
2. Create a single import set and transform map at the healthcare organization \[sn_hcls_organization\] table. Include a custom choice column in the import spreadsheet that indicates whether each row is internal or external.
3. Use an onBefore transform script to create the correct Internal Organization or External Organization record. Based on the internal or external value, the script creates the linked Internal Organization or External Organization record. This approach produces one import set that creates records across the appropriate tables, so the customer manages only a single import set.
4. In the same script, look up an existing common location record for the address and reference it from the Internal Organization or External Organization record, copying the address data up to the Business Organization record. Only when no matching common location record exists should you add the address details and allow a new common location record to be created.

{#understanding-service-model-foundations-hco__ol_import_process}  
Tip:  
Don't add address fields directly to an Internal Organization or External Organization record when a matching common location record already exists if you haven't populated the common location yet. Doing so triggers the
business rule that creates duplicate common location records.

For a worked example that applies this data model to a hospital system, see [Example: Service Model Foundation in a hospital setting](https://www.servicenow.com/docs/n9V3hv7d7nD8q32QAiH4aA "See how Service Model Foundation (SMF) tables for healthcare organizations and locations come together for a real hospital system.").