Technical Reference

The Halo Service Data Model

The SDM is the structural backbone of Halo SAF. It defines how your IT estate is organised into connected layers — from business outcomes down to physical infrastructure — and how those layers drive automation across every ITSM process.

This page is the complete technical reference: layer definitions, modelling rules, relationship types, decision questions, and real-world examples. It is written for ITSM practitioners and solution architects building or governing a Halo SDM.

← Back to Halo SAF SAF vs CSDM →

On this page

The golden rules The five layers → Business Service → Technical Service → Business Application → Business Application Instance → Infrastructure CIs

Also on this page

Relationship types Ticket routing rules Service vs Request Catalogue MSP pattern Real-world examples

Need help with your SDM?

Allied ESM has implemented SAF for organisations across the UK. We run SDM workshops, build your service taxonomy, and configure automation — end to end.

Talk to us

Start here

The golden rules for service modelling

Before getting into the layers, these principles apply universally. They are the difference between a SDM that drives real automation and one that becomes a maintenance burden.

Understand the service ecosystem. Before modelling anything, identify who provides, supports, owns, manages, and requests the service. Build this picture first.

Only model what is necessary. Focus on aspects within your responsibility. The SDM should be usable in real ITSM processes — not an academic exercise.

Define clear boundaries. Know where your responsibility begins and ends. Identify the most critical relationships to capture, not every possible dependency.

Don't include what doesn't need ITSM support. If a service has no assigned owner, no support team, and isn't managed through ITSM processes — leave it out.

Avoid redundancy. If a service is already covered by another entry in the catalogue, don't duplicate it. Each entry should provide distinct value.

Focus the CMDB on business outcomes. The infrastructure layer in particular can grow unwieldy. Only include CIs that support automated routing, impact analysis, or compliance requirements.

Structure

The five layers

The SDM is structured as a hierarchy. Each layer has a specific purpose and a clear set of rules. Relationships flow downward — Business Services consume Technical Services, which own Business Applications, which deploy Instances, which run on Infrastructure.

SDM Hierarchy — top to bottom

Business Service

User-facing · aligned to business capabilities

Layer 1

↓ consumes

Technical Service

Owns & manages applications and infrastructure

Layer 2

↓ consumes

Business Application

Configured software · deployed in a datacentre

Layer 3

↓ deploys

BAI

Business Application Instance

Production, Dev, UAT · by environment or region

Layer 4

↓ runs on

Infrastructure CIs

Servers, databases, network, clusters, storage

Layer 5

Arrows represent the primary relationship direction. Relationships are always defined from downstream to upstream — arrows point downward.

Layer 1

Business Service

Definition

A Business Service represents a service that delivers value to end users or customers — internally (within the organisation) or externally (to clients and partners). Business Services align with business capabilities. ITSM tickets are typically not raised directly against Business Services, but they help understand the business impact of IT issues and changes on end users.

Examples

Email Field Sales Finance Reporting Network Management Access Management Recruiting Printing Guest Wi-Fi & Remote Access

Modelling rules

→Cannot run on infrastructure — consumes Technical Services
→Can be consumed by zero or more Technical Services
→Criticality is a mandatory field — used for impact tracking
→Primarily used for impact reporting, not ticket assignment
→Not all organisations require this layer — only model it if stakeholders use it

Decision questions — should this be a Business Service?

Does this service directly support a business outcome or capability (e.g. Sales, HR, Finance)?

→ If yes: model as a Business Service

Would a business stakeholder recognise this as a service they consume or rely on for their operation?

→ If yes: model as a Business Service

Does it describe a functional outcome ("Customer Order Management") rather than a technical solution?

→ If yes: model as a Business Service

Layer 2

Technical Service

Definition

Technical Services own, support, and manage your applications and infrastructure. This is the most critical layer for automation — it is the base level for incident routing, change approval, and ownership assignment. Every Technical Service must have a TOM. There are three primary types, aligned to who supports the service: Application-aligned, Infrastructure-aligned, and Management (e.g. a service desk or managed service operation).

Application

Groups business applications delivering a common outcome. Owned and supported by an application team. E.g. the ERP service owns SAP, Workday, and associated integrations.

Infrastructure

Manages infrastructure that supports multiple applications. Owned by an infrastructure or platform team. E.g. Linux Server Hosting, Wireless LAN, Virtualisation Platform.

Management

Represents a managed or operational service, such as a service desk function or an externally managed service. Used where a team provides a service capability rather than owning applications or infrastructure directly.

Examples

Identity & Access Management ERP Finance Linux Server Hosting Wireless LAN Service Desk — EMEA Application Performance Monitoring

Modelling rules

→Create the Technical Service first — before applications and CIs
→Must have accountable and operational TOM data — this is what drives automation
→Must have a service type: Application, Infrastructure, or Management
→It is not a piece of software — it owns and manages applications and infrastructure
→Technical Services are not directly related to other Technical Services — dependencies are modelled at the Application Instance layer
→Can exist without any related CIs; can be consumed by zero or more Business Services
→Every CI class must be mapped to an owning Technical Service

