![]() In an ‘onSubmit’ scenario, you have to check for these changes yourself. There are some special situations (typically on submission of a record) where you don’t have a special event that tells you something changed. If at all possible, you should stick to ‘onChange’ client scripts or UI policies. When you write on ‘onChange’ client script or a UI policy, you can tie into the events and take actions as a result. ![]() Behind the UI, the system is taking cues as well and firing off ‘onChange’ events and setting field parameters as a result. ![]() The green field indicators give a simple visual cue to the user. When looking at a form in Service-now, it’s usually pretty easy to identify the fields that have changed since the form loaded (as seen in the screen shot above). Identifying modified or changed fields in Client scripts I’ll also show you a way that you can capture changed fields and values and print them in an email notification…without having to check every potential field in a record. In this post, I’ll show you some different techniques to identify changed fields in both client-side, and server-side scripts. Orking 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). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
December 2022
Categories |