Service-now provides the ability to automatically move incidents marked as ‘Resolved’ into a ‘Closed’ state after a certain number of days. In my experience I’ve found that this type of resolution/closure workflow is really the best way to configure your incident management setup because it allows end-users the ability to reopen incidents within a certain window [...]
Working in Service-now, you’ll find that a lot of scripting tasks come down to identifying which fields changed on a form (client-side) or record (server-side). In this post, I’ll show you some different techniques to identify changed fields in both client-side, and server-side scripts. I’ll also show you a way that you can capture changed fields [...]
While this customization may still be necessary in certain situations, ServiceNow handles this issue in Aspen builds or later without any customization. I’ve written before on SNCGuru about how ‘before query’ business rules can (and should) be used to secure row-level read access to records in Service-now. While this usually works perfectly, there is one issue [...]
Change management in Service-now includes the use of a parent ‘Change request’ ticket and (usually) the use of multiple ‘Change task’ tickets that can be assigned to separate groups or individuals to perform specific pieces of work. Because these change task tickets should factor into the overall plan for the parent change request, it often makes [...]
As of the ServiceNow Calgary release, this functionality is no longer necessary and, in fact, can cause some issues due to an unresolved bug in ServiceNow code. The best-practice method for making variables read only on standard forms post-Calgary is to use catalog UI policies and catalog client scripts along with the ‘Applies to’ checkboxes available [...]
