CSA overprep dump
SERVICENOW · Certified System Administrator (CSA)
By caffeinated soul
My anxiety-fueled notes on the specific exam traps I keep mixing up so maybe you won't.
Cheat Sheet
1
The traps that tripped me up
- Application Navigator vs. Filter Navigator: I kept mixing these up in practice tests. The Navigator is the whole sidebar menu, but the Filter is just that search box at the top. If the question asks how to find a module, go with the Filter.
- View Rules vs. View Names: A View Name is just a label for the layout. A View Rule is the logic that forces a user into that layout based on conditions. If the prompt mentions automatic switching, it has to be a Rule.
- Form Sections vs. Form Layout: You use the Layout tool to drag things around, but adding a tab is a Section change. Don't get hung up on the tool name.
My mistake: I spent way too long stressing over UI Policies versus Data Policies. UI Policies are for what the user sees on the form. If the question mentions server-side data integrity, ignore the UI stuff and pick Data Policies. Don't overthink the client-side part if the question is about the database.
1
The traps that tripped me up
- Application Navigator vs. Filter Navigator: I kept mixing these up in practice tests. The Navigator is the whole sidebar menu, but the Filter is just that search box at the top. If the question asks how to find a module, go with the Filter.
- View Rules vs. View Names: A View Name is just a label for the layout. A View Rule is the logic that forces a user into that layout based on conditions. If the prompt mentions automatic switching, it has to be a Rule.
- Form Sections vs. Form Layout: You use the Layout tool to drag things around, but adding a tab is a Section change. Don't get hung up on the tool name.
My mistake: I spent way too long stressing over UI Policies versus Data Policies. UI Policies are for what the user sees on the form. If the question mentions server-side data integrity, ignore the UI stuff and pick Data Policies. Don't overthink the client-side part if the question is about the database.
2
UI stuff that actually matters
| The confusing part | How to tell them apart |
|---|---|
| List V2 vs. V3 | V2 is the default. V3 is old and basically dead. Ignore V3. |
| System UI vs. UI Policies | System UI is for global menus. UI Policies are logic for specific forms. |
| View vs. Form Layout | View is the final look. Form Layout is the drag-and-drop tool to build it. |
Watch out: They love to swap 'Filter Navigator' and 'Application Navigator' in the options. The Filter is just the search bar at the top of the menu. Don't waste time trying to figure out the XML behind the menu items. I spent an hour on that and it never shows up on the test. Just know which one is the search box.
3
UI and Navigation edge cases
| Scenario | Best Tool |
|---|---|
| Search scope limits | Search Contexts |
| Form field behavior | UI Policies |
| User-based layout | View Rules |
| Global branding | System UI |
My mistake: I keep mixing up View Rules and UI Policies. If you need to swap the whole form layout based on a role, use a View Rule. Use UI Policies only for hiding or locking fields on the current screen. Don't stress about the technical difference between a View and a Form. Just think of a View as a saved set of fields. You can skip the deep dive on CSS overrides, as the exam ignores custom styling.
4
My workflow for task routing
- Check the user record for existing roles. Always add them to a group instead of dumping roles directly onto the user.
- Check the table. Is it an Incident or a Change? The state flow looks totally different depending on the table.
- Assign to a group. Visibility usually follows the group membership, not the individual.
- Watch for Assignment Rules. If you try to pick a person and the system keeps clearing your choice, an Assignment Rule is likely fighting you.
My mistake: I wasted so much time trying to memorize every single trigger condition for every task type. You really do not need to do that. Just remember that Assignment Rules fire before Business Rules. If a field value changes the second you hit save, it is almost certainly an Assignment Rule overriding you. Don't worry about the complex scripting logic here. Just focus on the order of operations and you will be fine.
5
When I actually use this Data Administration
| Requirement | Pick this |
|---|---|
| Hide rows based on user role | ACL |
| Make a field read-only | UI Policy |
| Validate data format on save | Data Policy |
| Force field logic on imports | Data Policy |
Trap: I keep trying to use UI Policies for security, but they are just for the form experience. If someone edits a field through a List view or a Web Service, the UI Policy does nothing. Use an ACL if you need to stop bad data from hitting the database. Don't overthink the UI Policy script field. Most of the time it is just a simple condition. You do not need to be a coding genius to pass this section. Just ignore the complex scripting edge cases for now.
6
Data Admin: The stuff that actually breaks things
Reference QualifiersChoice ListsDictionary OverridesTable Inheritance
The Dictionary Trap
- Dictionary Overrides: Use these when a parent table field needs to act differently on one specific child table.
- Table Inheritance: Children get everything from the parent. You cannot delete a parent field from a child record. It will break the whole schema.
- Reference Qualifiers: These filter your list results. Simple ones use the condition builder. Dynamic ones use a script.
Wait, slow down: I spent way too long memorizing how to write complex scripts for reference qualifiers. The exam mostly checks if you know they live on the dictionary entry of the field itself. Do not stress about the JavaScript syntax. Just remember that these are the only way to limit what shows up in a reference field lookup. You do not need to be a developer to get these points. Just remember where the form field lives and you will be fine.
7
My order of operations notes
The Execution Trap
- Server vs UI: Business rules run on the server. If your UI policy relies on a server value, the UI policy will fail because it is waiting for data that is still being calculated.
- Client-Side Security: Never trust a client script for security. A user can just disable JavaScript in their browser. Put your real logic in a business rule.
- Async vs Before: Before rules happen right before the database commit. Async rules happen after. If you need to save a value, keep it in a Before rule.
- Event triggers on the record.
- Browser handles UI Policies and Client Scripts.
- Server handles Business Rules.
- Database commits the update.
What not to overthink: I wasted a whole afternoon trying to memorize the exact millisecond difference between every server rule. You do not need to do that. Just remember that the server runs before the browser validation finishes. Also, ignore the deep dive on onCellEdit versus onChange. Just know onCellEdit is for list views and onChange is for forms. That is all the exam wants.
8
Automation logic: Pick the right tool
| Trigger | Best Use Case |
|---|---|
| Flow Designer | Complex logic or external calls. Use for multi-step tasks. |
| Business Rule | Simple record updates. Use if you need to script a quick change. |
| Scheduled Job | Recurring tasks. Use for cleanup or daily reporting. |
| Events | Asynchronous processing. Use to keep the main thread fast. |
The Trap: The exam constantly tries to bait you into picking a Business Rule for things that Flow Designer handles better. If the question mentions branching or integrations, stop looking at scripts. They want to see if you prefer the modern low-code path. Don't worry about the nuance between a flow and a subflow. Just remember: flows trigger, subflows are for reuse. Don't let the reusability debate eat up your time during the test.
9
Stop mixing these up
| Method | The Reality |
|---|---|
| g_form.getValue() | Client-side only. Always returns a string. |
| g_form.getDisplayValue() | Grabs the label you see, not the sys_id. |
| GlideRecord.get() | Pulls one record. Use sys_id or a field match. |
| GlideRecord.query() | Pulls a set of records after your filters. |
| current.update() | Saves work. Avoid this in before rules. |
| current.insert() | Makes a new record. Rarely used in includes. |
The Trap: They keep putting g_form methods into server-side questions. I catch myself doing this all the time, but if the question mentions a Business Rule, g_form cannot exist. It is literally impossible. Just check if the context is client or server before you even look at the syntax. Don't stress about the exact query parameters, just keep the environment split straight in your head.
10
Scripting traps I keep falling for
Watch these specific spots:
- g_scratchpad: Strictly client-side. It lives in onLoad or onChange. Do not try to call it from a Business Rule.
- Query calls: You can stack addQuery all day, but nothing happens until you call query(). It is like writing a letter and never mailing it.
- Business Rules: Async rules run after the user transaction finishes. Never call current.update() here. You will trigger a recursive loop that tanks your instance.
- Client Scripts: onSubmit can return false to kill a save. onChange cannot. Don't waste time trying to make onChange block a submission.
The real trap: I spend way too much time worrying about the exact order of operations. You do not need to memorize the millisecond a query fires. Just remember this: if you are in a Before rule, the system is already saving the record for you. Calling current.update() there is just redundant work. Seriously, ignore the complex timing charts and just remember that Before means the work is already handled.
11
Scripting gotchas that tripped me up
| Check this | Against this |
|---|---|
| g_form.getValue | g_form.getDisplayValue |
| current.update() | current.insert() |
| onSubmit Script | Before Business Rule |
| addQuery() | addEncodedQuery() |
My biggest mistake: I constantly confuse getValue with getDisplayValue. getValue pulls the raw database value, not the label you see on the screen. If you are looking at a choice field, you will get the integer or key, not the text. I spent a whole afternoon staring at a script that was failing because I wanted the label. Just focus on the difference between the raw data and the human-readable text. Also, do not stress about the encoded query syntax. It is just a copy-paste from the list filter. If you are doing one filter, use addQuery. If you have a complex string from the list view, use the encoded version. That is all you need to know.
12
What I would reread on the bus
Update SetsClient vs ServerACL EvaluationImport SetsEvents
- Look at sys_update_xml to see what really moved. It is easy to assume whole tables migrate, but you are only moving specific record deltas.
- Remember the order: Business Rules run before Client Scripts and UI Policies. If your logic feels like it is fighting itself, you have a race condition.
- Double check ACLs. If the user has the role, the condition field gets ignored entirely.
- Check your Transform Map coalesce field. If that is empty, your import will create duplicates every single time.
Bus ride strategy:
Do not waste time memorizing UI Builder layouts. Focus on data flow instead. If you can trace a record from a CSV file to the final destination table, you understand the architecture. Ignore the random menu options you never touched in the labs. They are just there to distract you.