ServiceNow CSA Cheat Sheet: Configuration and Access
Recall ServiceNow CSA mechanisms with comparison tables for forms, references, ACLs, imports, catalog work, script timing, analytics and security.
Use this reference to recall a distinction you have already studied. If you cannot explain why a rule applies, work through the scenario guide and the relevant official documentation before attempting another mixed mock. Product screens and available features depend on release, interface, plugins and permissions.
Start with the kind of change
| Need | First distinction to make |
|---|---|
| A person cannot find a module | Navigation visibility versus access to the underlying data. |
| A field behaves differently on a form | UI behaviour versus server-side validation and record authorization. |
| A user can order an item but cannot read a resulting record | Catalog audience versus access to the submitted record. |
| An automation appears not to run | Saved design versus active trigger, qualifying event and execution evidence. |
| Imported rows create duplicates | Source identity and matching rules versus successful file loading. |
| A change works in development but not test | Transported configuration versus dependencies, data and target permissions. |
Name the object, operation and user before choosing a correction. “Access is broken” is less useful than “this user can read the task but cannot write its assignment field.”
Navigation, personalization and shared configuration
A navigation entry is a way to reach work; it does not prove that the current user may perform every operation there. Similarly, changing a personal view should not be confused with changing a shared table definition. When comparing two users, hold the record and operation constant before attributing a difference to roles.
For a lab exercise, record the application, module, table, view and acting user. Change one condition at a time. An administrator seeing a record is weak evidence that the intended business user can see it.
Keep these objects separate
| Object | What it represents | Example distinction |
|---|---|---|
| Application | A collection of related capabilities and configuration. | The place where a process is implemented, rather than an individual task. |
| Module | A navigation entry leading to a function, list or other destination. | Hiding a module does not secure its underlying records. |
| Table and record | A definition of a kind of data, and one instance of that data. | An Incident table versus one incident assigned to your team. |
| Form view | A particular presentation of a record’s fields and sections. | Two views can display different fields from the same record. |
| Personalization | A user’s preferred presentation or experience. | A personal column arrangement does not redefine the team’s data model. |
| Plugin or installed application | Capabilities that may require activation, dependencies or entitlement. | A missing feature is not always a missing role. |
Before installing a capability in a lab, inspect its dependencies and availability. Before changing a shared form, establish the intended table and view. These are different administrative decisions even when both begin with “I cannot see the feature.”
Lists, forms and filters
Read Boolean grouping explicitly. Consider this requirement: show active requests for either the Network or Desktop group. In pseudocode, the condition is:
active = true AND (group = Network OR group = Desktop)
These four test records make the requirement observable:
| Record | Active | Group | Should appear? |
|---|---|---|---|
| A | Yes | Network | Yes |
| B | No | Desktop | No |
| C | Yes | Desktop | Yes |
| D | Yes | Database | No |
A filter that includes B has grouped the conditions incorrectly. Treat this as reasoning pseudocode, not a literal ServiceNow encoded query. A list filter narrows a result set; it is not a substitute for authorization.
Templates, activity and task work
A form template supplies reusable field values. It does not replace a validation rule or an approval process. After applying a template, inspect the actual values before saving: “the template was selected” is weaker evidence than “the intended assignment and description were stored.” A template for a routine request can save entry time while still requiring the user to provide case-specific details.
An assignment group identifies a team; Assigned to identifies an individual. A task with a group and no assignee is not necessarily unowned by a team. Read both fields when interpreting a work queue. Journal fields such as comments and work notes support different communication purposes; check the field’s audience rather than assuming everything visible in an activity stream is public.
For Visual Task Boards, establish the board type. A field-driven lane and a manually organized lane have different implications when a card moves. Confirm the associated task’s value after a move and test access separately from board membership. See board types .
Tables, references and inheritance
| Concept | Recall rule | Useful check |
|---|---|---|
| Dictionary definition | Describes a table or field, including its type and attributes. | Is the change to stored structure or only form layout? |
| Table extension | A child table inherits from its parent. | Is this a shared parent field or a child-specific field? |
| Reference field | Connects a record to another record; the displayed label is not its identity. | Do two identical names point to different records? |
| Dot-walking | Follows a reference to a field on the related record. | Are you reading the caller’s department or an incident’s own field? |
| Related list | Displays related records in the record’s context. | Which relationship determines membership in the list? |
Example: two users are both displayed as “Alex Lee.” An incident must refer to the intended user’s record, not whichever visible name happens to come first. If that user changes their display name, it does not create a new person or mean every referencing incident must acquire a new identity. Use identifiers and relationship evidence when investigating a mismatch. Review tables and data models .
Form behaviour, data consistency and security
| Mechanism | Main purpose | Check before concluding it solves the problem |
|---|---|---|
| UI policy | Conditional form behaviour such as visible, mandatory or read-only fields. | Applicable view, On load, Reverse if false and other policies affecting the same field. |
| Client script | Browser-side response to an interface event. | Script type, supported interface and whether the operation actually uses that interface. |
| Data policy | Mandatory/read-only data consistency. | Its configured applicability to the write path being tested. |
| Business Rule | Server-side record processing. | Table, condition, operation and execution timing. |
| ACL | Authorization for a secured object and operation. | Acting user, applicable rules, decision types, table and field requirements. |
A field hidden by a form rule may still exist in the record. A good test therefore distinguishes what the user sees from what the user is authorized to read or change. ServiceNow’s form-logic guidance and client-script documentation explain why interface behaviour alone is insufficient for other data-entry paths.
UI policy reminder: On load includes evaluation when the form opens; Reverse if false reverses configured actions when the condition becomes false. Check competing rules before predicting the final state. UI policy documentation .
Read access-control evidence carefully
An ACL concerns an operation on a secured object. A table read and a field write are different checks. Do not infer write access from read access, or field access from the fact that a record opened.
Modern documentation distinguishes Allow-If and Deny-Unless. A failing applicable Deny-Unless rule can block access despite a permissive Allow-If rule. Identify the applicable rule set before applying a simplified “one matching rule allows it” shortcut. Use a representative non-admin account and account for elevated privileges or admin override when relevant. ACL overview and Deny-Unless evaluation .
Catalog, knowledge and fulfillment
Catalog user criteria concern who can discover or request an item. Reading a record created after submission is a separate access question. ServiceNow’s catalog user-criteria diagnostic explicitly does not diagnose ACL rules.
For knowledge, investigate the article and knowledge-base context as well as the user’s criteria. A published article is not proof that every user can read it. Knowledge user-criteria diagnostics .
In a standard requested-item workflow, distinguish the overall request, each requested item and the tasks used to fulfill it. One shopping request can involve several items and several fulfillment steps. A completed task does not, by itself, establish that all requested work is complete. Catalog task relationships .
Item, producer, guide and variables
| Requirement | Starting concept |
|---|---|
| Order equipment that follows a request fulfillment process | Standard catalog item and its fulfillment design. |
| Give an employee a simple way to create an incident | Record producer targeting the appropriate task-based table. |
| Help an employee request a related group of items | Order guide with the relevant item-selection rules. |
| Collect a size, date, justification or selected person | Catalog variables of appropriate types. |
A record producer looks like a catalog offering but creates its target task-based record instead of a requested item. Do not search only for an RITM to decide whether a producer submission succeeded. Record Producer documentation .
Knowledge check: separate article state, knowledge-base access and the intended reader. “Published” answers a lifecycle question; it does not by itself answer authorization. Test as the reader, not just the author.
Virtual Agent check: distinguish the conversational topic, the information collected, the action performed and any human handoff. A friendly confirmation message is not evidence that a requested record was created. Test an unsupported request and an unavailable-agent path as well as the happy path. The scenario guide gives a concrete example.
Automation: follow the evidence
A useful inspection sequence is event → trigger conditions → execution → action result. An edited design and a qualifying record do not prove that an execution occurred. Look at execution evidence rather than repeatedly changing a working action.
Workflow Studio supports different trigger types. For record-triggered work, check which changes qualify and how repeated updates are handled. A flow that updates a record needs particular care if that update can qualify it for another run. Flow trigger types .
For Business Rules, recognize server-side timing: before, after, asynchronous and display have different purposes. An asynchronous result is not necessarily available immediately after the initiating transaction. Business Rules .
Read a short script by context and timing
| Context | Question to ask |
|---|---|
onLoad client script | What happens when this supported form loads? |
onChange client script | Which field change invokes the logic, and which guards stop it? |
onSubmit client script | What runs when this form is submitted? |
| Before Business Rule | What must be set or checked before the database operation? |
| After Business Rule | What dependent work requires the completed operation? |
| Async Business Rule | Can this work occur later without an immediate result or guaranteed order? |
| Display Business Rule | What server-side preparation is needed when the record is displayed? |
The same-looking condition in a browser script and a server rule does not imply the same execution path. Identify the table, operation and conditions before tracing values. Use declarative configuration where it meets the requirement; scripting is not inherently a better answer. See client scripts and Business Rules .
Analytics and notifications
For a visualization, name the population, filter, aggregation and time basis. “Open tasks by group now” and “tasks opened each month” answer different questions. A dashboard arranges visualizations; it does not make their definitions equivalent. Historical indicators require appropriate historical measurements, not just a new chart type. Platform Analytics and Performance Analytics concepts .
Sharing the dashboard is also distinct from authorizing its data. Verify the viewer’s experience and the relevant data-source/report controls. Avoid assuming every aggregate uses the same per-record filtering behavior.
For a notification, trace qualifying change or event → condition → recipients → generated email → delivery evidence. An email record marked as sent by the platform still does not prove that a person read it. No generated email and an email generated without a usable recipient are different failures. The system email log connects messages with their originating event and notification.
Imports: loading is not transforming
An import set stages rows; a transform map connects source fields with target fields. Coalescing controls matching to existing target records. When several fields coalesce, treat them as a combined match, not alternative lookup keys. Inspect blank values, duplicate keys and transform settings before assuming that a successful run produced correct business records. Field maps and transform maps .
A useful reconciliation checks inserted, updated, ignored and failed rows, then inspects important field values and relationships. Matching total counts alone does not show that the right record was updated.
CMDB, CSDM and configuration transport
The CMDB holds configuration items and their relationships. CSDM supplies modeling guidance and terminology for organizing service data; it is not another name for the database. A useful relationship should help explain the service affected by a component, not merely make a diagram look complete. CMDB overview and CSDM model .
Update sets transport tracked configuration, not ordinary submitted orders or task transactions. Preview and conflict resolution are preparation for a commit, not proof that the resulting application works. Keep dependencies and separate data loads in a deployment checklist. Tracked customizations .
Security posture and responsibility
Security Center findings help identify and prioritize configuration concerns. A finding becoming visible is not remediation. Record the owner, approved change and evidence from a later check. For an access issue, test an allowed user and a denied user against the same operation.
In the shared-responsibility model, distinguish provider-operated infrastructure from customer decisions about users, permissions, configuration and data. A hosted platform does not remove the customer’s responsibility to configure appropriate access. If a team grants an unnecessarily broad role, correcting that grant is a customer administration task. Use Security Center documentation with the responsibilities established for your organization.
Use the reference to choose your next session
For a missed question, write the distinction you overlooked, identify the fact that selects the correct mechanism, and invent a second example with a changed condition. Use the blueprint to check coverage and the study plan to schedule the next review. A familiar-set percentage is not a validated prediction of passing CSA.