The automation of IT Service Management (ITSM) workflows using explicit rules and data has been established for years. Domain-specific rule engines interpret rules written in declarative rule modelling languages and generate forwarding arrows to process event streams and support decision making. Such automation is augmented by rule-driven Quality Assurance for correctness, safety, and risk management. The service desk is the onshore base of an ITSM supply chain. An end-to-end incident response service resolves incidents using only onshore resources and employs back office teams to help with unresolvable incidents. The forward factories of rule-based automation for ticket processing service are identified. Several rule-based workflows in incident and change management have been published. Further glimpses of the future across all ITSM workflows are provided based on training in an online ITSM service with automated operations. Rule engines are specialised components that direct the processing of data flows according to pre-defined rules. Decision factories complement the more common event-driven rule engines. While event processing occurs below the polling frequency of the source, rules in decision factories are triggered based on the arrival of data. These factories are applied in ITSM for risk and safety evaluation and quality assurance. Rule-enriched architectures incorporate domain-specific modelling languages to ensure correctness with respect to qualitative quality attributes. Dedicated factories provide resilience, detect slack or over-utilisation, and offer point-in-time assurance and testing.

At their simplest, situation-action rules can be viewed as decision tables stored in an accessible form using a declarative language. Although facility management can include parts of IT service management (ITSM), IT service delivery still requires dedicated approaches.

The delivery of IT services is colocócated management, business processes, business service development, and business service provision. Using an event-driven Kingfisher approach allows a dedicated IT service management rule engine to fulfil the management architecture. Although several IT service management suites combine service request workflows with orchestration engines, rule-based automation focuses on common patterns for service request and incident workflows to achieve the promised added value with respect to the cost of implementation and change.

1.1. Overview of Rule-Based Automation in ITSM

Automation of service management workflows, such as in-service desk and change-management operations, enables tedious tasks to be performed without human intervention. Often this is an extension of automation that has been in place for many years but is based either on application program interfaces (APIs) or on rules embedded in scripts. In IT service management (ITSM) the underlying patterns are now becoming more common, namely automation based on a rule engine, commonly labelled rule-based automation.

Figure 1

From Decision Factories to Real-Time Response: Orchestrating Event-Driven Architectures for Intelligent ITSM Automation

One of the most important tasks in rules-based automation is the definition of the set of rules that a rule engine must be able to execute. Depending on the volume of events and jobs that are managed, these rules can be defined in a different tool, known as a decision factory [13]. As the load increases, a move to an event processing engine allows for real-time evaluation of the service-management events and a more immediate response. Event processing is a very important subset of the event-driven architecture style and is supported by complex event-processing systems. Event-driven architectures have a demand-response approach, responding to events and demands as they emerge, while batch processing performs a sequence of operations on an entire data set [14].

Although early ITSM automation was mainly script-based an emerging trend towards rule-based automation is supported by greater availability of event-driven service management technologies, the simplicity of rule design, and an approach to operational ITSM that is similar in spirit to event resolution expertise [15]. Four issues are explored: a unified definition of rule-based automation in ITSM, design patterns for rule-based ITSM automation, the characteristics of rule languages suitable for rule-based automation, and examples drawn from the incident management and change management workflows considered in service operation.

Automation services that help to scale up and improve control of operational ITSM work are important components of closing gaps in comprehensive ITSM service portfolios [16]. Scripting-based services are a huge success, and there is a growing number of accessible and easy to use decision worker systems and tools. Just-in-time decision factories which are event or signal driven in nature can use these components as part of their operations to make decisions in a timely manner. Furthermore it is possible to manage decision factories that often operate in batch mode based on offline data. The availability of decision workers is playing an important role in shifting towards rule-based automation of operational work [17].

Equation 1) Step-by-step derivation of the core “rule engine” model (event-driven)

Step 1: Represent an incoming event as structured facts

Let an ITSM event (incident/alert) be represented as a vector of facts:

Step 2: Define a rule as a condition → action mapping (situation-action)

A single rule $r_i$ is:

• $C_i\left(e\right)$ is a boolean predicate (condition part)
• $A_i\left(e\right)$ is the action (route ticket, notify, create change, escalate, etc.)

Step 3: Determine which rules “fire” for an event (rule matching)

