1 Indeed, this is common question in an interview. I have been asked this question many times. To find out answer, there are many YouTube videos gets released which explains new features in details.

---

0 Helpfuls

to achieve this we can write two BR 1-sc_task 2- on table sc_req_item condition-state changes to closed complete logic 1- var rtm = new GlideRecord('sc_req_item'); rtm.addQuery('sys_id', current.request_item);//request_item is a field of sc_task rtm.query(); while (rtm.next()) { rtm.state = '3'; rtm.update(); } logic2-var req = new GlideRecord('sc_request'); req.addQuery('sys_id',current.request); req.query(); if(req.next()){ req.request_state = 'closed_complete'; req.update();

---

0 Helpfuls

Hi Sahitya, As such there is no difference technically. However, Catalog client scripts are written for catalog items or variables sets and Client Scripts are written for backend tables e.g. incident, problem etc.

---

0 Helpfuls

As Such there is no difference technically. Client script have 4 types Onload OnChange OnSubmit Oncelledit Catalog client script have 3 types Onload Onchange Onsubmit

---

0 Helpfuls

Catalog client scripts stored in catalog_script_client table and Client scripts stored in sys_script_client table. In catalog client script we have the option to apply the client script to the catalog item view, RITM view , Task view and also Target record view But in Client script we does not have that options. In Client script we can apply the script to a specific view by checking the Global checkbox But in catalog Client script there is no Global check box because Catalog client script applies on a specific catalog item or a variable set

---

3 Helpfuls

in catalog client script their is no cell edit type client script we have only 3 types i.e onload, on submitte, on change that is major diffrence in that

---

1 Helpfuls

Hi Sahitya, Primary difference is that batch update sets enable you to group update sets together so you can preview and commit them in bulk on the other hand normal update set is single entity which can be committed separately. Dealing with multiple update sets can lead to problems, including committing update sets in the wrong order or inadvertently leaving out one or more sets. Therefore, SN has introduced concept of batch update sets ( but many people now use merge update set functionality, both methods have its pros and cons) The system organizes update set batches into a hierarchy. One update set can act as the parent for multiple child update sets. A given set can be both a child and parent, enabling multiple-level hierarchies. One update set at the top level of the hierarchy acts as the base update set.

---

1 Helpfuls

Hello Kanika, This can be implemented easily via workflow where you can inlcude validation script to check if dedicated user exist in that group, if not, then send it to managers manger. Workflow allows us to write such quite complex logic while triggering approval. However, I am pretty sure it can be achieved via Flow Designer as well but it becomes quite difficult to implement such logic in flow designer. I would not recommend to BR for triggering approvals as it becomes difficult to track approval status to perform further operation.

---

0 Helpfuls

Cleanup scripts automatically run on the target instance after the cloning process finishes. Use cleanup scripts to modify or remove bad data. Cleanup scripts run after data preservers and the clone are complete.

---

0 Helpfuls

They get read/write access to whole table without any restrictions. Therefore it is possibility that if they make any mistake, it could create chaos in whole table. Alternatively we should think of having scripted rest api where SN developer will have more control on what operation other toll can perform. e.g. if other system is only going to change assignment group, adding a comment on incident then instead of providing table api access, you can write scripted rest api.

---

1 Helpfuls

If Retroactive pause is checked, any new SLA gets associated to the ticket also considers the pause time. For example, I have 2 SLAs for 2 different group. Both have Retroactive Start is set as ticket creation date. When ticket is created and assigned to first group, SLA1 got associated to the ticket. The ticket was put on hold for 1 hour and then assigned to 2nd Group, which linked the SLA2 to the ticket. Since the SLA2 has Rectroactive Start is set as ticket creation date, it will consider the SLA start time as ticket creation date. Now if the Retroactive Pause is also set for SLA2, it will also consider the 1 hour of pause time, which will extend the SLA breach date by 1 hour.

---

0 Helpfuls

Hi Niru, With this function, we can write client as well as Server side script in same UI action. More details here : https://servicenowguru.com/system-ui/ui-actions-system-ui/client-server-code-ui-action

---

0 Helpfuls

In the context of ServiceNow's gsftSubmit() function, using null for the first parameter typically indicates that the notification or confirmation message generated by the UI Action should appear in the global notification container at the top of the page, rather than being attached to a specific HTML element on the form. It's a common and recommended practice for most scenarios, providing a general notification area for the user. Understanding gsftSubmit() gsftSubmit() is used in UI Actions that have both client-side and server-side scripts. It allows you to execute the client-side script first for validation or other client-side logic, and then trigger the server-side code of the same UI Action. The gsftSubmit() Syntax The typical syntax is: gsftSubmit(null, g_form.getFormElement(), "action_name").

---

0 Helpfuls

Integration between one serviceNow instance to another Servicenow instance

---

0 Helpfuls

In addition to Priya's answer, OOTB E-bonding spokes (flow actions ) are available with which we can connect to other instances.

---

0 Helpfuls

E- bonding, it means company A and company B are integrated and received an acknowledgment for the same with unique ticket number. Now Company A and Company B can practically transmit the updates and other transactions. Outbound > Company A -----New Submit Request --- > Integration-------> Company B Inbound Company A <-Acknowledgment with Company B Ticket Number--

0 Helpfuls