When to split Technical Services vs keeping them together

A common modelling question: if two different tools deliver what is effectively the same service (e.g. two different SIEM products serving different customers), do they need separate Technical Services?

The rule: only split if the TOM would differ. If the assignment path, approval process, and ownership structure are the same regardless of which underlying tool is involved, use one Technical Service and model the tools as separate Business Applications beneath it. The Technical Service represents the operational responsibility — not the product.

If different tools genuinely route to different teams, have different SLAs, or require different approval chains, then separate Technical Services are justified. When in doubt, keep it consolidated and split later.

Decision questions — should this be a Technical Service?

Does this service provide, own, or manage IT capabilities — applications or infrastructure?

→ If yes: model as a Technical Service

Is it primarily managed, maintained, and consumed by IT teams rather than business users?

→ If yes: model as a Technical Service

Does it require detailed support routing, change approval, or ownership assignment?

→ If yes: model as a Technical Service with a TOM

Layer 3

Business Application

Definition

Business Applications are configured software solutions designed to support and deliver specific business and technology capabilities. They are deployed and running within the organisation's (or a third party's) datacentre. To be classified as a Business Application, a system must provide direct business value by supporting daily functions used by end users or IT. This includes both commercial off-the-shelf products and internally developed systems.

Examples

Halo ITSM Jira Splunk VMware vCentre F5 SSO SAP Workday

Modelling rules

→Must have at least one Business Application Instance (minimum: production)
→Must have exactly one owning Technical Service
→Not directly related to other Business Applications — use the Instance layer for dependencies
→Health Status is a mandatory field — reflects live operational state
→An Impact Statement (the business effect of downtime) should be documented

Note: Business Applications vs Software Licences. Business Applications are part of the SDM and drive ITSM automation. Software Licences are a separate concept in Halo, linked to Contract Management and used to track who is consuming what. A software product can have both a Business Application record (for ITSM automation) and a Software Licence record (for contract and asset management) — they serve different purposes and should not be conflated.

BAI

Layer 4

Business Application Instance

Definition

Business Application Instances are the physical deployments of Business Applications. Each instance represents a specific deployment differentiated by environment, geography, or business line. They are directly connected to the infrastructure layer and support peer-to-peer dependency mapping between applications — making this the layer where impact analysis and dependency visualisation live.

By environment

Production, Dev, UAT, Staging. The production instance is always mandatory. Others are modelled based on operational need.

By geography

Global, Regional, Country. Used where an application is deployed with distinct infrastructure in different locations (e.g. SAP EMEA, Jira LATAM).

By business line

Where an application serves a specific business unit with its own deployment and support model. E.g. a time management system deployed separately for corporate and manufacturing.

Examples

Halo ITSM — Production Jira — UAT SAP — EMEA CDC Monday.com (SaaS Global) YSoft Printing — Dev

Modelling rules

→Every Business Application must have at least one Production instance
→Always linked to the infrastructure layer — unless the application is SaaS (third party owns infrastructure)
→Each instance is deployed by exactly one Business Application, using a 'deploys' relationship
→Peer-to-peer relationships between instances model cross-application dependencies
→Target Application Availability should be set to track uptime expectations

Layer 5

Infrastructure CIs

Definition

The infrastructure layer covers the physical and logical components that run your applications — servers, databases, network devices, clusters, racks, and more. The CMDB scope here should focus on elements that drive tangible business outcomes. Not every piece of infrastructure needs to be modelled. Prioritise CIs that directly support incident routing, impact analysis, and change management.

Common CI classes

Server Database Server Database Instance Cluster Firewall Switch Virtual Desktop UPS Rack

Modelling rules

→All infrastructure classes must be mapped to an owning Technical Service
→Key relationships between CIs (e.g. databases running on servers) must be identified and mapped
→Owning Service field is mandatory — this is the fallback for TOM data when no direct TOM is set
→Focus on CIs that deliver tangible business outcomes — avoid overloading the CMDB

Dependency mapping

Relationship types

Relationships in the SDM are visual aids for the dependency diagram — they do not directly influence automation, but they enable impact analysis and service health visualisation. Arrows always point downward (downstream). Key types are listed below.

Relationship	Direction	Example
Consumes	Business Application → Technical Service Business Service → Technical Service	SAP consumes the ERP Finance Technical Service
Deploys	Business Application → Business Application Instance	Jira deploys Jira Production, Jira UAT
Runs On	BAI → Cluster or Server Database → Database Server	Jira Production runs on APPSRV-01
Manages	Application → BAI or Infrastructure	A monitoring application manages a server cluster
Hosts	Server → Database Rack → Server or Switch	DB-SERVER-01 hosts Oracle Production Instance
Sends Data To	BAI ↔ BAI (peer)	CRM Production sends data to Finance Reporting Production
Connected To	Switch ↔ Switch, Router, Load Balancer	CORE-SW-01 connected to DIST-SW-02
In Rack	Infrastructure → Rack	APPSRV-01 in RACK-DC1-A03

Note: relationship direction is upstream → downstream. The parent always points to the child. "Deploys" is used to indicate that a Business Application deploys its instances — the arrow goes from Application down to Instance.

