SNOW

 var watchListArray = []; var oldWatchList = previous.u_watchlist.split(','); var newWatchList = current.u_watchlist.split(','); for (var i = 0; i < oldWatchList.length; i++) {   if (newWatchList.join(',').indexOf(oldWatchList[i]<0)){     watchListArray.push(oldWatchList[i].toString());   } }   gs.eventQueue("event_name",current, watchListArray.toString()); }

Inbound means that other applications make calls to ServiceNow's REST API to get information from SN ,   basically when some other tool hits your instance(wsdl) with a payload and you process it and acknowledge it. EG, if an incident gets created in a third party tool then an incident gets created in a service now . Here we accept the request and process it. - Direct Web Services - Web Service Import Sets -Direct Web Service API : Servicenow by default creates a webservice api for every table in the system, if you create a custom table system will provide SOAP and REST api to perform CURD operations. - Web Service Import Sets Staging web-service/Web Service Import Sets: this staging allow third party to send data to import table and then we do transform map by qualifying the data to send into the Servicenow.

BEFORE : Use before insert/update business rule to do some validation and if validation fails stop form submission Use before insert/update business rule to set values for current record based on some other fields on the form such as calculated field AFTER : Use after insert/update business rule to insert/update data in related list table Use to update information on related objects that need to be displayed immediately, such as GlideRecord queries. ASYNC: Use to update information on related objects that do not need to be displayed immediately, such as calculating metrics and SLAs. Mostly used to call 3rd party SOAP or REST endpoints DISPLAY : Mostly used to send field value from server side to client side; for the fields which are not available on the form, this value can be used in onload, onchange, onsubmit client scripts

1) incident.None --> if user satisfies this ACL, then he will have access to the table and all the fields provide there are no field level acls like incident.* or incident.<field_name> 2) incident.None & incident.caller --> User should satisfy both the ACLs in order to have access to caller field, but rest of the fields can be accessed if user satisfies incident.None acl. 3) incident.None & incident.*-->User should satisfy both the ACLs in order to have access to all the fields 4) incident.*--> this is a field level acl. So user still needs to satisfy the table level acl incident.none in order to access the table and fields. 5) incident.* & incident.caller --> User still needs to satisfy incident.none acl and incident.* acls to access all the fields except caller. For caller user needs to satisfy both the incident.none and incident.caller acl. 6) incident.None & incident.* and incident.caller --> User still needs to satisfy inciden...

1. Configure OAuth provider on instance 1 (OAuth Application Registry -> Create an OAuth API endpoint for external clients) Create unique provider profile name. We need to generate client ID along with Client Secret. Both can be generated by system normally. Token lifespan are optional, generated by default system policy. 2. Configure OAuth consumer on instance 2 (OAuth Application Registry -> Connect to a third party OAuth Provider) Create unique consumer profile name. (very important, script will need pass in this consumer profile name as parameter) Client ID and Client secret are the values were generated from step 1. Grant type. Value can be either "password" or "refresh_token". Suggest to use password since you won't have refresh_token info initially. This refresh_token only will be generated during first time when access token is generated. Token URL will be provided by OAuth provider. In this example, it would be the  https://oauth_...

BACKGROUND SCRIPT CODE VAULT RECORD QUERIES ACTIVE REQUESTS WITHOUT REQUESTED ITEMS (function() { var grRequest = new GlideRecord("sc_request"); grRequest.addEncodedQuery("active=true"); grRequest.query(); gs.print('Active Requests without Requested Items :('); while (grRequest.next()) { var gaRequestedItem = new GlideAggregate("sc_req_item"); gaRequestedItem.addQuery("request",grRequest.sys_id); gaRequestedItem.addAggregate('COUNT'); gaRequestedItem.query(); var req = 0; if (gaRequestedItem.next()) { req = gaRequestedItem.getAggregate('COUNT'); if (req == 0) { gs.print(grRequest.number); } } } })(); DISTINCT OPERATING SYSTEMS OF CIS (function() { var gaServer = new GlideAggregate('cmdb_ci_server'); //GlideAggregate query gaServer.addAggregate('count'); //Count aggregate (only necessary for a count of items of each OS) gaServer.orderByAggregate('count'); //Count aggregate ordering gaServe...

Clean Architecture with ServiceNow Introduction The following set of rules is aimed to provide a maintainable, extendable and understandable architecture for any solution within service now. They are kept as short as possible to allow for a one page document. Please share your thoughts and feedback, as well as your critique. 1 Script Includes are for Data Manipulation Don’t save. Don’t update. Don’t insert. Don’t delete. In fact: Script Includes don’t. They provide. 2 Business Rules are for Data Transformation Do save. Do update. Do insert. Do delete. In fact: Business Rules do, but won’t think. Therefore, make Script Includes the brain of Business Rules. 3 Client scripts are for displaying data What do they display? Data! Where do they get it from? Queries! Do they think? No! Do they do? No! But what are they there for? To display data. That’s it. 4 Workflows are a succession of Business Rules Follow the same principles! They do, but won’t think. Make Sc...