Business Rule Designer – Problem Management

After Business Rule

Use an After Business Rule in Problem Management when a field or related record must be updated immediately after the problem record is submitted, and the results must be visible to the user right away.

When a Problem record is created or updated, the After rule executes after the data is saved to the database. During this time, the Problem record is temporarily frozen, and no additional updates are allowed until the rule finishes processing.

This mode suits actions that must occur before the user continues working, ensuring accuracy and consistency in the problem data.

Async Business Rule

The Async Business Rule runs asynchronously in the background and does not freeze the Problem record. Users can continue working—performing transitions, adding work notes, linking incidents—while the background processing continues independently.

This mode is ideal for non‑urgent or backend operations such as updating related tables, recalculating downstream fields, synchronizing CI data, linking multiple incidents to a Problem, or sending notifications.
Async rules minimize user wait time because the work happens behind the scenes.

Scenario 1 — Auto‑Populate Problem Fields Based on Symptom Pattern

Context:

Ryan, an end‑user, submits multiple incidents related to application outages. A Problem Manager creates a new Problem record to investigate recurring failures.

Scenario:

A Business Rule is configured in After mode to automatically update the Problem Category to “Application Failure” and assign the Workgroup to “App Support Team” if the Problem Symptom contains the keyword “Application Crash”.

What Happens:

• When the Problem is submitted, the After Rule fires immediately.

• The system freezes the Problem record until Category and Workgroup updates are complete.

• Once processed, the fields update instantly and become visible to the user.

Why After:

Because these fields must be updated before investigation continues, ensuring the Problem is routed correctly and consistently.

Scenario 2 — Validate Root Cause Before Saving the Problem

Context:

Maxwell, a Problem Analyst, documents the preliminary root cause after completing diagnostics.

Scenario:

A Business Rule is set to trigger in After mode when the Problem Status is changed to “Root Cause Identified”.

The rule automatically:

• Updates the Root Cause Summary based on internal logic

• Ensures the Known Error field is populated

• Verifies mandatory data before allowing status change

What Happens:

• When Maxwell clicks Submit, the After Rule executes immediately.

• The Problem record remains frozen and locked until validations and field updates finish.

• Only then is control returned to the analyst.

Why After:

These updates must happen synchronously to maintain accuracy and ensure every user sees the validated, updated record.

Example Use Cases for Async Execution Mode:

Scenario 1 — Notify Stakeholders When a Problem Becomes High Priority

Context:
A Problem has been escalated to High Priority due to repeated service outages affecting production.

Scenario:
An Async Business Rule is configured to notify:

• Head of IT Operations

• Problem Review Board

• Impacted Service Owners

Whenever a Problem is updated to Priority 1 (P1).

What Happens:

• The Problem record does not freeze.

• Notifications are sent in the background.

• The analyst can continue investigation steps without interruption.

Why Async:
Notifications do not need to delay the user—they can run quietly in the background.

Scenario 2 — Auto‑Link Related Incidents in the Background

Context:
Maxwell creates a new Problem after identifying a pattern across many incoming incidents.

Scenario:
An Async Business Rule is configured to:

• Scan for incidents with matching symptoms

• Link all related incidents to the Problem

• Update the Problem’s Related Incidents list automatically

This rule runs whenever the Problem is created or updated.

What Happens:

• The Business Rule runs asynchronously, allowing Maxwell to continue working.

• The Problem record remains editable while the system links incidents in the backend.

• No freezing or delays occur.

Why Async:
Linking dozens—or hundreds—of incidents can be time consuming and should not block user activity.

The following trigger types are supported for Problem Management:

• Create: Select this check box to execute the business rule when a record is created.

• Update: Select this check box to execute the business rule when a record is updated.

• Schedule: Select this check box to execute the business rule when a record is scheduled.

Note:

If Schedule check box is selected, then When must be selected as Async.

Calendar icon is displayed if the schedule job is configured for this business rule.

Scheduled Business Rules

Business Rules configured with the Schedule trigger execute automatically at defined intervals.

This can be used for scenarios such as:

• Sending notifications

• Auto-updating Problem Records

• Monitoring records based on SLA or timelines

Administrators can also define whether the rule should execute:

• Anytime

• Only during business hours

• Only outside business hours

Note:

Scheduled Business Rules are useful for automating periodic Problem lifecycle activities such as review and closure.

When there are multiple conditions which need to be computed together, these conditions can be grouped together in a Business Rule. This can be achieved by using the AND/OR conditions and by using the grouping functionality provided in the tool.

Here is an example scenario which shows how we can use Grouping of Conditions to achieve the best results:

Example:

Scenario:
Fredrick wants to automatically close low priority Problem records that belong to the End User Computing workgroup, ensuring that resolved and low-impact Problems do not remain open unnecessarily.

Solution

Trigger

• Module: Problem Management

• Trigger Type: Schedule

Condition

1. Status = Resolved

2. AND Priority = Low

3. AND Impact = Low

4. OR (Workgroup = End User Computing AND Impact = High)

Action

• Update field Status = Closed

Figure: Example of grouped

Standard Attributes

Operator

Based on the selected field value, the operators are displayed. Select the required operator from the drop-down list.

List of Operators Supported

Understanding and using the recipient section appropriately helps in effectively notifying the stakeholders. The recipient is divided into two sections which are displayed based on the selected medium:

To - The "To" field is used to specify the primary recipients of the notification. These are the individuals or groups that the sender expects to read and respond. Include the main recipients who are directly involved or expected to act.

Cc - The "CC" field is used to include additional recipients who may be interested in the notification content. CC recipients are not the main addressees but are still receiving a copy for information. Inform others or keep them in the loop without making them the primary audience.

You can add the type of recipient based on their groups. The types of recipients are explained in the following table:

The following table describes the fields on the Notification pop-up:

The following table describes the fields on the API pop-up:

Linked to this Business Rule

Under this section, you can view the list of APIs linked to this Business Rule. Also, you can edit and delete the APIs available under this section.

Linked to other Business Rule

Under this section, you can view the list of APIs linked to other Business Rules. Also, you can edit and delete the APIs available under this section.

Unlinked APIs

Under this section, you can view the list of unlinked notifications. These notifications are created but not linked with any business rule.