For a set of rules $R=\{r_1,\dots ,r_m\}$, define the triggered subset:

Step 4: Resolve conflicts (if multiple rules match)

If several rules match, most engines apply priority/salience, specificity, or agenda ordering. Model this as a scoring function:

Choose the executed rule:

Step 5: Execute action(s)

If actions are single-choice:

If actions are multi-rule (allow several to fire), then:

2.1. Definitions and scope

Rule-based automation (RBA) denotes the use of explicit codified business rules to support or enable autonomous execution of IT Service Management (ITSM) workflows. It has become increasingly prevalent during the last decade, spurred by the advent of new supporting software technology, rising operational cost and associated service quality issues, and the growing business appetite for faster-paced IT service provisioning [18].

One major area of RBA activity concerns the automation of incident management workflows, including triage, service restoration, and first-level staff activities. Such automation is generally driven by rules that detect service-affecting incidents, classify them according to predefined criteria, and implement appropriate reactive or proactive responses. A related but separate area of RBA investigation focuses on the use of decision factories to deploy and execute IT service change workflows that are governed, in whole or in part, by business rules [19].

2.2. Historical development and motivations

Despite the historical development of IT Service Management (ITSM) automation being difficult to chronicle, scattered historical records indicate that the first information technology jobs that were related to ITIL incident management were highly repetitive in nature and were therefore automated from the beginning. The first use cases for company-wide automation of ITIL incident management processing were explored in a banking environment in Switzerland around year 2000. Such rules-based automations were later adapted for supporting the ITIL change management process in a Swiss bank. In both cases, some additional risk analysis procedures were added to the original incident management automations for fulfilling the risk assessment requirements defined in the ITIL procedures [20]. For a few years these automations operated in the target environments without business engagement disturbances until the introduction of business engagement unit processing checks. This unit check required checking business engagement on every automated processing and not just checking it every second or third time [12]. The changed business requirement was not properly communicated to the ITIL process owner and escalated along the normal ITIL escalation channels within the banking company environment. Therefore, the original automations executed under the authority of the ITIL process owner and without any business engagement unit check remained operational even after the formal introduction of this new requirement [21]. Over these years several other job roles were operationally engaged to perform similar and simple checks to route end-user requests to the respective teams for fulfilling the user requests for service support such as for printer, network, SAP, etc. All these simple routing roles were later merged to create process owners for dedicated process rs for routing process in the United Kingdom [22].

Rule-Based Automation for IT Service Management Workflows

Architectural patterns for IT service management automation. Rule-based automation encompasses various distinct architectural approaches, two of which arguably dominate day-to-day IT service management operations: the rule engine pattern and the decision factory pattern[11]. In the rule engine approach, an event, often signifying a significant change of state in an operational service or environment, serves as a trigger that causes one or more rules to be evaluated in a thematic rule engine. The typically discrete, open-ended nature of relevant events suggests and facilitates the use of an active computing paradigm (see, for example, Schuster et al. 2019). Conversely, a decision factory operates in batch mode, continually evaluating the same set of decision-making rules across a much larger volume of work that usually pertains to ongoing operations [23].

In IT service management (ITSM), the terms “event” and “incident” are often used interchangeably. Therefore, the images in this section illustrate rule engines operating in ITSM contexts. A number of actual and potential scenarios for invoking incident-management rule engines can be considered: breakdowns detected by automated monitoring tools, alerts escalated by human operators, requests from systems or applications, or simple “calls to arms” to fill urgent capacity gaps. Resilience, a crucial quality for any ITSM process, is a paramount concern for rule-engine implementations [24].

3.1. Rule engines and decision factories

Rule-based automation in ITSM can be realized within an event-driven architecture where dedicated rule engines act on incoming events as they happen, or via batch processing using a decision factory architectural pattern. In the first case, events matching rule conditions trigger the execution of corresponding actions. In the second case, events first enter a queue, and a dedicated decision factory processes them in a predefined order according to the business constraints [25].

The best approach depends on the system and the types of events processed. An event-driven approach is more efficient when the incident management rules require immediate or near-immediate decisions and actions [10]. A decision factory may generate a delay between an incident being raised in, for example, an external monitoring system and an associated change request in the change-management system, but the batch approach also has several advantages. It can be implemented centrally, with a single alert-batch engine capable of processing alerts from different sources; it can take resource-control decisions over alerts coming from different external systems; and it can leverage all available information by looking at all active alerts together [26].

