CSA-C01 common mistakes
CSA-C01 · Understand the traps and how to avoid them.
When asked where to change a record's default view or which menu a module appears under, the candidate edits the record form itself or creates a new table column instead of editing the module/application menu record.
Navigation questions are phrased around a visible symptom (a module is in the wrong place), so candidates jump to the data layer rather than the Application Menu and Module records that actually control placement.
What to do instead
Before answering, ask 'is the question about where something is displayed or about what is stored?' If displayed, inspect the Application Menu and Module records (and their order/roles fields), not the table.
Candidate assumes a field's mandatory/read-only behaviour set on the dictionary always wins over a UI policy or client script, and answers that the dictionary setting is the final authority.
Dictionary attributes feel like the 'real' definition of a field, so candidates forget that UI policies and client scripts can override mandatory/read-only behaviour at the form layer, and that server-side enforcement differs from client-side.
What to do instead
Memorise the layering: dictionary attributes define the base, UI policies and client scripts modify the form presentation at runtime, and only server-side validation (business rule / data policy) is a true enforcement. Answer according to which layer the question describes.
Candidate treats a role as a permission on a table and an ACL as a container of users, or assumes assigning a role automatically grants record access without any ACL evaluation.
Roles, groups, and ACLs are all 'access control' concepts and get mentally merged; candidates forget that roles are granted to users/groups and ACLs are the rules that check those roles against a table/field/record.
What to do instead
Draw the chain explicitly: user -> group membership -> role -> ACL condition -> record/field. When a question asks 'who can see this', trace that chain rather than naming a single object.
Candidate answers that deleting a field from a form removes the data, or that a new field automatically appears on every form and list.
Form layout and schema are visually adjacent in the UI, so candidates conflate the form designer with the table dictionary; they forget that removing a field from a form only changes layout, while the column and its data persist.
What to do instead
Separate the three layers: dictionary (column + data), form layout (which fields render), and list layout (which columns show). Deleting from a form is layout-only; deleting the dictionary entry is what affects data.
Candidate builds or selects a filter that uses 'is' versus 'contains' or 'is one of' interchangeably, and gets a different result count than expected on a report.
Filter operators look similar in the picker and candidates skim them; string operators ('contains', 'starts with') behave differently from equality operators ('is', 'is one of') and from 'is empty'/'is not empty'.
What to do instead
For any filter question, restate the operator in plain English before choosing: 'is' = exact match, 'contains' = substring, 'is one of' = set membership, 'is empty' = null. Check the operator, not just the field and value.
Candidate assumes a UI policy and a client script run in the same order or that a client script's onChange fires before the UI policy applies, producing the wrong final field state.
Both are client-side form logic and both can set mandatory/read-only/visible, so candidates don't consider execution order and the 'reverse if false' behaviour of UI policies.
What to do instead
Learn the client-side order (UI policies and client scripts both run on load; UI policy actions apply, then scripts run) and remember UI policies have a 'reverse if false' option while scripts must undo their own changes. When asked for the resulting state, apply policies first, then scripts.
Candidate puts a server-side operation (GlideRecord query, gs.print, current.update) inside a client script, or a client-only call (alert, g_form) inside a business rule, and picks that as the correct answer.
The syntax looks similar and candidates focus on 'what does the logic do' rather than 'where does this code execute', forgetting client scripts cannot query the database directly and business rules cannot call g_form.
What to do instead
Tag every API in the question: g_form/alert = client only; GlideRecord/current/gs = server only. Eliminate any answer that mixes them before evaluating the logic. Use GlideAjax or a script include when a client script genuinely needs server data.
Candidate assumes a flow or workflow approval completes as soon as the approver record is created, or that an 'any one approves' and 'all must approve' approval behave the same.
Approval mechanics involve approval records, approval rules, and the difference between 'Approves' and 'Approves/Rejects' states; candidates collapse these into a single 'approved' event.
What to do instead
For approval questions, identify (a) who the approvers are, (b) whether the rule is any/all, and (c) what state transition ends the approval. Only after all required approvers reach the required state does the flow continue.
Candidate assumes a catalog item's variables are stored as normal table columns, or that a knowledge article becomes visible to end users as soon as it is created.
Catalog variables live in their own variable/question tables and are surfaced through the item's configuration, not the target table's dictionary; knowledge visibility depends on workflow state and the knowledge base's user criteria, which candidates overlook.
What to do instead
For catalog questions, remember variables are defined on the item (and optionally mapped to fields) rather than added as columns. For knowledge, check article state (published vs draft) and the knowledge base's user criteria/can-read settings before concluding it is visible.
Candidate configures a transform map to map a source field directly to a target field without a coalesce, then expects re-imports to update existing records instead of creating duplicates.
Transform maps feel like simple field-to-field mapping, so candidates skip the coalesce key that determines insert-vs-update, and they also forget that a scheduled import needs a data source plus a transform map, not just a file.
What to do instead
For any import question, name the coalesce field first (it decides match/update vs insert), then the field mappings, then the transform on-load scripts. Verify the pipeline: data source -> import set -> transform map -> target table.