Display Business Rule and g_scratchpad

[asifnoor]

Hi,

In this article, I will explain the usage of Display Business Rules and g_scratchpad with 1 small requirement

Requirement: When creating a new problem task from Problem view i want to populate few fields of problem into the problem task such as Assignment group, Assigned to, problem statement.

So For this, we will create a Display BR on the problem_task table. The Display Br executes whenever we view a record on the problem_task.

Display BR

System Definition -> Business Rules ->New

Table: Problem_task

conditions: Parent is not empty (So that this BR runs only when click on new from existing problem)

Under Advanced, in the script add this code

(function executeRule(current, previous /*null when async*/ ) {
    var gr = new GlideRecord("problem");
    if (gr.get(current.parent)) {
	g_scratchpad.parent=current.parent;
        g_scratchpad.short_description=gr.short_description;
	g_scratchpad.assigned_to=gr.assigned_to;
	g_scratchpad.assignment_group=gr.assignment_group;
    }

})(current, previous);

Save the BR.

Then create a onLoad client script and there you will have access to g_scratchpad object and populate the values into the problem_task form.

Client Script

function onLoad() {
   //Type appropriate comment here, and begin script below
	if(g_scratchpad.parent) {
		g_form.setValue("short_description",g_scratchpad.short_description);
		g_form.setValue("assignment_group",g_scratchpad.assignment_group);
		g_form.setValue("assigned_to",g_scratchpad.assigned_to);
	}   
}

Let me know if you have any questions in the comments below.

Mark the article as helpful and bookmark if you found it useful.

Regards,
Asif
2020 ServiceNow Community MVP

[teeparti tarun]

Hi,@Asif, can you help me by providing 10 real-time use case scenarios of display business rules using g_scratchpad, so that I could get a grip and clarity on the Display Business rule topic

Thanking you

[Kosuru Manaswin]

The above scenario was not working can you help me out 

[Jagadish Sanadi]

@Kosuru Manaswin  could you share the code

[Tejas16]

@Kosuru Manaswin I also face the same issue.
To Resolve this issue:
I used current.problem instead of current.parent all over the code. and use trigger condition as problem is not empty.
It works.

[Kavitha17]

Use this BR for  the above scenario and the above client script then it works

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

        var gr = new GlideRecord('problem');

        gr.get(current.problem)

        g_scratchpad.parent = current.problem;

        g_scratchpad.short_description = gr.short_description;

        g_scratchpad.assigned_to = gr.assigned_to;

        g_scratchpad.assignment_group = gr.assignment_group;

    }

)(current, previous);

[pak-gerner_]

The AI explanation for this is great. I don't know if this was available at the time of the original post but sharing here;

Okay, here's a breakdown of the provided code snippet, focusing on clarity and readability:

Purpose:

This code is a Business Rule in ServiceNow. It appears to be designed to run when a record (likely an Incident, Change, or other task-based record) is created or updated. Its primary goal is to copy certain fields from a parent "Problem" record to a scratchpad variable, making them accessible for use elsewhere (e.g., in a Client Script).

Line-by-Line Explanation:

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

   • This is a self-executing anonymous function, which is the standard structure for a ServiceNow Business Rule.
   • current: This variable represents the current record being acted upon (e.g., the Incident record that triggered the rule). It's a GlideRecord object.
   • previous: This variable represents the record before the update. It's null when the rule runs on insert (creation of a new record). It's a GlideRecord object.

2. var gr = new GlideRecord("problem");

   • This line creates a new GlideRecord object named gr, specifically for the "problem" table. GlideRecord is the ServiceNow class used to interact with database tables.

3. if (gr.get(current.parent)) {

   • This is the core logic. It checks if the current record (current) has a parent field populated. It assumes that the current record has a field named "parent" that references a record in the "problem" table.
   • current.parent: Gets the sys_id of the parent record (presumably a Problem record).
   • gr.get(current.parent): This attempts to retrieve the Problem record from the database whose sys_id matches current.parent. The gr.get() method returns true if the record is found and false otherwise.

4. g_scratchpad.parent=current.parent;

   • If the gr.get() was successful (meaning a parent Problem record was found), these lines copy fields from the Problem record (gr) to the g_scratchpad object. g_scratchpad is a special object in ServiceNow that allows you to pass data from the server-side (Business Rule) to the client-side (Client Script).
   • g_scratchpad.parent=current.parent;: Stores the parent sys_id to scratchpad.
   • g_scratchpad.short_description=gr.short_description;: Copies the "short_description" field from the Problem record to the g_scratchpad.
   • g_scratchpad.assigned_to=gr.assigned_to;: Copies the "assigned_to" field from the Problem record to the g_scratchpad.
   • g_scratchpad.assignment_group=gr.assignment_group;: Copies the "assignment_group" field from the Problem record to the g_scratchpad.

5. }

   • Closes the if statement.

6. })(current, previous);

   • Closes the anonymous function and immediately executes it, passing in the current and previous GlideRecord objects.

In Summary:

The Business Rule checks if the current record has a parent Problem record. If it does, it retrieves the Problem record and copies the short_description, assigned_to, and assignment_group fields from the Problem record into the g_scratchpad. This makes those fields available to Client Scripts running on the same form, allowing you to display or use the Problem's information on the Incident/Change/Task form.

Important Considerations:

• Timing: This Business Rule should likely run "before insert or update" to ensure the g_scratchpad is populated before the form is displayed to the user.
• Table: The Business Rule needs to be associated with the table that has the "parent" field (e.g., Incident, Change Request, etc.).
• Client Script: You would need a corresponding Client Script to read the values from the g_scratchpad and do something with them (e.g., display them on the form, set other field values, etc.). The Client Script would access the values like this: g_scratchpad.short_description.
• Error Handling: The code lacks error handling. If current.parent is invalid (doesn't exist), the gr.get() method will fail silently. You might want to add a check to ensure the Problem record exists before attempting to copy the fields.

I hope this comprehensive explanation is helpful! Let me know if you have any further questions.

Get smarter answer from GPT-4o

[Jorn van Beek]

@pak-gerner_ 

Thank you for proving the AI feedback is just lousy at best. You only prove you need to have an even better understanding of ServiceNow when using AI. You need to understand when the AI is you something good and when it is just telling you nonsense.

The line by line code review is nice, but if you need help reading those lines than maybe this is not the job for you. Beter would be if it suggest improvements.

the things to consider are the true joke in this case.

Timing: really... saying those business rules run on insert/update... Just the idea is rediculus. These business rules run on (or rather before) display. It is information that is send from Server to Client together with the rest of the form. An insert/update is when the form is sent back to the Server.

The timing is something for consideration though. Do you want this information to always be retreived or not? do you need it BEFORE you show the form to the user or can you retreive it async after loading the form for example though an AJAX call. 

Table: yes there is a table... what is the point? maybe the point is you need to decide if you want to run it on problem task only or maybe more generic as task with extended impact that will have...

You need a clients script? yes... isnt that exactly what the first post said? added value 0.

Error handling... What do you think the if statement in 'if (gr.get(current.parent)) {' is doing? Yes, exactly Error handling.

Way better feedback would have been that it is not good practice to use 'gr' as variable name.

Or provide an alternative solution because to be honest (and totally not sarcastic... this time atleast...) I think for the provided use case there are beter solutions. Now and 4,5 years ago. Lucky often you dont need the best solution, just a working one. (ok that last part was sarcastic again)