Before Business rule is not updating the SLA's to flip back from Paused to in-progress

[AzizM]

Hi All,

I have been using before update business rule with the below code:

Condition code:: (current.caller_id.user_name == current.sys_updated_by || current.opened_by.user_name == current.sys_updated_by) && current.assigned_to.user_name != current.sys_updated_by

Script:  current.state = 19; 

and it was not flipping back the SLA from state - paused to state - in progress.

The state is getting changed and the comments are getting updating on the incident form, but it is not updating the SLA to trigger(SLA conditions are met)

Note: When i'm updating the state manually, the SLA's are updating as expected.

Thanks,
Aziz.

[Vikram Reddy]

@AzizM , the fact that state actually flips to 19 and the comments update tells you the business rule itself is firing correctly. The disconnect is downstream of that: SLA pause/resume isn't driven by the field write, it's driven by a separate re-evaluation cycle that happens after the record is saved.

Here's the mechanism. Out of the box there's an after business rule on the task table called Run SLAs (order 101) that fires on every insert and update. It hands off to the TaskSLAController script include, which re-checks the Start, Pause, Stop and Reset conditions on every active task_sla record tied to that task, against whatever is now committed on the record. A good writeup of this flow is here: SLA Engine, a developer's perspective.

Because Run SLAs is an after rule, it always executes once all before rules (including yours) have finished and the record is saved, so in theory your current.state = 19 should be just as visible to it as a manual save from the form. When that's not happening, it's almost never the before/after ordering itself, it's one of these:

1. Something else touches the record again after your rule runs, in the same transaction or immediately after (another business rule, a Flow, or a script include called later in the stack). Run SLAs then evaluates that later, competing value instead of your state=19, so the Pause condition never sees a clean "not paused" state. Check for any other before/after rule or Flow on incident that fires on the same update and touches state, hold reason, or whatever field your Pause condition actually keys off.
2. The SLA Definition's Pause condition is checking a field other than the plain state field, for example a legacy incident_state reference, an on-hold reason field, or an approval/assignment condition that your script doesn't touch. Open the SLA Definition, look at the Pause condition exactly, and confirm the field and value it expects match what your before rule is actually setting.
3. Double check the business rule is set to Advanced with that script as the actual condition, and there's no separate Filter Condition underneath that also has to evaluate true. If the advanced condition and a filter condition both exist, both must pass for the script to run.

To isolate which of these it is, open the affected task_sla record and use the Repair related link/UI action. Repair forces TaskSLAController to re-run its condition logic against the record as it stands right now. If Repair flips it to In Progress immediately, the Pause condition really was satisfied, and your problem is timing/ordering with something else touching the record. If Repair does nothing, the Pause condition itself isn't being satisfied by state = 19, which points you back to check 2 above. There's a similar case worked through here that matches your symptom almost exactly: Business Rule to release an incident from On-Hold is not causing the SLA to resume, and ServiceNow documents the general "meets the condition but doesn't flip until Repaired" pattern in KB0745555.

I'd start with Repair since it tells you in one click whether this is a condition mismatch or a competing-update problem, then fix the actual field/rule rather than guessing at the business rule script.

Thank you,
Vikram Karety
Octigo Solutions INC