The Pitfalls of a Single-Table ITSM Architecture: A Comparative Analysis of HaloITSM vs. Ivanti Neurons for ITSM

Executive summary

As organizations grow and their IT operations mature, the foundational architecture of their IT Service Management (ITSM) platform can make all the difference in achieving long-term agility, effective integration and a high standard of service.

Some ITSM solutions, like HaloITSM, use a simplified, single-table model (storing all service records in a single unified table). In contrast, Ivanti Neurons for ITSM employs a more advanced, object-oriented architecture that segments distinct ITIL processes (incidents, problems, changes and requests) into separate, modular entities.

This white paper examines the shortcomings of the single-table approach, particularly in complex enterprise environments, and highlights the benefits of adopting a more structured, scalable ITSM architecture.

Feature/capability	Single table	Module
Workflow flexibility	Limited	High
ITIL alignment	Basic	Comprehensive
Customization isolation	Low	High
Reporting granularity	Moderate	Advanced
Integration complexity	High	Low
Scalability	Moderate	High
Performance	Moderate	High
Security	Complex	Simplified

1. Introduction

The ITSM landscape is evolving rapidly, with increasing demands for automation, integration and user-centric service delivery. While simplicity can be an advantage for small teams or startups, it often becomes a liability as organizations grow. This paper examines the architectural trade-offs between HaloITSM’s single-table model and Ivanti Neurons’ modular design.

2. Understanding the single-table ITSM model

In platforms that use a single table, all service records — whether incidents, service requests, problems or changes — are stored in a single “Tickets” table.

Illustrated below is a single-table ITSM architecture featuring six fields:

Record #	Record type	Owner name	Subject	Confidential	Priority
1	Incident	Don	VPN Error		2
2	Change	Jamie	Patch SQL Server		Low
3	HR Case	Harold	My pay is wrong	Yes	Urgent
4	Incident	Don	SAP failure		1
5	Request	Patricia	New computer		Low

The first thing that you'll notice is the field called “Record type.” This determines what data is being stored in the record and is the primary field for restricting access to that field type.

Security

First, we'll examine the security framework for this table. The subsequent definition outlines access permissions for Harold.

Harold is allowed full access to table = “tickets” and record type = “HR Case.”

This security rule ensures that Harold can access the tickets table and only look at HR cases.

Now let’s look at this rule for Don, who works in IT…

Don is allowed full access to table = “tickets.”

A challenge arises because Don, an IT employee, has unrestricted access to the entire table. This could inadvertently reveal confidential HR case data to Don.

The rule should be:

Don is allowed full access to table = “tickets” and record type NOT = “HR Case.”

This complexity increases when granting Don full access to “incident” but only read access to “changes.”

Configuration

Configuration within a unified table environment can also be complex because fields within the same table may have diverse requirements based on the record type.

By observing our table, we note a variety of priority types for the respective record types. Incidents adhere to the ITIL standard, using a numerical system (1, 2, 3, 4), while changes and requests are categorized as low, medium or high priority. HR requests, however, are classified as low, high or urgent.

How do you implement and maintain this complexity? While a free-form field reduces data integrity and standardization, a lookup table with record type filters is preferable. Yet, this still presents the challenge of mixed data types, complicating reporting and field/table maintenance.

Configuration in a shared single table is more complex, as all configuration changes must take all record types into account. For instance, the field “Confidential” is required for HR Cases, but not for other record types. If “HR Case” was its own table, you could simply make the field mandatory at the table level. If we make this change in a single table, then that field is also mandatory across incidents, changes and requests, which don't require it. The solution is to programmatically enforce it as a mandatory field within a field business rule, which requires some definition and additional administration.

Now, let's say we have a legal team that wants to build a custom application for legal requests. In a single-table architecture, we’d need the record type to be “Legal,” and some fields could be reused (e.g., “Subject,” “Description,” “Confidential”). But, legal also needs additional mandatory fields: “External” (yes/no), “Legal proceedings” (yes/no), etc. These fields need to be added to the tickets table, forms and workflow. The additional fields need careful planning so as not to impact existing record types, security definitions and business rules.

Performance and scalability

While a single-table architecture begins efficiently, accommodating fewer records and OOTB fields, its performance may decline as record volume grows — unless you maintain database hygiene and indexing diligently. Additionally, the inclusion of custom fields can further exacerbate potential performance dips.

In general, best practice for database tables is to:

• Avoid unnecessary table fields.
• Normalize data where possible to reduce redundant fields.
• Only query and return the fields you need.
• Properly index fields in the table to optimize performance.

How does an ITSM system with a single-table approach ensure performance and scalability?

While a single-table data model simplifies some aspects of IT service management, it does have limitations that you need to understand.

3. The case for modular ITSM architecture

A modular ITSM architecture is one in which each ITSM process is modelled as a distinct business object and related to other business objects (processes); for example, incident to problem, or problem to change. This modular approach closely follows ITSM processes and ensures that data is isolated, which provides several benefits.

Process-specific workflows

In a modular table design workflow, SLAs, approvals and business rules can be unique to the table (process). There's no requirement for special filtering to prevent the workflow running against a record of a different type (ITSM process). For example: escalation running criteria against an incident on breach of an SLA.

Under this approach, there is smoother alignment with ITIL best practices and governance, effectively stopping execution against non-ITIL processes (like HR Cases or Facilities Work Orders).

Improved security

By segregating tables by process, you enhance security, mitigating the risk of inadvertent access to sensitive data. Here, access is granted only to those explicitly authorized, with additional security measures readily adaptable to target specific data and records.

Moreover, separate table security ensures that reporting and exporting follow standard table security rules, rather than more complex row-level security.

Enhanced customization

Process-specific tables offer greater configuration flexibility, ensuring that changes in one process don't impinge on others (or on widely used fields). Unique field configurations at the table level eliminate the need for intricate business rules, extending our support to more complex scenarios, such as CAB approvals for changes or root cause analysis for problems.

Advanced reporting & analytics

With process-aligned tables that hold structured data, granular reporting, trend analysis and KPI tracking across ITIL domains is now more feasible, and incorporating related data is simplified. For example, a report that illustrates all incidents resolved by changes.

This also facilitates compliance reporting and executive dashboards across process or enterprise business objects (e.g., HR cases, facilities work orders).

Better integration & extensibility

The streamlined integration with external systems includes individual tables that align with processes. This method not only simplifies API exposure but also enhances security (as APIs require explicit access to the table’s API).

This enables low-code/no-code extensibility for accelerated innovation and the flexibility to extend existing business objects or create new ones.

4. Questions to ask

A single-table data structure may constrain future growth. When evaluating ITSM systems, it’s crucial that you thoroughly understand the underlying data architecture.

Ask the following questions of your ITSM vendor:

• Do you have separate tables across your ITSM processes, or are they in the same table?
• How hard is this to maintain and secure?​
• What's the impact of adding a new function, like Legal Requests?​
• How difficult is it to replicate custom functionality in the tool?​
• How long will it take to create a custom object​?
• How hard is it to secure the data from unauthorized access?
• Can you show me how to add new fields and new objects?
• How many people are required?​
• What will it cost?​
• Will I be able to upgrade?​

5. Which ITSM architecture is right for you?

A single-table ITSM solution, like HaloITSM, is a good starting point for organizations that want to get up and running quickly with a simplified user experience. But these solutions can create growth and scale challenges for mature, enterprise-level IT operations.

As organizations look to align with ITIL, automate complex workflows and integrate across the digital ecosystem, a modular architecture like Ivanti Neurons for ITSM provides the flexibility, scalability and control needed for long-term success.