Business Rules, Flow Designer, and Script Includes
Key Takeaways
- Business Rule timing is an exam-favorite decision point: before changes the current record before commit, after reacts to committed data, async moves non-urgent work off the user's transaction, and display prepares g_scratchpad data for form load.
- Flow Designer is best for readable process automation; flows have triggers, subflows package reusable logic without their own trigger, and actions are reusable steps that collect inputs and produce outputs.
- Script Includes centralize reusable server logic, while GlideAjax exposes approved client-callable methods to forms without putting database logic in the browser.
- Use GlideRecord for server-side table work, but prefer GlideRecordSecure when returning user-context data where Access Control Lists must be honored automatically.
- A strong CAD answer usually chooses configuration first, then script only for precise validation, reusable logic, or a requirement Flow Designer cannot express cleanly.
Business Rules, Flow Designer, and Script Includes
Quick Answer: Use Business Rules for trusted server-side logic tied directly to database activity, Flow Designer for readable process automation, and Script Includes for reusable server logic. If a client script needs server data, call a client-callable Script Include with GlideAjax; if a script returns records in user context, consider GlideRecordSecure so Access Control Lists are respected.
CAD automation questions usually test tool selection, not raw memorization. Read the requirement for three clues: when the logic must run, who must maintain it, and whether the result must be protected by server-side security.
Business Rule Timing
A Business Rule is server-side JavaScript that reacts to record operations such as insert, update, delete, query, or display. Timing matters because it changes both behavior and performance.
| Timing | Runs | Best use | CAD trap |
|---|---|---|---|
| Before | Before database commit | Set or validate fields on current before save | Calling current.update() can cause recursion and extra writes. |
| After | After commit | Create related records or update records that depend on the saved record | Do not use it just to change the same record you could change before save. |
| Async | After commit in the background | Non-urgent calculations, metrics, integrations, or heavier work | It may not finish before the user sees the result. |
| Display | Before a form is sent to the browser | Put server data on g_scratchpad for client scripts | It is for form-load support, not post-save processing. |
Always add a condition when possible. A broad Business Rule that runs on every update is harder to debug, slower, and more likely to create side effects than a narrowly scoped rule.
Flow, Subflow, and Action
Flow Designer is the low-code automation layer. A flow has a trigger, such as a record being created or updated. A subflow has no standalone trigger; it is called by a flow or script and is ideal for reusable logic such as a standard approval path. An action is a reusable step with inputs and outputs, such as creating a task, sending a notification, calling an integration, or applying a custom operation.
Use Flow Designer when the process should be visible to admins and process owners: approvals, task routing, notifications, service catalog fulfillment, and cross-step orchestration. Use a Business Rule when the requirement is tightly coupled to record commit behavior, especially validation before save.
Script Includes, GlideAjax, and Secure Queries
A Script Include stores reusable server-side functions or classes. It keeps shared logic out of multiple Business Rules, UI Actions, and flows. If browser code needs a server answer, mark the Script Include client callable and call it with GlideAjax. Return only the value needed by the form, not a broad record payload.
GlideRecord is the standard server-side table API. It is powerful but must be written carefully: validate queries, avoid overly broad updates, and use getValue() or getDisplayValue() instead of grabbing entire reference objects when a string value is enough. GlideRecordSecure performs similar table work while enforcing ACLs, which makes it safer when user-facing logic requests records through a client-callable path.
Exam Decision Checklist
- Need to stop an invalid save? Use a before Business Rule or another server-enforced control.
- Need a readable approval or fulfillment path? Start with Flow Designer.
- Need reusable server logic? Create a Script Include.
- Need client-side form code to ask the server for a value? Use GlideAjax.
- Need returned records to honor the user's ACLs? Prefer GlideRecordSecure.
A scoped expense app must reject saves when the amount exceeds a hard limit, route approved records through a manager approval path, and reuse a currency-formatting helper from several scripts. Which design is strongest?