This module appears under the ‘System Policy application’ menu. It helps to automatically assign the tasks to a particular user or a particular group using the assigned_to and assignment_group fields respectively, depending on the specified set of conditions. One can define these assignment rules readily for their desired table.

---

0 Helpfuls

Any examples?

---

0 Helpfuls

let's say we select category as 'Hardware' and subcategory as 'Mobile' based on these selections we can make 'assignment group' and 'assigned to' fields automatically display.

---

0 Helpfuls

Assignment Rules: In HRSD, i have used this I gave condition like if hr service is benefits inquiry and assigned to empty then you can assign to particular group.

---

0 Helpfuls

Assignment rules in ServiceNow automatically set values in the assigned_to and assignment_group fields when certain conditions are met .Go to system policy->Assignment data look rules->create new record based on your requirement.

---

0 Helpfuls

Sometimes, interviewer expects deeper understanding from candidates if candidate is having more experience. May be you could have explained how these things work in backend at DOM level. e.g. We have equivalent concept in CSS, if we use visibility:hidden in CSS to hide fields, it causes their space to be retained. But, on the other hand, if we use display:none, it causes space to be removed. So, I believe this is what ServiceNow uses in backend. This answer could have impressed interviewer.

---

2 Helpfuls

I never knew this, it's really impressive answer. Thank you.

---

0 Helpfuls

This is very important and common interview question. Below is the use of weight field in notification. - With the same target table and recipients, the system only sends the notification with the highest weight. - The default value weight 0 causes the system to always send the notification (assuming the conditions are met) This article explains weight concept very well : https://www.servicenow.com/community/uk-united-kingdom/notifications-email-notification-weight-examples/ba-p/2271497 Hope this helps.

---

0 Helpfuls

I think answer depends on given scenario. However, below are the short and simple use cases for different BR. Before BR : Use this BR when you want to update anything on current record. If you use After or Asycnh BR for such scenario then you will have to use current.update() which is not considered as best practice. Asynch BR : When you want to perform any operation which takes long time to execute. This way, user don't have to wait for this BR to complete as it runs in backend asynchronously. After BR : When you want to perform any operation on other than current record, it could be record in other table or same table but other than current record. Hope this helps.

---

0 Helpfuls

Before Business Rule: A Before BR runs before the record is saved to the database. It’s best for scenarios where I want to validate or modify data on the current record. However, it’s not ideal when I need to create related records or trigger flows, because the current record’s sys_id isn’t guaranteed to exist yet. Relying on it too early could cause data integrity issues or trigger failures. Async Business Rule: An Async BR executes after the record is committed, but runs in the background. It is faster in terms of not blocking the main transaction, so it’s useful for non-critical operations like logging, notifications, or calling external systems. But for flows and catalog requests that require sequential execution or guaranteed timing, async rules can introduce risks, since they have no guaranteed execution time or order. It may delay or fail silently, which is unacceptable for time-sensitive tasks. After Business Rule: An After BR runs immediately after the record is saved and within the same transaction. This makes it ideal for creating dependent records, updating related tables, or triggering flows that rely on data that is now committed, including the sys_id. It ensures that everything runs in a reliable sequence and within a guaranteed time frame. In catalog requests or flow orchestration, this level of control is critical, so After BR becomes the best fit.

---

1 Helpfuls

Hi Kishan, We can write script in approval activity as below to identify if 50% approvals are approved or 50% are rejected based on result take action. Approval activity script : //Approve based on percentage indicated var approvePercent = 50; if((counts.approved/counts.total)*100 >= approvePercent){ answer = 'approved'; } if((counts.rejected/counts.total)*100 > (100 - approvePercent)){ answer = 'rejected'; } Our ServiceNow Guru explained this very well here : https://servicenowguru.com/graphical-workflow/approval-percentage/

---

0 Helpfuls

System has internal detectors for this and will prevent an endless series of such Business Rule executions, the detection of this has been known to cause performance issues in that instance. Source : https://support.servicenow.com/kb?id=kb_article_view

---

0 Helpfuls

Do you mean to convert Data Policy to UI policy? If so, then yes, we can convert Data policy to UI policy. There is related link on Data Policy named as "Convert this to UI Policy" which will converts Data Policy into UI Policy.

---

0 Helpfuls

There is small trick in this scenario. Many developer don't know that we can dot walk caller name in encoded query itself (2nd line in below script). Instead developers glide into all incidents and then they add if condition to check if caller name startswith s, which is valid solution but not efficient one. Script :var grIncident=new GlideRecord("incident"); grIncident.addEncodedQuery("caller_id.nameSTARTSWITHs"); //Here dot walk is very important, very useful in many scenarios grIncident.query(); while(grIncident.next()){ grIncident.setValue("active",false); grIncident.update(); }

---

1 Helpfuls

Thanks Kushal. I never knew dot walk work this way as well.

---

1 Helpfuls

Hey Kushal, Your script works but it is not efficient. In this case we can rather use updateMultiple method as we are going to update same value for all filtered records ( that is making it false ). Interviewer normally expects efficient script from candidates. We can use below script : var grIncident=new GlideRecord("incident"); grIncident.addEncodedQuery("caller_id.nameSTARTSWITHs"); grIncident.query(); grIncident.setValue("active",false); grIncident.updateMultiple();

---

1 Helpfuls

As I have read , Incident's Active is set to false when Incident state is Closed or Cancelled.

---

1 Helpfuls

var gr = new GlideRecord('incident'); gr.addEncodedQuery('caller_idSTARTSWITHs^ORcaller_idSTARTSWITHWITHS'); gr.query(); while(gr.next()){ gr.setValue('active',false); gr.update(); }

---

0 Helpfuls

you need to change state of new cases to canceled/closed/resolve than only you can set Active false. var gr = new GlideRecord('incident'); gr.addEncodedQuery('caller_idSTARTSWITHs^active=true'); gr.query(); while(gr.next()){ gr.state=8; gr.active=false; gr.update(); }

---

0 Helpfuls

Hi SatyaPriya, The primary use of initialize function in script include is to set default values to variables which can later be used anywhere in script include. We don't need this in client callable script include as the data which we need is normally sent via client script while using GlideAjax. Note :ServiceNow automatically removes initialize function whenever we check client callable checkbox in script include.

---

0 Helpfuls

When a Client Callable Script Include is created the prototype extends from the "AbstractAjaxProcessor" Class and "initialize: function() {}" will not be added since it is already in the AbstractAjaxProcessor.prototype. If we add "initialize: function() {}" into the Client Callable Script Include manually, the GlideAjax call won't work since it overrides the initialize function in the AbstractAjaxProcessor.prototype and request, responseXML, gc objects used in the Ajax call are not available

---

1 Helpfuls

For a UI policy to be eligible for conversion to a data policy, the following conditions must be met on the UI Policy form. - The Run scripts check box must be cleared. - The Global check box must be selected. - None of the UI policy actions can have Visible set to True or set to False. Visible must be set to Leave Alone. Source : https://docs.servicenow.com/en-US/bundle/utah-platform-administration/page/administer/form-administration/task/t_ConvertAUIPolicyToADataPolicy.html

---

0 Helpfuls