Business Rule Types (Before, After, Async, Display)

Business Rule Types (Before, After, Async, Display) – ServiceNow CAD Exam Guide

Why Business Rule Types Matter

Business Rules are one of the most powerful server-side automation tools in ServiceNow. Understanding the four types of Business Rules — Before, After, Async, and Display — is essential for the ServiceNow Certified Application Developer (CAD) exam. These rule types determine when your server-side logic executes relative to the database operation, and choosing the wrong type can lead to performance issues, unexpected behavior, or data integrity problems. On the exam, you will encounter scenario-based questions that test your ability to select the correct Business Rule type for a given requirement.

What Are Business Rule Types?

A Business Rule is a server-side script that runs when a record is displayed, inserted, updated, deleted, or queried. Every Business Rule is configured with a When field that controls its execution timing. The four options are:

1. Before Business Rules
These execute before the database operation (insert, update, or delete) takes place. The record has not yet been saved to the database when the script runs.

Key Characteristics:
- Used to modify field values on the current record before it is written to the database.
- No need to call current.update() — the system will save the record automatically after the Before rule completes.
- Calling current.update() inside a Before rule is a common anti-pattern and can cause recursive execution and performance degradation.
- Ideal for setting default values, validating data, or aborting the operation with current.setAbortAction(true).

Example Use Cases:
- Automatically setting the Priority field based on Impact and Urgency before the incident is saved.
- Preventing a record from being saved if mandatory conditions are not met.
- Normalizing or formatting data before it hits the database.

2. After Business Rules
These execute after the database operation has completed. The record has already been committed to the database.

Key Characteristics:
- The record is already saved, so any changes to current fields require an explicit current.update() call — but this is generally discouraged as it triggers another database operation and can cause recursive rules.
- Best used for actions that depend on the record already existing in the database, such as creating related records, sending events, or updating other tables.
- Runs in the same transaction as the triggering operation.

Example Use Cases:
- Creating child tasks or related records after a parent record is inserted.
- Sending an event to trigger a notification after a record is updated.
- Updating a parent record's field when a child record changes.

3. Async Business Rules
These execute after the database operation, but they run in a separate, asynchronous transaction on a scheduler worker thread.

Key Characteristics:
- They do not block the user's transaction — the user sees their save complete without waiting for the Async rule to finish.
- Ideal for long-running or resource-intensive operations that should not slow down the user experience.
- Because they run in a different transaction, they have access to the current and previous objects, but the data reflects the state at the time the async job was queued.
- They are essentially scheduled jobs that execute as soon as a scheduler worker is available.
- If you need to modify the current record in an Async rule, you must call current.update().

Example Use Cases:
- Sending REST or SOAP messages to external systems after a record is saved.
- Performing complex calculations or data aggregation that would be too slow for a synchronous rule.
- Generating reports or documents triggered by a record change.

4. Display Business Rules
These execute before the form is displayed to the user but after the record has been read from the database.

Key Characteristics:
- They run when a record is loaded for display (i.e., when a user opens a form), not when the record is saved.
- They respond to the query database operation (the form load query), not insert/update/delete.
- Used to set values in the g_scratchpad object, which makes server-side data available to client-side scripts.
- Changes made to current in a Display rule will appear on the form but will not be saved to the database unless the user submits the form.
- They are the bridge between server-side data and client-side scripts.

Example Use Cases:
- Passing server-side information (like a user's role or a system property value) to a Client Script via g_scratchpad.
- Setting a temporary field value to display on the form without saving it.
- Calculating and displaying a value that is derived from related records.

How Business Rules Work – Execution Order

Understanding the execution order is critical:

1. User submits a form (insert or update).
2. Before Business Rules execute (in order of their Order field value, lowest first).
3. The database operation occurs (insert, update, or delete).
4. After Business Rules execute (in the same transaction).
5. Async Business Rules are queued and execute when a scheduler worker picks them up.

For form loads:
1. The record is read from the database.
2. Display Business Rules execute.
3. The form is rendered for the user.

Key Comparison Table

Before: Runs before DB operation | Same transaction | Use for modifying current record | Do NOT call current.update()
After: Runs after DB operation | Same transaction | Use for creating related records, events | Avoid modifying current
Async: Runs after DB operation | Separate transaction | Use for long-running or external integrations | Must call current.update() if modifying
Display: Runs when form loads | Query operation | Use for g_scratchpad, temporary display values | Changes not auto-saved

Common Pitfalls to Understand

- Calling current.update() in a Before rule is wrong and can cause infinite loops.
- Using a synchronous After rule for a long-running process (like an external API call) will slow down the user experience. Use Async instead.
- Assuming a Display rule saves data — it does not persist changes unless the user submits the form.
- Forgetting that Async rules run in a different transaction and may not reflect real-time changes made by other concurrent processes.

Exam Tips: Answering Questions on Business Rule Types (Before, After, Async, Display)

Tip 1: Read the scenario for timing clues.
If the question says "before the record is saved" or "set a field value before insert," the answer is Before. If it says "after the record is saved" or "create a related record," think After or Async.

Tip 2: Look for performance and user experience keywords.
If the scenario mentions "without impacting user experience," "long-running process," "external system call," or "asynchronous," the answer is Async.

Tip 3: Watch for g_scratchpad.
Any mention of g_scratchpad or passing data to a Client Script from the server side immediately points to a Display Business Rule.

Tip 4: Remember the current.update() rule.
If a question asks what is wrong with a Business Rule that calls current.update() in a Before rule, the answer is that it is unnecessary and causes performance issues or recursion. In Before rules, changes to current are saved automatically.

Tip 5: Know which database operations each type responds to.
Before, After, and Async rules respond to insert, update, delete operations. Display rules respond to query (form load) operations. If the question is about form display behavior, choose Display.

Tip 6: Distinguish After from Async.
Both run after the database operation. The key difference is that After runs in the same transaction (synchronous), while Async runs in a separate transaction (asynchronous). If the scenario needs guaranteed immediate execution after save within the same transaction, choose After. If it can tolerate a slight delay, choose Async.

Tip 7: Elimination strategy.
On multiple-choice questions, quickly eliminate options that do not match the timing or purpose. For instance, if the requirement is to abort an insert, After and Async are too late — only Before can abort the action.

Tip 8: Practice with real scenarios.
The CAD exam is heavily scenario-based. Practice by reading a requirement and immediately identifying: (a) What is the trigger? (b) When should the logic run? (c) Does it need to be synchronous or asynchronous? (d) Does it involve form display or database operations? This framework will consistently lead you to the correct Business Rule type.

Summary

Mastering the four Business Rule types is a foundational skill for the ServiceNow CAD exam. Remember: Before for pre-save modifications, After for post-save synchronous actions, Async for post-save operations that should not block the user, and Display for making server data available on form load via g_scratchpad. With these principles firmly in mind and consistent practice applying them to scenarios, you will be well-prepared to answer any Business Rule type question on the exam.