Things Every ServiceNow Developer Must Know : Part 2
1) Inherited field (checkbox) in a Client Script configuration :
determines whether the script runs on the specified table and all of its descendant tables that extend it.
When checked: The client script written on a parent table (e.g., the Task table) automatically applies to all child tables that extend it (e.g., Incident, Problem, Change). This promotes code reuse and consistency across related forms.
When unchecked: The client script only runs on the specific table selected in the Table field and not on any tables that extend it.
2)If you want to export your record data in XML without admin role : you just have to add &XML in record url
3)If you have to give read only access for all tables/modules :
In ServiceNow, there is a built-in role called snc_readonly that is used to restrict a user’s access to read-only mode. This role does not provide any access by itself; instead, it works by limiting the permissions of other roles assigned to the user. For example, if a user has the admin role, they normally have full create, update, and delete access. However, when the snc_readonly role is added along with admin, the user will still be able to view records but will not be allowed to modify them. This means the user must first be given a role that grants access, and only then can snc_readonly be used to restrict that access. This approach is commonly used to provide temporary or audit-only access while maintaining proper governance and control.
Reffer this : Read only access
4)setForceUpdate(true) & autoSysFields(false) :
In ServiceNow, setForceUpdate() is a GlideRecord method used to force an update on a record even when no field values have changed. Normally, ServiceNow updates a record only if at least one field value is modified. However, when setForceUpdate(true) is used, the system treats the record as changed and executes the update operation. This is especially useful when you want to trigger Business Rules, workflows, flows, audits, or system logic that depend on the update action, even though the data remains the same.
autoSysFields(false)
This method stops ServiceNow from automatically updating system fields such as Updated by, Updated on, Created by, and Created on. It is useful during data migration or backdated updates.Disables the update to the system fields sys_updated_by, sys_updated_on, sys_mod_count, sys_created_by, and sys_created_on.
5)Conditional script writer group :
From the Zurich release, ServiceNow introduced the Scripting Governance tool to control who can edit scripts and scriptable fields. Even users with the admin role cannot modify scripts unless they are part of the Conditional Script Writer group or have the snc_required_script_writer_permission role. This tool monitors all fields that can contain executable code, including Business Rules, Client Scripts, Script Includes, and HTML fields. Automatic assignment to the group is managed through a system property, ensuring secure and controlled scripting access.
You can also explore : Things every servicenow developer must know :part 1
