Business Logic and Scripting (Client and Server Side)
What to know
Server-side logic lives in business rules (sys_script). Know the four timings: before (runs before the record is written; use current.setValue() to change the record without a second update), after (record already written; use for side effects such as creating child records or notifications), async (queued, runs after the transaction, no user session), and display (runs only when a form loads and cannot persist changes). Before-query rules inject conditions into list queries; know their performance risk.
Reusable server code belongs in script includes, typically ES5-style prototypes or classes, called with new MyHelper(). GlideRecord is the data API: addQuery, addEncodedQuery, get, next, setValue, insert, update, setLimit, and getValue. Use GlideAggregate for counts and sums instead of looping, and previous in after rules to compare values.
Client-side logic lives in client scripts and UI policies: g_form, g_user, g_scratchpad, and GlideAjax calling a script include that extends AbstractAjaxProcessor. Client scripts cannot query the database directly - that is the classic exam scenario for GlideAjax.
Also know Flow Designer for orchestration and scheduled jobs for recurring work.
Traps
- Calling
current.update()inside a business rule on the current record, causing recursion and duplicate side effects. - Trying to use
GlideRecordin a client script. - Assuming display business rules persist values; they do not.
- Forgetting
setWorkflow(false)when you do not want notifications or flows triggered. - Assuming an async rule can read the user's session or
g_scratchpad.
Worked example
Auto-assign a group on insert: before-insert business rule with condition Assignment group is empty, script current.setValue('assignment_group', <sys_id>);. The write happens as part of the same insert - no extra update.
Rule of thumb: change the record before, react to the record after.