Figure 2

Balancing Immediacy and Oversight: Event-Driven vs. Decision Factory Patterns in Automated ITSM

3.2. Event-driven vs. batch processing

Two architectural patterns for implementing rule-based ITSM workflow automation are event-driven systems, in which rules are fired as events occur, and batch-processing systems, in which the rules are applied periodically to a set of relevant objects. Event-driven rule execution has long been associated with publish-subscribe architectures, including forward-chaining production systems. These systems have traditionally been complex, as rule furnaces must be assembled and tuned to give correct results, especially under high loads and when multiple events rush in bursts [27].

More recent work has, however, turned toward addressing the complexity of event-driven rules in ITSM implementations. According to previous studies, the ability to compose and manage large numbers of small, independent rules can introduce flexibility, simplicity, and transparency, as well as facilitate collaboration between different organizations. The properties of rule engines, such as retraceability and observability, can also assist the development of intelligent cybersecurity solutions [28].

An alternative to pure event-driven rule execution is the definition and periodic application of rule factories. In this approach, the rules are complex, implementing business logic and quality assurance, but the execution cycle is straightforward and fast [9]. Although this can lead to loss of content on crashes and limit responsiveness to events such as drastic changes in the IT park, it is simpler to manage than approaches with event-oriented high-load rule engines [29].

Figure 3

Functional Theme Importance Derived from Textual Frequency

Rule-based systems translate knowledge about an application domain into decision-making logic expressed in a form understood by a specialised computer program. Typically, this is a rule engine, which is designed to perform optimised forward or backward chaining over rules and facts. Rule engines and fully declarative systems permit rules to evolve rapidly. At a different level of abstraction, modelling languages such as Decision Model and Notation support the design of rule sets that are managed in rule factories attached to operational systems such as ITSMs [30].

Operational ITSM automation rules can be encoded in rule engines or expressed in more general-purpose business process management, event processing, or workflow management languages that link to underlying rule engines for decision-making and data look-up tasks [8]. The semantics of these languages enable reliable model-based analysis and testing that confirm the properties of interest prior to deployment. ITSM automation is often ambiguous in language but monotonic by nature, permitting specialised rule engines to be used [31]. Error checking can be provided by standard linting tools, and coverage analysis applied to unit tests, both using decision table representation styles. Exceptions to primary functions can thus readily be built and managed, enabling a achieves-failure-then-do-something-else style of design [32].

Equation 2) Step-by-step derivation of “decision factory” (batch / queued) model

Step 1: Queue the incoming events

Let events arrive over time and be added to queue $Q$:

Step 2: Define a batch interval $\mathit{T}$

A decision factory runs every $T$ minutes (or at fixed schedule):

• Events arriving in $[kT,\left(k+1\right)T)$ are processed in batch $B_k$.
$B_k=\{e\mid t\left(e\right)\in [kT,\left(k+1\right)T\left)\right\}$

Step 3: Apply rules across the batch (global optimization / constraints)

Model as selecting actions $a_j$ for each event $e_j\in B_k$ to maximize utility:

subject to constraints:

Step 4: The batching delay

If the batch runs every $T$, the expected waiting time before processing starts (assuming uniform arrivals) is:

4.1. Rule modelling languages

Established modelling languages and software tools facilitate the specification of business rules for expert systems, with the objective of making imperative rules accessible to the business domain. The analogy is stricter, with a definition of a business-rule modelling language given as follows [33]: “A language that permits business users to define a business rule in order to make it available for use by rule engines located either within or external to the business modelling framework” (R. C. V. B. C. V. B. C. V. B. C. V. B. C. V. B. C. V. B. C. V. B. C. V. Bedini et al.).

The distinction between business-rule modelling languages and rule-modelling notations is brought out by Allen et al. in the context of modelling business rules for decision-support systems: “A business-rule modelling language provides a means for business users to create a set of business rules, which may be implemented as business processes or decision-support systems in a rule-modelling notation, no matter what its nature. The rule-modelling notation supports the formal specification of rules and their software-based management from a business-rule perspective [34].”

