Why Use Before Business Rule for Validation Instead of After?

[neerajydv11]

Hi Everyone,

I wanted to understand why validation logic should be implemented using a Before Business Rule instead of an After Business Rule in ServiceNow.

In what scenarios is this approach preferred, and what issues can arise if validation is done using an After Business Rule?

It would be really helpful if someone could explain this with a real production example.

Thanks in advance!

[prerna_sh]

Hi @neerajydv11 ,
 "Before Business are" a type of business rule that executes before a record is inserted or updated in the database. These rules allow you to perform actions and validations on the record data before it is saved.

Situation: Depending on their role, you would like to prevent users from changing specific fields on a record.

1. Goal: Preserve data integrity by limiting illegal modifications to vital fields.
2. Execution: Before Business Rule: Establish a before-business rule on the table (such as an incident) where it is necessary to restrict unauthorized updates.
3. Conditions: When particular fields (like assigned_to or state) are changed, the rule is triggered.
4. Step: Verify the user's role; if they don't have the necessary role (like ITIL), deny the update

------------------------------------------------------------------------------------------------------------------------------------------------------
After Business Rule: Use to perform automated actions or logic after a record is inserted, updated, or deleted in a specific table. It is a server-side script that executes after the database transaction has occurred.
Use Case: Notify the change manager and impacted users via email when a change request is approved.

-------------------------------------------------------------------------------------------------------------------------------------------
If my response solves your query, please mark helpful by selecting accept as Solution and Helpful. Let me know if anything else is required.
Thanks,
Prerna

[Vishal Jaswal]

Hello @neerajydv11 

I would encourage you to try below in your PDI:

Navigate to All > Incidents > All and find the total count of incidents (let's say 100).
Create a Before Query Business Rule to only show incidents created by the logged in user as shown below:



You will understand Before Business Rule better.

Now, imagine that everyone in your team is creating P1 incidents without actually adding Business Impact value and you need validation from incident creators that before incident is saved, Business impact is populated then you have onChange Client script, making the field mandatory options however before business rule can also be used here just for learning purpose:



Another user case is to avoid duplicate incident creation via API. Let's say there is a third party API in your organization which creates incident and populate incident's correlation id field value and you want to reject any duplicate requests for same correlation id because there is already active incident.

So, you can use rest api explorer to create such dummy incident in your PDI as shown below:


Create a Before Insert business rule on the Incident table as shown below:

Hit send on the same REST API Explorer and this type you will get 403 Forbidden error as shown below:


NOTE: For API record creation it is recommended to use "!gs.isInteractive()" as a best practice or in general when you know where human interaction with UI Page/form is not required, there you can use it.

With such learnings you will be able to learn and identify when to use before business rule.