Automation logic

How Halo routes tickets using the SDM

When a ticket is created or its CI changes, Halo traverses the SDM to identify the correct Technical Service and apply the associated TOM data. The rules are evaluated in sequence.

If the ticket type (Request Form or Incident Form) has dedicated routing configured, that routing takes priority.

If the primary CI is a Business Application Instance with no TOM, Halo uses the TOM of the owning Business Application instead.

For all other CI classes with no TOM maintained, Halo uses the TOM of the owning Technical Service.

If a ticket is raised from the request catalogue against a CI of type 'is service', that CI is used as the primary service directly.

If a ticket is raised from the request catalogue against a Business Application CI, the owning Technical Service's TOM is used.

If a non-catalogue ticket has no owning service on the primary CI, Halo checks the owning Business Application for TOM data before defaulting.

Why this matters: The cascade ensures that automation works even with an incomplete SDM. A partial model is better than no model — every CI that has an Owning Service set will benefit from automated routing, even if the full TOM isn't populated yet.

Catalogue structure

Service Catalogue vs Request Catalogue

Two different views of the same data. The Service Catalogue is your operational SDM in the CMDB. The Request Catalogue is the user-facing self-service portal. Understanding the distinction prevents a common implementation mistake.

Service Catalogue

Your CMDB and SDM — the internal, operational view. The five-layer hierarchy lives here: Business Services, Technical Services, Business Applications, Instances, and Infrastructure. This is the foundation for all ITSM processes and automation.

✓Defines ownership and accountability
✓Drives incident routing and change approval
✓Automatically creates "twins" in the request catalogue
✓Not primarily user-facing

Request Catalogue

The end-user view — what colleagues see in the self-service portal. Requestable items, incident forms, and access workflows are surfaced here. Visibility and subscriptions are controlled item by item.

✓User-facing self-service portal view
✓Controls visibility, access, and subscriptions
✓Items can be grouped into categories
✓Request forms and workflows defined here

How the twin mechanism works: When you create a Technical Service in the CMDB with the 'is Service' class flag enabled, Halo automatically creates a corresponding catalogue item under Services > Technical in the request catalogue. When you create a Business Application with 'is Business Application' enabled, a twin appears under End User Catalogue > IT > Business Applications. Both are hidden from end users by default — you control when they become visible. This means your SDM build directly populates the portal with no duplication of effort.

Managed Services Providers

SDM for MSPs — a different pattern

If you're a managed services provider using Halo to deliver services to external customers, the SDM still applies — but the catalogue and subscription strategy works differently from a standard internal IT deployment.

Subscribe customers at the Application layer

Subscribe each customer to the specific Business Application (or Instance) that reflects their deployment. This allows Halo to identify precisely which customers are affected when a particular tool or environment has an issue.

Example: two customers use different SIEM tools. Subscribing at the application level means you can instantly identify which customer group is impacted by a CrowdStrike outage vs a Sentinel issue — without wading through the full customer base.

Control the catalogue at the Business Service layer

The requestable items customers see in the portal should sit at the Business Service level — not the application level. Customers understand "MDR" or "Threat Detection". They don't know or care which underlying tool delivers it.

This also future-proofs your catalogue. If you switch from one tool to another, the customer's service name and request items stay the same. No confusion, no retraining, no catalogue rebuild.

The practical split

For reporting & impact

Use the application / instance layer. This tells you which customers, on which tools, are affected by an outage.

For the customer portal

Use the business service layer. Customers raise incidents and requests against service names they recognise.

For ticket triage

Start at the business service the customer identified, then drill down through the CMDB to the specific CI that caused the issue.

Reference

Real-world examples across the layers

A representative sample of what each layer looks like in a real enterprise SDM. These are not prescriptive — your organisation's taxonomy will reflect your own services and applications.

Business Service	Technical Service	Business Application	Example Instance
Email	Messaging & Collaboration	Microsoft Exchange	Exchange — Production
Identity & Access	IAM Platform	Okta / Azure AD	Azure AD — Global
File Storage & Sharing	Cloud Services — EMEA	SharePoint Online	SharePoint — Production
Finance Reporting	ERP Finance	SAP S/4HANA	SAP — EMEA CDC
Printing	Print Management	YSoft SafeQ	YSoft — Production
Devices	Device Management	Intune / JAMF	Intune — Global
Service & Support	IT Service Management	Halo ITSM	Halo — Production
Mobility	Mobile Device Management	VMware Workspace ONE	WorkspaceONE — APAC

Ready to build your Service Data Model?

Allied ESM runs structured SDM workshops for organisations at every stage of CMDB maturity. We help you define the right scope, build your service taxonomy, and ensure your Halo implementation delivers real automation from the start.

Book an SDM Workshop Back to Halo SAF

Official Halo Partner

Allied ESM is a pure play Halo partner — licensing, implementation, consulting & managed services.

Talk to us

See how Halo SAF compares to ServiceNow CSDM

A frank, side-by-side comparison for ITSM leaders who've lived through a CSDM implementation.

SAF vs CSDM →