A variety of decision- and workflow-centric processes can benefit from rule-based automation tailored to decision capture, execution, and management. Rule-based systems can augment IT service management operations such as incident management and change management [35, 1].

Automation of incident management aims to increase throughput by generating accurate, low-risk, high-value responses to incidents while freeing human operators to focus on high-risk or consequential cases. Less than 20% of incidents can be completely automated without supervision, but the vast majority can be executed as decision factories—situations where rules provide explicit answers to most scenarios even if humans provide the decisions for a few. Typical rules capture the categorization and triage of incidents, and the orchestration of automated responses [7]. Even if the incident response is mostly automated, it may still require human confirmation because service owners need to give the green light for significant applications. If the incident requires simple queries for resolution, these requests can be generated automatically for any incident and assigned to the appropriate support group or team. The increasing volume of requests for password resets offers another example of incident resolution that can be streamlined or automated [36].

Automation of change management can streamline the operation while mitigating risks. The scope of automation often extends to risk assessment of individual changes and scheduling of changes in just a few steps. The operational and technical validation checklist typically remains under human control. Risk assessment can begin with a table of risk assessments for different change types, or a list or matrix of similar changes with associated levels of technical and operational risk. A change may still require the scheduling efforts of human operators, but these actors receive automated recommendations on the most suitable window [37].

5.1. Incident management

Various workflows in incident management are suitable for rule-based automation. Some of the simplest work items are the creation, acknowledgment, and escalation of incidents, which are often based on status changes or timeouts [6]. The rules invoked in these situations are typically trivial and indexed for efficiency [38]. Automated notifications to users of incident updates represent another common application. Although several of the service desk tools provide these notifications as built-in features, they are frequently ignored. Automated reporting of Open, High-Priority Incidents is another common work item. A list of such incidents is generated and emailed to a predetermined list of recipients on a scheduled basis. Policy dictates when these notifications are triggered [39].

Routing rules aim to direct incidents to the appropriate on-call individual, but these are often set up erroneously and require manual intervention to resolve problematic situations. A more sophisticated approach employs an off-line machine-learning model trained from historical assignment data to predict the target assignment group for incoming incidents [40]. The model output is cached for efficient access and incorporated into the rule process. The inference process yields a predicted assignment group that is checked against the existing data for accuracy. When the predicted assignment group is not the same as the actual group, an additional rule captures the condition and logs it for future retraining of the machine-learning model [41].

Figure 4

Hybrid Intelligence in ITSM: Integrating Rule-Based Automation and Machine Learning for Optimized Incident Management and Routing

5.2. Change management

During change planning, rules for risk assessment and risk treatment may use information from incident management (notably the known error database) or the wider IT service conFigure uration system models. Review and authorization for changes are also suited to rules, particularly if a risk assessment is combined with information about impact on service levels [42]. To assist management activity the rules may use the service catalog and service level agreement models and other relevant knowledge. It is then appropriate to use risk and impact assessment rules to determine the required authorization level [43, 2].

Automated execution of changes can be considered as the information orchestrator calling action executors associated with the automation toolset. When treatment of an identified risk is planned and these rules have provided an escalation to a pre-defined authorization group, either for awareness or action, SQL queries to the records in the problem management module will also assist. Integration with the automation toolset should provide feedback on execution success or failure, allowing associated errors to be raised and managed [44].

Particular attention must be paid to rules that control required manual activities, such as system provisioning. For example, in the context of incident management a rule may determine that the change request should be processed by the change manager instead of an automatic execution because the change is too complex or has too many dependencies [45]. An alternative approach for complex change requests is to use a two-step decision: if the rule factory deems the execution of the change request safe, then the rule engine directly executes the change request; otherwise it is escalated to the change manager. Whenever a manual step is involved the risk of human error increases significantly, which must be accounted for when designing the automation strategy [46].

In the event of a failure of the automated execution of a change request (e.g. incorrect provisioning), the process must be able to recover and continue without external intervention if possible. One alternative is to embed recovery logic in the execution state itself, but a better option is to define a corresponding negative scenario that is monitored by an incident management automation factory [47, 4]. For example, a rule may monitor the conFigure uration management database to assert that an application required by the change request has been provisioned correctly, and the creation of an incident in case of failure would complete the error-handling loop [48].

Equation 3) Step-by-step derivation of a latency/throughput model (illustrative, queueing-inspired)

