Category: UI actions
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 UI actions Tuesday, 27 July 2010 10:42 No Comments
A
few months ago I wrote about copying change requests using a UI action. While that method works great, it does require you to specify each and every field and value that you want to populate into the new change request. If you’ve got a lot of fields to copy over then you might end up with a pretty big script and a lot of items to copy over. You also need to be aware of any new fields that get added after you create the script and make sure that they get copied if necessary.
The following method works in much the same way, but it copies by performing an insert against the current record (rather than starting from a brand new change record and supplying each value). Because of this, you’re concerned about overriding any of the values (such as start and end dates) that you don’t want to be copied over from the record you are copying. This method works better if you know you want to copy over all (or the majority) of the field values from a given change.
Posted by Mark Stanger in Scripting, UI actions Wednesday, 19 May 2010 07:41 1 Comment
T
his script was designed specifically for easily creating a copy of a variable set but it could be easily adapted to create a copy of any other record (and associated records) in Service-now. Rather than use a field-by-field copy technique, this script works more like an ‘insert’ on the records it touches. Because of this, you get an exact copy without having to specify each and every field to copy. If you don’t want an exact copy of a particular field, you can overwrite it in the script. You can implement this copy functionality to copy a variable set by creating a UI action with the following settings…
Posted by Mark Stanger in Business rules, Graphical workflow, UI actions Monday, 28 December 2009 07:41 1 Comment
W
hen implementing the Change management process in Service-now you’ll probably encounter a scenario where your entire change workflow (including all tasks and approvals) needs to be reset. The first option to consider (assuming you’re using the graphical workflow engine to manage the tasks and approvals) is the Rollback workflow activity. The rollback activity works great for a lot of scenarios, but what if you don’t have a defined point in the workflow where everything should be rolled back? What if the rollback (or reset) can happen at any point in time? There’s not really an easy way to handle this within the workflow itself since you would need to check for a rollback condition at an infinite number of places.
Recent Comments