SERVICENOW BEST PRACTICE - detailed post
- Scripts should not directly call Java packages
- enable privacy on client callable script includes
- Read ACLs should not contain GlideRecord
- protect a system property if you do not wish for a system property on production to be overwritten via an update set - for example, if it contains environment-level settings - consider setting private=true
- table transform maps generally do not need "Run business rules" enabled
- JDBC Data Sources should have the "Use last run datetime" option checked
- Standardisation of form labels the general principle is upper case letter followed by lower case letters for the first word, and next word(s) start with lower case examples
- read only fields fields such as number, parent fields should be made read only via UI policy so these can't be overwritten
- CA Validation: Mutual authentication establishes trust by exchanging secure sockets layer (SSL) certificates
- check run as user on scheduled jobs
- Use of javascript alert /prompt/confirm in client scripting
- these should be avoided where possible in favor of ServiceNow native dialog boxes which are more pleasing to the eye for service portal, use spModal for classic UI, use glideModal for combined portal/classic scripts (as in service catalog client scripts, for example), see Appendix C below
- consider if a new table is required, or a new field, as there may be better ways of implementing the solution for Data Lookup tables
- Check the ServiceNow roadmap to see whether the feature will be delivered out of the box in the near future – perhaps contact your Account Manager
- consider if the solution has already been built by someone else on the servicenow store or share:
See my custom widget & page suggestion
http://www.cloudminus89.com/2020/07/sys-admin-useful-service-portal-widget.html?q=duplicate
Loading a large table with results set to zero, to then apply the filter this is useful when querying large tables, particularly on production
in the below example we wish to load the incident table which on production which contains large number of records on production, using the ?sysparm_filter_only=true parameter in the url https://.service-now.com/incident_list.do?sysparm_filter_only=true
then apply the filter you desire and run the query
SNUtils might perhaps have an equivalent option also
check this table: sys_email_log
- Use the script referenced here (don’t really need to do this if you have the SNUtils browser extension installed)
In a scoped app it can be easier:
always clone over the sub-prod instance prior to upgrading so that testing is valid
where you choose to skip updates and retain local object updates, consider documenting these somewhere. This will enable you to check why you retained a local object rather than having to do the analysis each time
any plugins / new features not enabled as part of the upgrade should be documented for future analysis so that the tool does not get too far behind in time
The update set could contain the story number (perhaps ServiceNow or Jira reference), plus defect number in the case of a UAT defect, and update sequence (01, 02, etc) which indicates the order of deployment
The update set name could contain a very concise description and suffix could be the developer/admins initials, e.g. _RDS
You could build a form to help enforce the naming standards!
Haven't tested these all recently within global/local scopes, so feel free to have a play! option 1 use an encoded query embedded in the GlideRecord , e.g. var grProf = new GlideRecord ( 'x_cls_clear_skye_i_profile' ); grProf . addQuery ( 'status=1^ owner=NULL ' ); grProf . query (); even better use the glideRecord addNotNullQuery or addNullQuery option 2 JSUtil.nil / notNil (this might be the most powerful. See this link ) example: if ( current . operation () == 'insert' && JSUtil . notNil ( current . parent ) && ! current . work_effort . nil ()) option 3 there might be times when you need to get inside the GlideRecord and perform the check there, for example if the code goes down 2 optional routes depending on null / not null can use gs.nil : var grAppr = new GlideRecord ( 'sysapproval_approver' ); var grUser = new GlideRecord ( 'sys_user' ); if ( grUser . get ( 'sys_id' , current . approver )){
Classic UI : var sURL_editparam = gs . action . getGlideURI (). getMap (). get ( ' sysparm_aparameter ' ); if ( sURL_editparam == 'true' ) { gs . addInfoMessage ( 'parameter passed ); } Portal : var sURL_editparam = $sp . getParameter ( " sysparm_aparameter " ); if ( sURL_editparam == 'true' ) { gs . addInfoMessage ( 'parameter passed ); }
Call a script include to apply a reference qualifier on a catalog item variable: - variable reference qualifier dependent on another variable selection, in this case a variable referencing sys_user (requested_for) On the catalog item form. variable name to apply ref qual filter : retail_equipment variable reference qualifier (on cmdb table ): javascript : new refqual_functions (). lostStolen_getAssignedCIs (); client-callable script include ( refqual_functions) function : lostStolen_getAssignedCIs : function (){ //--called from variable set client script, for lost/stolen request (service catalog) gs . log ( current . variables . requested_for , 'retail_lostStolen_getAssignedCIs' ); return ( 'install_statusNOT IN8,7owned_by=' + current . variables . requested_for ); //owned_by=1269b79937f1060041c5616043990e41install_statusNOT IN8,7 },
http://www.cloudminus89.com/2023/02/servicenow-best-practice-detailed-post.html