How I Learned about Business Rules and Client Scripts
While preparing for the CSA exam I quickly found that I had some problem areas where I was lacking. One area was the difference between business rules and client scripts.
I vented my frustrations about not being able to keep track of their differences in the WomenNow slack channel (in the SNDevs slack). Immediately I was provided with sites for learning the differences and help from people who have been using these tools for years.
My new bff, Gabi, one of the founders of WomenNow, quickly asked me to write about it. “Writing down the differences will help you and possibly others,” she said. This idea allowed me to see differences easily, and it had a long lasting effect on me. It helped me to learn not only business rules and client scripts, but UI actions, data policy, and UI policies.
The first thing I wrote down was whether the script runs client-side or server-side. This was the major difference and what I needed to remember between the two. An ancient wise sage once said…
Server side is like my web browser calls the server and asks what it wants and the server responds, then we hang up the phone.
Client side, there’s no phone calls cause everything is still in the browser; no phone call means no server update.
Like most web pages, interaction is client side until we make another “phone call” to submit the form to their server or go to another page, etc.
Ah yes, the ancient art of “Phone Calls.”
Business Rules
Business rules run server-side. They take information to and from the server when they run on forms and lists. Not only that, but business rules are major throughout the entire platform as they are configured to run when a record is:
Displayed
Inserted
Updated
Deleted
And also:
When a table is queried
Before or after the database action has occurred
Asynchronously!
Client Scripts
Client Scripts run…well, they run client-side, so there’s no phone call and the changes happen in the user interface as they are made in the browser. They run:
Onchange()
Runs when a particular field’s value changes.
OnLoad()
Runs when a page is loaded.
OnSubmit()
Runs when a record is submitted.
OnCellEdit()
Runs when a cell on a list changes value.
Ok what’s next?
Now, let’s talk UI policy, UI action, and data policy.
UI actions can be server or client-side depending on a checkbox.
They’re the buttons on lists and forms and the context menu.
UI policies are client-side.
A UI policy is a rule that is applied to a form to dynamically change information on the form. Then UI policy actions (the fun friend) determine what happens on the form. For example, setting a field to mandatory or requiring a value in order to save the record. (That’s my favorite part: so much control over what the users can do *evil laugh*. Will I make them have to fill it out or allow them to pass? Sorry, back to the policies…)
Data policies run on the server-side and can be converted into UI policies.
Data policy and UI policy can be a little confusing, so I try to remember that data policy runs on the server-side and can be converted into UI policy. Data policy acts whenever a record is inserted or updated into the database by any means. UI policy runs on the client-side and acts whenever a record is inserted/updated through a form.
While learning these things can be tricky and take time, be persistent, look for what makes sense to you, and build from there. As someone who is new but submerged into all things ServiceNow I can easily say, Do. Not. Give. Up! Go to the Now Community, read through the comments, and learn. Watch videos on YouTube while you navigate and get more familiar with your PDI. Test things out and challenge yourself with simulators on Now Learning. ServiceNow does not quit; there’s even NowCreate, where you can listen to webinars and learn all day. There’s no shortage of learning, so jump in!
