To allow tables to inherit a client script, the inherit checkbox must be set.

---

0 Helpfuls

There is no Inherit checkbox directly in the Service Catalog for catalog items

---

0 Helpfuls

gs.eventQueue('event name',current,parm1,parm2);

---

2 Helpfuls

Sure, I can explain a UI policy I've created and discuss why UI policy was chosen over other methods like Client script or ACL. Example UI Policy: Making a Field Read-Only Based on User Role Requirement: In a ServiceNow application, users with the role 'IT Support' should not be able to edit the 'Assigned To' field on an incident record once it has been assigned. Implementation using UI Policy: UI Policy Definition: Create a UI policy named "Read-only Assigned To for IT Support". Condition: When the user has the 'IT Support' role AND the incident state is not 'New'. Action: Set the 'Read-only' property of the 'Assigned To' field to true. Why Use UI Policy: Simplicity: UI policies are easy to configure through the ServiceNow UI without needing scripting knowledge. User-Friendly: Changes made by UI policies are immediate and visible to users as they interact with forms. Performance: UI policies execute on the client side, reducing server load compared to ACLs which execute server-side. Why Not Client Script or ACL in This Case: Client Script: While client scripts could achieve the same functionality by setting field properties, UI policies are simpler for this straightforward requirement. ACL (Access Control List): ACLs are generally used for security and data access rules rather than field-level behaviors like making fields read-only based on conditions. Alternative Approach: Client Script: If additional logic were needed beyond field properties (e.g., showing a message or performing calculations), a client script might be more appropriate. ACL: If the requirement involved restricting access to certain records based on roles, ACLs would be essential. However, for making fields read-only conditionally, UI policies are often the best fit due to their simplicity and direct applicability. In conclusion, UI policies were chosen in this scenario for their simplicity and direct capability to make fields read-only based on user role and record state conditions. While client scripts and ACLs have their uses, UI policies provided the most straightforward solution for this particular field behavior requirement in ServiceNow.

---

1 Helpfuls

By using rulebase we can add the catalog items to a order guide.

---

0 Helpfuls

var grP1 = new GlideRecord('incident'); grP1.addQuery('priority',1); grP1.query(); while(grP1.next()){ gs.print(grP1.number); }

---

0 Helpfuls

Select row header 50.

---

0 Helpfuls

(function runTransformScript(source, map, log, target /*undefined onStart*/ ) { // Add your code here var num = parseInt(source.u_sr_no); if(num <= 50){ ignore = true; return; } })(source, map, log, target);

---

0 Helpfuls

It will show all the users.

---

0 Helpfuls

It will show all the ITIL users as per the default Use reference qualifier.

---

0 Helpfuls

Add assignment_group(backend name of group field) in the dependent value of assigned_to field

---

0 Helpfuls

Create onBefore transform script and add this (function runTransformScript(source, map, log, target /*undefined onStart*/ ) { // Add your code here if(source.sys_import_row >= 100 ){ error = true; } })(source, map, log, target);

---

1 Helpfuls