Posts Tagged ‘Business rules’
Posted by Mark Stanger in UI actions Tuesday, 31 August 2010 05:45 2 Comments
M
ost Service-now administrators and consultants know how to configure and use UI Actions. UI Actions are UI elements that can show up on a form or a list as a button, link, or context menu. When these UI elements are clicked they execute some JavaScript. Most of the time UI Actions are used to perform some server-side update to a record or records. In other cases, you can use the ‘Client’ checkbox on the UI Action record to execute some client-side JavaScript (including checking for mandatory fields).
But what if you need to do both? The classic case is when you want to click a button to make an update to a record, but only if the user has provided the correct input first. An example would be a ‘Reopen Incident’ button that changes the state on an incident record from ‘Resolved’ to ‘Active’. Usually you want to require the user to provide some sort of comment or additional information explaining why they are reopening the ticket. The problem is that you don’t always want the ‘Comments’ field to be mandatory so the validation needs to happen at the time the ‘Reopen Incident’ button gets clicked. Validation of mandatory fields needs to happen client-side but the update to your record needs to happen server-side. How can you accomplish both of these things with a single UI Action? This article shows you how.
Posted by Mark Stanger in Client scripts Thursday, 17 June 2010 13:38 No Comments
T
oday I came across a scripting issue that I actually see quite often. I can’t ever remember it when I need it so I’m going to document it here. The issue is this: when working in a client script or business rule, I need to only have the script run if the record is a valid record. For me, this issue really only comes into play when working with client scripting or UI policies. For example, I only want a script to run if the record hasn’t been submitted yet. The following scripts show how you can test if a record is a new record or not in your scripts.
Posted by Mark Stanger in Scripting Wednesday, 3 March 2010 06:26 No Comments
S
ys_id values uniquely identify each record in your Service-now instance database. While you should never try to modify these values, it is sometimes useful to know what the sys_id value is for a particular record. This article describes the different ways of identifying the sys_id value for a particular record.
Posted by Mark Stanger in Scripting Tuesday, 23 February 2010 06:37 3 Comments
I
doubt if there’s a single concept in Service-now that is more valuable to understand than how to use GlideRecord methods to query, insert, update, and delete records in your system. These methods have a wide variety of uses and are found at the heart of many of the business rules, UI actions, and scheduled job scripts that are essential to tie together your organization’s processes in your Service-now instance.
While the content of this post isn’t new information (additional examples can be found on the Service-now wiki), my aim is to provide a single page of information containing some common examples of these methods as a reference. This is an excellent page to keep bookmarked!
Posted by Mark Stanger in Scripting Thursday, 11 February 2010 16:10 No Comments
A
n important part of managing the flow of any record submission is to be able to validate the information from the form or record and provide feedback to the end-user if there is something that they need to change. While there are many ways to validate different kinds of data, preventing the submission of that data is pretty straight-forward. In Service-now, there are two different ways to stop the submission of a record. One method works client-side (in the rendered html form) and the other method works in server-side javascript as the record hits the database.
Recent Comments