ServiceNow CSA Scenario Guide: Worked Administration Cases

These are original teaching cases, not official ServiceNow exam questions. Each uses simplified, explicit assumptions so the conclusion follows from the evidence. Read the situation, predict the result, then compare your reasoning with the explanation. Use current product documentation for your instance release and interface.

Choose a case for the mistake you made

For each case, predict an outcome before reading the explanation. The lab suggestions use synthetic data in an authorized training environment. They are exercises in tracing behavior, not instructions to change a production instance.

Case 1: ordering an item does not grant record access

A team leader can find and order a catalog item. After an employee orders it, the leader cannot read the resulting requested-item record. The scenario states that the applicable read authorization permits the requested user and fulfillment staff; it has no manager exception. The business requirement is to allow leaders to read only their own direct reports’ requested items.

Reasoning: item availability and requested-item access are different decisions. Widening the catalog audience changes who can order, not the specified read authorization. Giving the leader broad fulfillment access also exceeds the stated need. The correction belongs in the applicable record-access design, scoped to the direct-report relationship and evaluated with all relevant access rules.

Verify: test a direct report, another leader’s employee and the leader’s own request with representative non-admin accounts. Include any sensitive field restrictions. A passing test for one allowed record is insufficient without a denied-record test.

Change the case: if the leader cannot discover the item at all, investigate its user criteria instead. The catalog diagnostic evaluates user-criteria access, not ACLs. Review the ACL model for record authorization.

Case 2: the right rule runs at the wrong moment

A form policy makes u_justification mandatory when u_exception is true. In this lab there are no competing policies or scripts, the policy applies to the current view, and the field is initially optional. The policy has On load off and Reverse if false on.

Reasoning: this configuration does not perform the policy action when the form initially loads. The later changes exercise its condition, and Reverse if false reverses the configured action when the condition stops being true. If the requirement includes opening existing exception records, enabling On load addresses the missing evaluation point.

Verify: test initial load, both condition transitions and a different applicable view. If a result still differs, inspect other rules before assuming the policy has no effect. These settings concern the form; they do not establish enforcement on an integration write. UI policy settings .

Case 3: an import updates the wrong kind of match

A custom training table stores supplier contacts. Its intended business identity is the pair (supplier_code, contact_code). Both fields are configured to coalesce. All keys are non-empty, target keys are unique, inserts are allowed, and no transform script overrides matching.

The incoming rows are (S20, C01, South support) and (S30, C01, New desk).

Reasoning: both coalesce fields must match. The first row updates the S20/C01 record. The second has no combined match and creates a new record under the stated insert settings. The shared contact code alone is not enough to update either existing row.

Verify: expect one update and one insert, then inspect the identities and names. Row counts without identity checks would miss an update to the wrong supplier. ServiceNow documents combined coalesce matching and transform-map settings .

Change the case: if inserts are intentionally suppressed, the second row cannot be assumed to create a record. If a key is blank, inspect the relevant blank-coalesce settings. Establish those facts before applying the remembered update-or-insert result.

Case 4: a successful form script leaves imported data unchanged

A browser form script builds a contact display label while the user enters given and family names. An import supplies those two fields but no label. The import does not open that browser form, and the lab has no equivalent transform or server-side label logic.

Reasoning: the script’s execution context explains the missing value. A form event did not occur on the import path. If the label must be populated for this import, add the appropriate transformation; if it must remain consistent across several write paths, design and test suitable server-side handling. The requirement determines the scope of the fix.

Verify: compare an interactive save, an import and any other supported write path. Check repeated updates and blank inputs. The original form behaviour can remain useful for immediate feedback, but its existence is not evidence that every path enforces the same result. Client-side versus server-side processing .

Case 5: the import is complete but fulfillment is not

In this teaching example, a new-hire intake file has loaded successfully into a staging table. A team expects a fulfillment task for each accepted intake. The design requires transformation to a target request record, followed by a qualifying automation execution. There are no target records yet.

    flowchart TD
	  A[Source rows loaded] --> B[Staging records]
	  B --> C[Transform to target records]
	  C --> D[Qualifying automation trigger]
	  D --> E[Execution and action result]
	  E --> F[Verify fulfillment record]

Reasoning: evidence establishes only the first part of the designed process. Investigate the transformation before rewriting the downstream task action. An import completion message is not evidence that the target event occurred.

Verify: follow one known source row through the intended target identity, then inspect the qualifying event and execution outcome. If the target record exists but no execution does, the investigation moves to trigger conditions and activation. Workflow Studio trigger documentation .

Change the case: if an execution exists and the task action failed, the earlier steps are no longer the immediate uncertainty. Read the action’s error and inputs. A useful diagnosis moves with the evidence.

Case 6: a clean preview does not complete a deployment

A team captures a catalog configuration change in an update set and previews it in a test instance. The preview has no unresolved conflicts. The team also expects development’s submitted requests to appear in test and declares the deployment verified without committing or performing a test order.

Reasoning: several claims exceed the evidence. Preview is not commit; tracked configuration is not ordinary transaction data; and a committed change still needs functional testing. Submitted requests are not transported simply because the catalog definition is captured. Customizations tracked by update sets .

Verify: check dependencies and the target change set, commit through the authorized process, then create a fresh test request as a representative user. Inspect the expected fulfillment result. Arrange any required test data separately and record manual steps. ServiceNow’s update-set guidance describes why accompanying data and manual changes need attention.

Change the case: if the team is distributing an application, first confirm the appropriate deployment mechanism. An update set is not automatically the right choice for every kind of installation.

Case 7: two convincing charts answer different questions

A team asks, “How many active tasks does each assignment group have now?” Two authors create charts from the same authorized training records. Author A filters active = true and counts records by group. Author B filters by this month’s opening date and counts records by group. Neither chart has additional filters.

