Halo ITSM
Service Automation Framework

Halo SAF —
Make Your ITSM Platform Actually Work for You.

The Halo SAF is the engine behind real automation, connecting your services, your people, and your processes so that Halo ITSM delivers its full value from day one.

Talk to an Expert
Automated / Intelligent routing
Governed / Clear ownership
Scalable / Grows with you
SAF in action — live automation
CI Alert detected
Linux Server — OUTAGE
Major Incident
SAF Engine
Traversing CMDB relationships → 3 services impacted
Ownership
L2 Engineering assigned
✓
SWAT Mobilised
4 team members paged
✓
Stakeholders
12 subscribers notified
✓
Zero manual decisions — all driven by SAF data

The problem most organisations don't talk about

ITSM platforms get deployed, go live, and then quietly underdeliver. Tickets get logged, but nothing is truly automated. Incidents land in the wrong queue. Nobody knows who owns what when something breaks. Sound familiar?

70%

of organisations end up with an expensive ticketing system and little else. Process automation never materialises. Ownership is unclear. The platform becomes a liability instead of an asset.

No real automation

Incidents are manually triaged and assigned. Change approvals chase the wrong people. Every process relies on human memory rather than structured data.

Unclear ownership

When an outage hits, nobody knows who is accountable. Services lack defined owners. Escalation paths are guesswork. Resolution times suffer as a result.

Poor data quality

The CMDB is either empty, out of date, or so bloated it's unusable. Without reliable service and asset data, every process is built on sand.

What SAF changes for your organisation

SAF is not a product add-on. It's a foundational investment that takes Halo ITSM beyond ticketing and turns it into a genuine service automation engine. Here's what that looks like in practice.

Automated incident routing

New incidents are automatically assigned to the right Level 1 team based on the affected service. One-click escalation to Level 2 or Level 3, with no manual decision-making required.

Intelligent change management

SAF automatically determines change ownership, identifies approval and review teams, assesses risk, and runs collision checks, all derived from your service and ownership data.

Major incident response

When a major incident strikes, SAF instantly identifies all impacted services, mobilises the right SWAT team, and sends targeted communications, reducing chaos and resolution time significantly.

Defined ownership at every level

Every service has a named owner, an operations team, an engineering lead, and escalation paths. This clarity is inherited automatically. You never have to ask "who owns this?" again.

Meaningful dashboards & reporting

With services at the heart of your data, leadership gets real-time visibility across health, availability, SLA performance, change pipeline, and CMDB data quality, broken down by service and business unit.

Governed data you can trust

A federated governance model gives each service team accountability for the quality and accuracy of their data. Regular certification cycles ensure your CMDB remains a reliable source of truth.

The Framework — Part 1 of 2

The Service Data Model (SDM)

The SDM is a best-practice CMDB blueprint built around the concept of a service. Rather than filling your CMDB with every asset imaginable, it creates a structured, connected picture of the things that matter: the services that support your business.

  • Business Services: the services your users request through the catalogue, aligned to business capabilities.

  • IT Services: the technology layer that owns and manages your business applications and infrastructure.

  • Business Applications & Instances: the software that runs your business, mapped to their environments and deployments.

  • Infrastructure CIs: the physical and logical assets that underpin everything, selectively included where they add genuine business value.

SDM Taxonomy

Business Service

User-facing, catalogue-requestable

↓ consumed by
IT Service

Owns & manages applications

↓ runs on
Business Application / Instance

The software and its deployments

↓ depends on
Infrastructure CIs

Servers, databases, network, storage

TOM — Operational Roles (examples)

Incident
L1 Support L2 Support L3 Support
Change
Owner Approval Review
Request
Approval Assignment
Problem
Owner L2 Support
Configuration
Maintenance Governance

Roles are defined once per IT service and automatically inherited by all applications and instances it owns.

The Framework — Part 2 of 2

The Target Operating Model (TOM)

If the SDM defines what your services are, the TOM defines who is responsible for them. It's a RACI-driven model that assigns named teams and individuals to every key process role, covering every service in your estate.

  • Operational roles drive automation: incident assignment teams, change approvers, request fulfillers. These roles power Halo ITSM's automated workflows.

  • Accountable roles ensure awareness: service owners, CIOs, risk officers, architects. Named individuals are always on-call and easy to reach.

  • Automatic inheritance means roles defined at the IT Service level cascade down to all business applications and instances, cutting maintenance overhead dramatically.

SDM Layers Explained

Five layers. One connected picture.

The SDM is structured around five distinct layers. Each layer has a clear definition, specific modelling rules, and a direct role in driving automation. Only model what is necessary — focus on what delivers genuine business value.

Want the full technical reference? Read the SDM deep-dive →

BS

Business Service

Top layer

A Business Service represents the value delivered to end users or customers — aligned to existing business capabilities. ITSM tickets are not typically raised directly against Business Services, but they are essential for understanding the business impact of IT issues and changes.

Examples

Email Field Sales Finance Reporting Access Management Recruiting

Key rules

  • →Must directly enable a business function or outcome
  • →Cannot run on infrastructure — it consumes Technical Services
  • →Only model if a business stakeholder would recognise it as a service they consume
TS

Technical Service

Automation foundation

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 data. Three types exist: Application-aligned, Infrastructure-aligned, and Management (e.g. a service desk or managed service).

Examples

IAM ERP Finance Linux Server Hosting Wireless LAN Service Desk

