Hi Siva, This is very common interview question where interviewer asks difference between latest ServiceNow version (Utah as of today ) and old version. As Rome is latest version as compare to Quebec in your question so instead of finding out differences, you should know new features we have got in Rome release. New features in Rome release will indirectly gives you difference between Quebec and Rome. Below is the official documentation which describes New features and products in Rome release : https://docs.servicenow.com/bundle/rome-release-notes/page/release-notes/summary/rn-summary-new-features.html Below video also explains new features in Rome : Video Link : https://www.youtube.com/watch?v=zWMikrL9bck

---

0 Helpfuls

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

Hi Jyoti, Excellent question to test candidates knowledge. If you need to move/publish an app from the development instance to another instance( as if it is fully developed and ready to install on a TEST instance/PROD instance), you should do it via "Publish an application to the application repository". In this case, the app will be available to be installed on all instances except the DEV instance. Mode details here : https://support.servicenow.com/kb?id=kb_article_view

---

1 Helpfuls

Publish an application to the application repository : https://www.servicenow.com/docs/bundle/yokohama-application-development/page/build/applications/task/t_PublishAppsToTheAppRepository.html

---

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

Workflow.

---

0 Helpfuls

By using Record Producer, it allows you to create table based records e.g. Incident, Problem etc. With this you basically involve ITSM tables/processes with Service Catalog.

---

0 Helpfuls

Integrate ServiceNow's Service Catalog by connecting its request fulfillment with core ITSM processes like Incident, Problem, Change, Asset (CMDB), and Knowledge Management, using automated workflows (Flow Designer/IntegrationHub) for seamless data flow, approvals, and task creation, ensuring requests trigger correct actions (e.g. fulfillment tasks, change requests, asset updates) for a unified user experience.

---

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.

---

0 Helpfuls