Let:

• $\lambda$ = event arrival rate (events/min)
• $\mu$ = processing capacity (events/min), with $\mu >\lambda$

Event-driven expected processing delay (simple M/M/1 intuition)

A widely used approximation for mean time in system is:

Add a base overhead $t_0$ (parsing, rule evaluation setup, logging):

Batch decision-factory expected delay

Batch adds expected wait $T/2$:

6.1. Error handling and resilience

An error in rule evaluation can have severe consequences. Whenever an ITSM rule integration performs a non-null state change, this should be bypassed unless explicitly ruled safe [49]. There are usually two forms of rules that can trigger non-null state changes: corrective relaying rules, where an external event led to an undesirable state, and proactive relaying rules, where an external cause is detected that is probably going to lead to an undesirable state, warranting a preventive correction. In both scenarios, one wants to retain a level of confidence in the validity of the action imposed by the system [50].

Being able to relate different facts implicitly, resourcing a dependency graph of situational facts can help in automating error recovery [51]. If the dependency graph for a change is known, upon running an error-free clean-up a new clean situational fact can be generated and applied, allowing control to resume with a clean slate. The overall architecture can furthermore help achieving resilience, through automatic black-box rehabilitation. In accordance with the previous statement, as long a command is neither corrective nor proactive relaying, failing to evaluate should degrade gracefully without the need for any explicit error handling. The use of strategies and simplification rules, for instance, should relax to dead ends if completion no longer holds [52, 5].

As a result, a white-box system has been described that can be resourced as a black box. Black-box resilience emerges as a by-product of open architecture, while safety bugs are made detectable by describing them in a clean situation [53].

The proposal and examples provided illustrate how rule-based automation can easily and sustainably constrain workflows in ITSM processes other than incident management. Rule-based systems enable staging ATM change workflows without requiring switchover builds or DB schema changes, automatically promoting change request templates from ATM status to pre-production or production status based on upcoming schedules, other system releases of particular relevance, or simply expiration time.

Figure 5

Core Components of ATM Sustainability

Role and service group memberships are managed outside the ATM application but serviced with an initial integration that maps IT to business responsibilities [54].

An event-driven risk management system can automate much of the risk management process, categorising all ATM changes following normal service without the need for sign-off, automatically escalating the remaining changes for sign-off based on their risk classification, and preparing for the risk management board meeting by collecting and formatting the presentation material from the change tracking system. Adopting these patterns has the potential to reduce risk and speed ATM and other change workflows significantly. The requirement to input information twice or more in a temporary staging area, such as for change categorisation and risk assessment, is moot in practice, as current manual practices are error-prone and neglected [55].

Prioritising error handling is fundamental to delivering any kind of workflow automation component safely. Introduced as supervised pre-production playbooks beget unsupervised production playbooks, in full ATM mode or transition periods requiring residual supervision, it is essential to default failure recovery attempts by third parties and automatic escalation for management sign-off. With such measures in place, even ATM incidents caused by automated incidents can be accommodated [56].

7.1. Final Thoughts and Future Directions for ITSM Automation

Given the impetus from rising customer expectations and the consequent need for effective, efficient, and timely IT service delivery, rule-based automation of IT Service Management workflows offers a direction for increasing the throughput and quality of these services [57].

Rule-based automation requires • the systematisation and documentation of the industry policies and processes that guide IT service delivery; • an understanding of the risks of each [decision point] in the automation; and • an architecture that separates the code that makes decisions from the supporting machinery. By implementing these recommendations for three equally important ITSM workflows—incident management, problem management, and change management—the effort and risk in automating decisions are reduced. The quality of automation, measured by the level of throughput achieved, is then limited by the amount of bureaucratic work in these workflows, not the decision-making itself [58].

The increasing complexity and interconnectedness of IT systems will continue to increase the volume of decisions required to manage the systems, putting pressure on these subject-matter experts. Three strategies for dealing with this increasing demand will be improved tooling for the subject-matter expert, process-oriented documentation, and the reinforcement of training and practice. Of these, improved tooling can be applied most rapidly. A change in attitude is required: the improvement should incorporate and build upon existing decisions by the subject-matter experts, automation be within their control, and the risk from the uncontrolled application of system decisions understood and managed [59].