Work it out: predict each chart’s Network and Desktop totals. Then identify which chart answers the stated question.

Reasoning: Author A obtains Network 2 (T1 and T4), Desktop 1 (T3). Author B also obtains Network 2 (T2 and T4), Desktop 1 (T3). The identical totals conceal different populations. Only A answers the current-active-work question. Changing B’s color, title or chart type does not repair its filter.

If T1 closes tomorrow and nothing else changes, A’s Network count falls to 1 while B’s remains 2. This changed-fact test exposes the distinction that the initial totals concealed. A current snapshot also cannot establish what the active backlog was at each prior month-end. That question needs suitable historical evidence or collected indicator scores.

Verify: inspect the contributing records as well as totals. Check the source, time field, filter and aggregation before publishing a dashboard. Test the intended viewer’s permissions separately. Read Platform Analytics dashboard guidance and indicator concepts .

Lab output: keep the four-record table, both filters and predicted results after T1 closes. A screenshot of two matching charts would not establish that both were correct.

Case 8: a notification cannot find its recipient

A training notification is configured to run when a request changes to Approved. Its recipient is the user in Requested for. The case supplies these observations:

Reasoning: the recipient source is empty. Rewriting the message body or broadening the trigger does not create an intended recipient. Establish why Requested for is missing and how the process should populate it. If the process permits an empty field, decide on an authorized fallback rather than silently emailing every member of a large group.

Verify: compare the missing-recipient case with a fresh qualifying record that references a test user with a usable address. Inspect the originating notification and email evidence. Do not repeatedly send real mail while debugging a lab; use the environment’s approved test-mail arrangement.

Change the case: if a generated message has the correct recipient but never reaches the mailbox, the uncertainty has moved downstream. Investigate sending status and mail delivery evidence rather than assuming the notification did not run. The system email log documents records and states that support this distinction.

Case 9: a reference name is mistaken for a record identity

Two user records have the display name Alex Lee. One works in Finance, the other in Operations. An incident’s caller reference points to the Operations user, but the requester intended the Finance user. The task is otherwise correctly assigned and categorized.

User U-FIN: display name Alex Lee, department Finance
User U-OPS: display name Alex Lee, department Operations
Incident INC-LAB: caller -> U-OPS
Required relationship: INC-LAB caller -> U-FIN

The identifiers above are teaching labels, not literal ServiceNow sys_id values.

Reasoning: the problem is the relationship to the wrong user record. Changing the incident’s short description or renaming the Operations user does not set the caller reference to the Finance user. Inspect identifying information, select the intended record and verify the reference. Dot-walking from the caller to department follows whichever record is actually referenced, not the department suggested by the human-readable name.

Verify: inspect the selected caller and related department. Then change a display label in the lab and observe whether the same underlying user remains referenced. This separates identity from presentation. Read tables and data models .

Change the case: if the caller is correct but the form omits department, first investigate the view and field presentation. That is different from changing the stored relationship. A form-layout correction should not alter a correct caller.

Case 10: a successful producer submission has no requested item

An employee uses “Report a broken monitor” in the catalog. The administrator implemented it as a record producer targeting Incident. The submission succeeds and an incident contains the supplied description. A tester declares failure because no requested item exists.

Reasoning: the expected artifact is wrong. In this design, the producer creates the target task-based record. A standard item for ordering a replacement monitor could instead use requested-item fulfillment. Similar wording and catalog presentation do not make these the same mechanism. Record Producer documentation .

Verify: inspect the actual target table, values mapped from variables and the submitter’s permitted follow-up experience. The form appearing in the catalog is not sufficient evidence of correct data mapping.

Change the case: the business now requires approval, procurement and delivery tracking for a new purchase. Re-evaluate the service design against those outcomes. Do not choose a producer merely because it was suitable for fault reporting.

Case 11: a conversation confirms work that never happened

A Virtual Agent topic collects a location and problem description. In the supplied design, it must call an action to create an incident, return its identifier, and show that identifier to the employee. When the action fails, the conversation still displays “Your incident has been created.” No incident or successful action result exists.

Reasoning: the message is disconnected from execution evidence. The success branch should depend on a successful action outcome and the returned record identifier. The failure path should explain what happened and offer the configured next step. Editing the greeting or adding more questions does not correct the false confirmation.

Verification matrix:

Availability and routing matter for human handoff; displaying “connecting” does not prove that an agent has accepted. See ServiceNow’s live-agent transfer guidance and check the release relevant to the lab.

Change the case: if the incident exists but its location is wrong, inspect input mapping and the submitted value. The correct investigation depends on which expected artifact is missing or incorrect.

Case 12: a visible record still has a protected field

A custom training table has a sensitive Internal assessment field. The case explicitly states that table-level read access has passed. The field’s applicable authorization requires membership in a review role. The test user lacks that role and has no administrative override. No other rule changes the result.

Reasoning: access to the record does not establish permission to read every field. Adding the field to a form layout changes presentation, not the supplied authorization requirement. If the user legitimately needs the field, review the role and access design; if they do not, preserve the restriction.

Modern ACLs can include Allow-If and Deny-Unless decisions, so inspect the actual applicable rules before extending this simplified example. A failed applicable Deny-Unless requirement can block access despite an Allow-If result. Use ACL documentation and Deny-Unless behavior .

Verify: use representative non-admin accounts and test both allowed and denied cases. Hiding a field with a UI policy is not an alternative authorization test.

Turn a solved case into useful practice

Write down the decisive fact, a plausible but ineffective fix, and one changed assumption that would alter your conclusion. Then try a different case in topic practice. For concise reminders use the cheat sheet ; for scope use the blueprint ; for a mixed attempt use the free practice exam .