3-Strike Rule – Strikes Still Firing After Incident Reassigned Out of On Hold – Awaiting Caller

[nameisnani]

Hi Community,

I have implemented the Three Strike Rule automation for Incident Management and encountered an issue during testing around reassignment. Looking for guidance from anyone who has handled a similar scenario.

---

WHAT WE HAVE CONFIGURED

We built the Three Strike Rule using the following components:

- Custom Field 1: u_on_hold_timestamp – stores the date/time when an incident is moved to On Hold – Awaiting Caller

- Custom Field 2: u_reminder_status – tracks the current strike stage (Strike 1, Strike 2, Strike 3, Auto Closure)

- Business Rule – automatically populates u_on_hold_timestamp when Three Strike processing begins

- Client Script 1 – Reset Three Strike Fields on State Change – clears u_on_hold_timestamp and u_reminder_status when the incident moves out of On Hold state

- Client Script 2 – Reset Three Strike Fields on On Hold Reason Change – clears tracking fields when the hold reason changes away from Awaiting Caller

- UI Policy – shows the Three Strike tracking fields only when the incident is in On Hold – Awaiting Caller

- Flow Designer Flow: Inc_ThreeStrikeRule_Automation – handles Strike 1, Strike 2, Strike 3 reminders,

calculates wait times using a business schedule (excludes weekends and public holidays), updates u_reminder_status after each reminder, and auto-closes the incident after Strike 3 if no response is received

- Choice List updates for u_reminder_status values

- Incident Form Layout updated to display both custom fields

---

THE ISSUE

When an incident is in On Hold – Awaiting Caller state and an agent reassigns it to a different assignment group, the following happens:

1. The Business Rule fires and correctly moves the state from On Hold to In Progress
2. The Client Scripts are designed to reset u_on_hold_timestamp and u_reminder_status when the state changes
3. However, because the state change is made programmatically by the Business Rule (server side) and not by the user directly, the Client Scripts do not fire for that state change
4. As a result, u_on_hold_timestamp and u_reminder_status are NOT cleared
5. The Flow Designer flow (Inc_ThreeStrikeRule_Automation) continues running against this incident and applies the next strike — even though the incident is no longer On Hold and has already been reassigned

In short: the strike automation does not stop after reassignment because the client-side reset logic is bypassed by the server-side state change.

---

WHAT WE THINK THE FIX IS

We believe the reset logic for u_on_hold_timestamp and u_reminder_status should be moved from Client Scripts to the Business Rule itself, so the fields are cleared server-side at the same time the state is changed.

Proposed addition inside the Business Rule, within the block that sets state = In Progress:

current.u_on_hold_timestamp = '';
current.u_reminder_status = '';

We also believe the Flow Designer flow should have a check at the start of each wait step to confirm the incident is still in On Hold – Awaiting Caller state before proceeding. If the state or hold reason has changed, the flow should terminate gracefully.

---

OUR QUESTIONS

1. Is clearing u_on_hold_timestamp and u_reminder_status inside the Business Rule the correct and safe approach?
2. Is there a recommended way to add an early exit condition inside a Flow Designer flow to stop processing if the incident state has changed?
3. Has anyone faced a similar issue where Client Script reset logic is bypassed by a server-side Business Rule state change — and how did you handle it?

Below is the business rule we configured for making worknotes mandtory whenn state is on hold .

(function executeRule(current, previous) {
 
    // Run only on update
    if (current.operation() !== 'update') {
        return;
    }
 
    // Check if reassignment happened
    if (current.assignment_group.changes()) {
 
        // Requirement 2: Work notes mandatory for any reassignment
        if (gs.nil(current.work_notes)) {
            gs.addErrorMessage(
                'Work notes are mandatory when reassigning an incident.'
            );
            current.setAbortAction(true);
            return;
        }
 
        // Requirement 1: If previous state was On Hold, move to In Progress
        if (previous.state == 3) { // 3 = On Hold
            current.state = 2; // 2 = In Progress
        }
    }
 
})(current, previous);

@Ankur Bawiskar  Need your help here - Please let me know if you need any screenshots from my end 

Any advice or alternative approaches are greatly appreciated. Thank you!