ServiceNow CSA common mistakes
ServiceNow CSA · Understand the traps and how to avoid them.
Concludes that a table is protected because its module no longer shows in a non-admin user's Application Navigator, and never tests direct URL access (for example, appending /incident_list.do to the instance URL).
Navigator modules are filtered by the roles a user holds, which feels exactly like access control. In reality hiding a module only changes the menu, while record and field access is enforced by ACLs, and many tables have read ACLs open to any authenticated user.
What to do instead
Treat module visibility as a usability setting and ACLs as the enforcement layer. When testing, impersonate the user, navigate directly to the table list and to a specific record by URL, then inspect the table's read ACLs and any role requirements.
Creates records (users, incidents, demo data) in a development instance, commits an update set, moves it to test or production, and expects those records to appear there too.
The retrieve/preview/commit workflow looks like a full instance migration, so candidates generalize update sets from 'configuration' to 'everything' without checking what is captured.
What to do instead
State the rule out loud until it sticks: update sets transport configuration records (forms, business rules, ACLs, catalog item definitions) forward from dev to test to prod; they do not carry transactional data or records in tables excluded from update capture. Move data with export/import or import sets instead.
Assigns a role to a group, then debugs the role itself or grants the role directly to the user, without first confirming the user is actually a member of that group.
The group-role record looks complete in isolation, and role inheritance through groups is invisible unless you look at the right list; candidates fix the wrong layer because the visible configuration 'looks correct'.
What to do instead
Check the chain in order: membership on the group record, then the effective roles on the user (sys_user_has_role shows group-inherited roles flagged as inherited), then role containment if one role contains another. Only assign directly to a user when group-based inheritance genuinely does not apply.
Runs a data import and transform without setting coalesce on a guaranteed-unique field, then reports duplicate rows in the target table or, conversely, sets coalesce on a loose field such as short description and gets records silently overwritten.
Coalesce is off by default, and the staging rows in the import set look perfectly clean either way, so the damage only shows in the target table after the transform runs.
What to do instead
Decide before the transform whether the import is insert-only or an upsert. For upserts, mark Coalesce on a field that is truly unique (email, employee number, external system ID), then prove it by running the exact same file a second time and confirming the row count holds steady.
Treats a catalog item and a record producer as interchangeable, and is then surprised when one submission creates a request/requested item pair and the other writes a single row straight into a task table.
Both are built on the same item-and-variables machinery in the Service Catalog, so the forms look nearly identical; the only real difference is what gets created on submit, and that is not visible while designing the item.
What to do instead
Memorize the outcome: a catalog item produces a request (sc_request), one or more requested items (sc_req_item), and optional catalog tasks; a record producer generates a single record on its target table with no request. Then submit as a real end user, because visibility and approval routing depend on the requester's roles and manager, which an admin test account usually masks.
Puts internal troubleshooting detail into Additional comments, assuming only the assignment group will read it.
Both fields sit side by side on the activity stream and are edited with the same composer, so to someone who has not learned the distinction they read as two interchangeable note fields.
What to do instead
Work notes are internal and restricted by ACL to internal roles; Additional comments are customer-visible and are typically included in outbound notifications. Before posting, ask who the audience is, and when verifying, check the notification's email body and the field-level ACLs on the record.
Makes a field mandatory or read-only with a UI policy or client script and treats the requirement as secured.
Those controls run in the browser, and the form then behaves correctly in every manual test, so nothing signals that the same record can be written through REST, an import, or a background script where the client logic never executes.
What to do instead
Enforce read/write access with ACLs and value constraints with data policies or a server-side check, keeping UI policies for user experience only. Remember ACLs evaluate with deny taking precedence over allow, so an allow rule will not override a broader deny.
Adds a field to a parent table expecting it to stay out of child tables, or adds a field to a child table and expects a report or query built on the parent to expose it.
Table extension is invisible on the form; a field added to a child looks normal, and it is easy to forget that reports on task-level tables also return rows from every table that extends them.
What to do instead
Draw the hierarchy before designing anything (for example task extending to incident, problem, and change). Put shared fields high on the hierarchy, child-specific fields on the child with reporting against that child, and represent many-to-many links with an intermediate table holding two reference fields rather than two reference fields on one table.
Builds a report on Incident and expects to see Problem or Change data, or builds a report on Task and is confused that unrelated work item types are mixed in.
Both directions look wrong if inheritance is not front of mind: parent-table reports include all children, while child-table reports never include siblings, and the report builder does not announce either behavior.
What to do instead
Choose the table by asking which record types you actually want to see together, then verify the result against a known record count. If mixed types are needed, use Task (or a database view); if one type is needed, report on that child table and do not add conditions on fields that exist only on a sibling.
Personalizes a list (adds or removes columns, saves a filter) and assumes other users now see the same view, or makes list changes expecting them to apply instance-wide.
List edits take effect immediately for the person making them and the list controls carry no obvious 'this is per-user' label, so the change feels like configuration rather than a personal preference.
What to do instead
Know the three layers: a temporary filter in the breadcrumb, a personal list that belongs to one user, and a global list layout that requires admin rights and affects everyone. To change the default for all users, edit the list layout (sys_ui_list) or the module filter, then verify by viewing the list as a different user.