Hello @Pragati Malviya,
Intended: ^(?!HCL).*
Saved as: ^^^^^^^(?!HCL).*
That mismatch is why HCL Priority 4 Gold - Resolution SLA sits at "In progress" while Total Time - Pending pauses fine on the same incident, INC7335287, at the same 18:xx timestamp. The matches regex operator in the condition builder treats a leading caret as the encoded query's AND delimiter, not a regex anchor. Every time that pause condition row gets touched again (edited, or a new OR clause added underneath it, which is what your second block is), the platform re-encodes the value and tacks on another caret. That's how you end up with seven of them stacked in front of the lookahead. Since that malformed row is part of the same encoded query string as your "State is one of Pending, Resolved" OR block, a broken leading condition can stop the whole pause condition from parsing correctly, not just that one row, which is why the OR'd State clause never fires either even though the incident is clearly in Pending.
- Rebuild that condition row from scratch: drop the caret entirely and write it as (?!HCL).* rather than anchoring it, then save once and leave it alone.
- Run Repair on the affected task_sla records afterward, existing SLA instances won't retroactively re-evaluate against the corrected condition on their own.
Thank you,
Vikram Karety
Octigo Solutions INC