Key rules

  • →Must have accountable and operational TOM data — this drives all automation
  • →Must have a service type: Application, Infrastructure, or Management
  • →Not a piece of software — it owns and manages applications and infrastructure
  • →Can exist without any related CIs; can be consumed by zero or more Business Services
BA

Business Application

Configured software

Business Applications are configured software solutions deployed in the organisation's (or a third party's) datacentre. They represent the functional systems that enable key business processes. This covers both commercial off-the-shelf products and internally developed systems — if end users or IT teams log in and interact with it, it belongs here.

Examples

Splunk VMware vCentre F5 SSO Jira Halo ITSM

Key rules

  • →Must have at least one Business Application Instance (the production deployment)
  • →Must have exactly one owning Technical Service
  • →Not directly related to other Business Applications — dependencies are modelled at the Instance layer
BAI

Business Application Instance

Deployments & environments

Business Application Instances are the actual deployments of a Business Application — differentiated by environment (Production, Dev, UAT), geography (Global, Regional, Country), or business line. They are directly connected to the infrastructure layer and support peer-to-peer dependency mapping between applications. This is where impact analysis lives.

Examples

Halo ITSM — Production Jira — UAT SAP — EMEA Monday.com (SaaS)

Key rules

  • →Every Business Application must have at least one Production instance
  • →Always linked to the infrastructure layer — unless the application is SaaS
  • →Peer-to-peer relationships between instances are used to model application dependencies
CI

Infrastructure CIs

Foundation layer

Infrastructure CIs represent the physical and logical components that run your applications — servers, databases, network devices, clusters, and more. The CMDB scope should focus on elements that drive tangible business outcomes. Not everything needs to be modelled; focus on what supports automated routing and impact analysis.

Examples

Servers Databases Firewalls Clusters Virtual Desktops

Key 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
  • →Avoid overloading the CMDB — only include what supports a business outcome
Two catalogues. One system.

Service Catalogue vs Request Catalogue

A common source of confusion in Halo implementations. They're different views of the same data — and understanding the distinction is key to building a catalogue that actually works.

Service Catalogue

The Service Catalogue is your CMDB and SDM — the internal, operational view of your IT estate. It reflects the five-layer hierarchy: Business Services, Technical Services, Business Applications, Instances, and Infrastructure. This is the foundation for all ITSM processes and automation.

  • ✓Defines ownership and accountability for every service
  • ✓Drives incident routing, change approval, and escalation
  • ✓Automatically creates a "twin" entry in the request catalogue when services are defined
  • ✓Not primarily user-facing — this is your IT operations backbone

Request Catalogue

The Request Catalogue is the end-user view — what your colleagues see in the self-service portal. It contains the requestable items, incident forms, and access request workflows that are surfaced to users. Visibility and subscriptions are controlled here, so you decide what end users can see and order.

  • ✓User-facing — what colleagues see in the self-service portal
  • ✓Controls visibility, access, and subscription for each item
  • ✓Items can be organised into categories for easier browsing
  • ✓Request forms, incident forms, and workflows are defined here

The key insight

When you create a Technical Service or Business Application in the CMDB, Halo automatically creates a corresponding entry in the Request Catalogue. These "twins" are hidden from end users by default — you choose when to make them visible. This means your SDM work directly populates your service portal, with no duplication of effort.

Your SAF maturity journey

SAF is designed to meet you where you are. Whether you're just getting started or looking to mature an existing CMDB, there's a clear, staged path forward. Each step builds real value before moving to the next.

1

Infrastructure

Start with your core infrastructure: servers, clusters, databases, network devices. Group them into infrastructure-aligned IT services and populate ownership data. This is the foundation everything else builds on.

2

Applications

Onboard your business applications and their instances, grouped into application-aligned IT services. Connect them to the infrastructure layer. This is where automation starts to deliver real value across incidents and changes.

3

End Users

Bring in end-user devices (desktops, laptops, mobile) assigned to end-user IT services. Particularly valuable for organisations running software asset management or device lifecycle programmes.

4

Mature

Continuously improve data quality and coverage. Introduce business services mapped to business capabilities. Widen the CMDB scope and drive healthy competition across service owners with regular scorecards and dashboards.

SAF evolves with your organisation. The framework adapts to your current maturity. You'll never be asked to do more than delivers clear business value.

Automation across every key process

Once SAF is in place, Halo ITSM uses your service and ownership data to eliminate manual decision-making across all core ITSM processes.

Incident Management

  • Auto Assignment to the correct L1 team
  • Auto SLA timers start from service configuration
  • Auto Escalation path determined from TOM
  • Auto Impact analysis across related services

Change Management

  • Auto Ownership set from affected CI's IT service
  • Auto Risk assessment from change history
  • Auto Collision & conflict detection
  • Auto Approval and review teams identified

Major Incident Management

  • Auto All impacted services identified instantly
  • Auto SWAT team mobilised via PagerDuty, Teams
  • Auto Targeted stakeholder communications
  • Auto Recent changes & incidents cross-checked

Ready to get Halo SAF working for your organisation?

Allied ESM has deep expertise in deploying SAF for organisations of all sizes. We'll work with you to build the right foundation at a pace that matches your maturity, and ensure your investment in Halo ITSM delivers genuine, lasting value.

Book a Consultation Learn about Halo ITSM

Official Halo Partner

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

FAQ

Common questions

Coming from ServiceNow?

See how Halo SAF compares to ServiceNow CSDM

A frank, side-by-side comparison for ITSM leaders who've lived through a CSDM implementation and want a cleaner path to automation.

Read the comparison →