Business rule : Display

[ZebaT]

I read community answer that Business rule: Display is used when say child incident task wants to get field value of parent table incident . Can someone give some other use case of this Display.

Thanks

[GlideFather · Accepted solution]

Hi @ZebaT,

display business rule is very powerful together with g_scratchpad.

When I used it the last time, it was when a requested item was loaded (= displayed), the BR checked where there is any pending approval for this particular RITM and if yes, it marked the scratchpad true, if no approval, scratchpad was false. And based on the scratchpad values a client script was hiding or keeping the Approval state field visible or not.

This use case was because most of the RITMs had an approval but a very few had no approval and the OOTB process showed field "Approval: Requested" and it was confusing for clients. Because there was no approval at all and thus it couldn't be Approved either... so we just hid the field described above :))))

[Mohammed8 · Accepted solution]

Hi @ZebaT 

Your understanding is correct.

While working on the Work Order form, there was a requirement that if a Work Order is created from an Incident and if the Incident had High priority, the qualifier/initiator user should be aware of incident priority when the Work Order form opens. To achieve this, a Display Business Rule was used on the Work Order table to check the related Incident’s priority when form load. If the priority was High and an info message was displayed on the Work Order form using client script. Display business rule was chosen cause it does incident record server check.

Thanks and Regards,

Mohammed Zakir

[PrashantLearnIT · Accepted solution]

Hi @ZebaT 

Display Business Rules (BRs) in platforms like ServiceNow are server-side scripts that execute before a form is presented to the user. Their primary purpose is to pass server-side data—such as field values or calculated results—to the client using the g_scratchpad object.

This allows client scripts to leverage that data for dynamic form behavior, including personalizing the form, showing or hiding fields, or setting default values, all without writing anything to the database.

Common use cases include auto-populating related task fields (for example, Assignment Group) when opening a new record from a parent record, displaying user-specific informational messages, and setting default values for fields that may not be directly present on the form.

[GlideFather · Accepted solution]

Hi @ZebaT,

display business rule is very powerful together with g_scratchpad.

When I used it the last time, it was when a requested item was loaded (= displayed), the BR checked where there is any pending approval for this particular RITM and if yes, it marked the scratchpad true, if no approval, scratchpad was false. And based on the scratchpad values a client script was hiding or keeping the Approval state field visible or not.

This use case was because most of the RITMs had an approval but a very few had no approval and the OOTB process showed field "Approval: Requested" and it was confusing for clients. Because there was no approval at all and thus it couldn't be Approved either... so we just hid the field described above :))))

[Mohammed8 · Accepted solution]

Hi @ZebaT 

Your understanding is correct.

While working on the Work Order form, there was a requirement that if a Work Order is created from an Incident and if the Incident had High priority, the qualifier/initiator user should be aware of incident priority when the Work Order form opens. To achieve this, a Display Business Rule was used on the Work Order table to check the related Incident’s priority when form load. If the priority was High and an info message was displayed on the Work Order form using client script. Display business rule was chosen cause it does incident record server check.

Thanks and Regards,

Mohammed Zakir

[PrashantLearnIT · Accepted solution]

Hi @ZebaT 

Display Business Rules (BRs) in platforms like ServiceNow are server-side scripts that execute before a form is presented to the user. Their primary purpose is to pass server-side data—such as field values or calculated results—to the client using the g_scratchpad object.

This allows client scripts to leverage that data for dynamic form behavior, including personalizing the form, showing or hiding fields, or setting default values, all without writing anything to the database.

Common use cases include auto-populating related task fields (for example, Assignment Group) when opening a new record from a parent record, displaying user-specific informational messages, and setting default values for fields that may not be directly present on the form.

[Ankur Bawiskar · Accepted solution]

@ZebaT 

Consider an example:

-> when you open incident form there is a related list of incident task

-> now when you click New in Incident Task related list a new form of Incident Task is opened

-> Now if you want to grab some field value from INC which is parent of Incident Task you can use Display BR on incident_task

Example:

(function executeRule(current, previous /*null when async*/ ) {

    // Add your code here
    gs.addInfoMessage("Parent INC description is" + current.parent.description);

})(current, previous);

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