SNOW-CSA Flashcards — Free ServiceNow Certified System Administrator CSA Study Cards

Create a transform map that maps the source field to the target field, and use a field mapping script to convert the department name to the correct sys_id.

Import Set Rows are processed through transform maps, which allow field mapping scripts to convert source values (like 'Human Resources') into the corresponding sys_id in the Department [cmn_department] table. This is the standard, supported approach for handling reference field lookups during imports, ensuring data integrity without manual intervention or post-insert processing.

Check the condition (prompt) filter of the report to see if there is a time-based filter that limits to the current week.

The report's condition filter (often called a 'prompt' or 'filter condition') directly controls which records are included. If a time-based condition like 'Opened > Current week' or 'Resolved > Current week' is applied, it would exclude incidents resolved before the current week, causing the low count. The administrator should first inspect the filter conditions to see if such a restriction exists.

The SLA stop condition is set to 'State is Resolved', but the SLA was paused due to a schedule (e.g., after-hours pause) and the pause time was not counted, causing the actual working time to exceed 4 hours.

The most likely cause is that the SLA stop condition is set to 'State is Resolved', but the SLA timer was paused due to a schedule (e.g., after-hours) at the time the incident was resolved. Because the timer was paused, the stop condition was not evaluated immediately. When the schedule resumed, the working timer continued to run, and by the time the stop condition was evaluated, the accumulated working time had already exceeded the 4-hour duration, resulting in a breach. In ServiceNow, SLA timers that are paused do not trigger stop conditions until they resume, which can cause breaches even when the incident is resolved within the expected real-time window.

Record Producer

A Record Producer is the correct self-service feature because it allows users to submit requests for new software through a catalog item without any manual intervention. It automatically creates a record (e.g., a catalog task or request) in the platform based on the user's submission, enabling a fully automated request process.

User criteria restricts visibility

User criteria is a visibility rule applied to catalog items that restricts which users or groups can see the item in the service catalog. If one user cannot see the item while others in the same department can, the most likely cause is that the user criteria on the catalog item excludes that specific user, either by user, role, group, or location criteria.

Enable caching for widgets

Enabling caching for widgets reduces server load and improves page load times by storing rendered widget output in memory, allowing subsequent requests to serve cached content without re-executing the underlying scripts or queries. This directly addresses performance degradation during peak usage without altering the user interface, making it the best practice approach.

Enable personalization on the form

Personalization allows individual users to add fields to a form without affecting the form layout for all users. By enabling personalization on the incident form, the system administrator grants end users the ability to add the 'Mobile Phone' field to their own view of the form, which is stored per user in the sys_user_preference table.

The user has a personal form layout that removed the field

The user's personal form layout can override the default form view, removing fields like 'Category' for that specific user while others see the field. This is a common scenario where a user has customized their own form layout, either intentionally or accidentally, by dragging the field off the form or using the personalization options.

List

A List module type is specifically designed to display a table of records from a specified table, such as the sys_user table for users. When creating a module under the 'User Administration' application menu, selecting List allows the administrator to configure the module to show a list view of user records, including columns, filters, and sorting options.

The CI is classified under a different CI class in the CMDB.

When a CI is classified under a different CI class in the CMDB, the scheduled discovery job may not update it because discovery uses the IRE to match incoming data against existing CIs based on identification rules. If the CI's class differs from what the discovery payload expects, the IRE may fail to reconcile the record, or the update may be directed to a different class table, leaving the original CI unchanged. This is a common cause of apparent update failures when the CI is reachable and the discovery source is correctly configured.

Dependency relationship (structural)

A dependency relationship (structural) is the correct model because it explicitly captures the directional 'depends on' nature of the chain: a business service relies on an application, which in turn relies on a server. In ServiceNow CMDB, structural dependency relationships (e.g., 'Depends on' or 'Used by') are designed to represent these hierarchical, transitive dependencies between CIs, enabling impact analysis and root cause mapping.

The identification rule for the CI class does not include the serial number.

The identification rule determines which fields are used to uniquely identify a CI. If the serial number is not included in the identification rule, the CMDB cannot detect duplicates based on serial number, allowing multiple CIs with the same serial number but different names and IP addresses to be created. This is a common misconfiguration that leads to CI proliferation and data inconsistency.

Create an Approval rule with conditions on cost and department budget.

Approval rules in ServiceNow are specifically designed to automate approval decisions based on conditions like cost and department budget. By creating an Approval rule on the catalog item, you can evaluate the requested cost against a threshold and check the department's budget balance via a condition script or reference to the budget table, enabling automatic approval without manual intervention.

Use the 'Email' variable type; it includes validation.

The 'Email' variable type in Service Catalog automatically validates that the entered value conforms to a standard email format (e.g., user@domain.com). This built-in validation ensures the manager's email is syntactically correct before the notification is triggered, without requiring additional scripting or regex. Option D is correct because it leverages this native validation, which is the simplest and most reliable method.

The business rule is running on 'before query' instead of 'before insert'.

The business rule is configured to run on the 'before query' operation, which means it executes every time a query is made against the 'u_employee_data' table. This causes the condition to set the 'u_department' field to 'Engineering' for all records returned by the query, effectively filtering the result set to only those with that department. The intended behavior is to set the default department only when a new record is created, which requires the business rule to run on the 'before insert' operation instead.

Another ACL with higher order denies read access to all incidents not matching the condition.

ACLs in ServiceNow are evaluated in order of their 'order' field, and the first matching ACL (either allowing or denying access) determines the outcome. If another ACL with a higher order (lower numeric value) denies read access to incidents not matching the condition, that deny rule will take precedence over the new ACL, preventing the user from viewing incidents assigned to 'Network Support' even though the new ACL would allow it. The user's role and group membership are satisfied, so the issue lies in ACL ordering and a conflicting deny rule.