OOB Business Rule update - and Impact??

[Lucky1]

Hello all,

There is oob business rule in our system.

It is "Change reverted to New".

So, it is before update BR.

Because of my business requirements, I need to update this BR, to after update.

So, can someone please explain me what could be the impact if I do this?

Regards,

Lucky

[Kieran Anson]

Can you share why you're looking to change this business rule? What is the business requirement?

[Lucky1]

Hello Kieran,

We have a custom BR, where in some cases, when the user clicks on Revert to New button, then the system throws error, saying "Cannot be reverted to New" at this time. 

But even though the system is throwing that error message, because of the oob BR I mentioned, the approvals are getting cancelled.

But my requirement is, the approvals should not get cancelled, when an error message is displayed.

Regards,

Lucky

[Nishant8]

Hello @Lucky1 , I'll suggest not moving the 'Change reverted to New' Business Rule from Before to After. Doing so might lead to a major risk of data integrity issues.
If a Change Request is successfully moved to the 'New' state but this Business Rule fails to execute for any reason, outstanding approvals from previous stages will remain active. Consequently, as the Change Request progresses through the lifecycle again, you will end up with duplicate/conflicting approvals.
Instead of changing the OOB BR, you can consider following approaches:
- Handle Errors via Abort Actions: We can identify the specific scenarios where the custom Business Rule throws an error and simultaneously abort the transaction using current.setAbortAction(true). This cancels the database save entirely, ensuring the OOTB rule is never improperly triggered.
- Utilize the Model Condition: The 'Change reverted to New' Business Rule specifically executes when the Model field is empty. In your custom Business Rule, you can control the execution flow by dynamically ensuring the Model field is non-empty whenever your validation error is displayed.
Since you have clear visibility of your instance's current configurations, it is much safer to control the logic within the existing execution flow rather than converting a core OOTB rule from a Before to an After state.
Additionally, you can refer below if planning to move to Flow Designer:
https://www.servicenow.com/community/itsm-forum/quot-revert-to-new-quot-in-change-flows/m-p/3521212

Regards,

Nishant

[henry_collins]

Moving an OOB “before update” business rule to “after update” can change the whole timing of when your logic runs. In before update, it can still modify field values or even stop the update, while after update runs when the record is already saved and changes are committed. So if your rule is currently relying on changing values or controlling the update flow, it may stop behaving as expected once moved.

Main impact is usually: loss of ability to influence the current transaction + possible need for extra updates. Best approach is to carefully test in sub-prod and confirm whether the logic truly needs post-save execution.