ISSUE SUMMARY:

• fields did not update on [change_request] record
  
• state field did not update
• workflow ran but parent record did not update
• Operation against file '<table_name>' was aborted by Business Rule 'SNC - Run parent workflows'
• If a task or approval record was updated and fired off the workflow on the parent record, if the WF update is aborted the WF context will advance forward without updating the parent record, this situation will cause the parent record to be at an odd state with the WF

MOST PROBABLE CAUSE:

• custom bus.rule where setAbortAction is called
• in OOB configuration, the change management state model did not allow the update to record

When reviewing node logs we might stumble across the following entry:

10:37:27.205    Info    Default-thread-14   92C15D161B272254FC82773BDC4BCBD9    txid=0b662e551ba7 Operation against file 'change_request' was aborted by Business Rule 'SNC - Run parent workflows^c5f012d91b270854cf82773bdc4bcb55'. Business Rule Stack:SNC - Run parent workflows,P1-P2

However, after further review, we note that business rule "SNC - Run parent workflows" is out-of-the-box and no setAbortAction method is being called

So we're left wondering how was the transaction aborted?

In a normal transaction where GlideRecord is updating a record and triggers a Business Rule with the setAbortAction method, this BR would show up in the node logs, however, in this node log entry is different because 'SNC - Run parent workflows' is out-of-the-box and has no abort method.

Usually how this BR is triggered is when an [sc_task] or [change_task] is closed, this BR triggers "after" the database operation, this BR wakes the WF up on the parent task record, moves the WF forward and then attempts commits this changes to the parent task, it is at this point some business rule is aborting the operation.

If we review the node log entry again, we see a comma after the name 'SNC - Run parent workflows' what follows next is the BR that aborted the transaction. In this case, a custom BR is named: P1-P2

This could cause unexpected behaviors on the parent task record since this type of operation is intended to be aborted. If this is the case, then all customization where abort should occur would need to be re-evaluated before the [sc_task] or [change_task] is committed to the database.