ServiceNow Certified System Administrator (CSA)

**搞不清 Tables 和 Database 的关系，尤其是 Table Extension（表继承）** — ServiceNow 的核心数据模型是"表继承"：Incident 继承自 Task，Task 继承自 cmdb_ci 或 sys_metadata。子表自动拥有父表的所有字段（dot-walking 就是靠这个），删除父表记录会级联删除子表记录。考试必考 "Extended table 和 Base table 的字段继承规则"，光背名词没用，必须在 PDI 里建一个继承表实际看一遍。

**ACL 求值顺序背错** — ServiceNow 的 ACL（Access Control List）求值是**先 Table-level 再 Field-level**，而且必须**两级都通过**用户才能访问。很多人记成"Field ACL 优先"是错的。另外 ACL 的 Condition + Script + Role 三个部分是 **AND 关系**——三个都必须返回 true 才给访问。每次考试至少出 4-5 道 ACL 情景题，挂 CSA 的人一大半是挂在这里。

**Business Rules 和 Client Scripts 搞混** — **Business Rule 跑在服务端 (Node.js 改过的 Rhino/GlideScript)**，可以访问数据库、调用 Script Include、在 before/after/async/display 四个时机触发；**Client Script 跑在浏览器**，只能操作表单 DOM，在 onLoad/onChange/onSubmit/onCellEdit 四个时机触发。考试会给你一个需求场景问"应该用哪个"——关键判断依据是"需不需要访问服务端数据"和"需不需要在表单界面上立即反馈"。

**UI Policy 和 Data Policy 区分不清** — **UI Policy 只在界面层生效**——用户通过表单操作时控制字段的可见/必填/只读。**Data Policy 在所有数据操作层生效**——包括 Import Sets 导入、REST API 调用、后台脚本写入时都强制执行。考试经典陷阱题："希望某个字段在所有渠道（包括 API）都必填，应该用哪个？"——答案永远是 Data Policy。

**Update Sets 的迁移流程不熟** — Update Set 是 ServiceNow 里把开发环境的配置改动打包迁移到测试/生产环境的唯一正规方式（类似 Git commit 的概念）。核心流程：Dev instance 开一个 Update Set → 做完所有改动 → Mark Complete → 导出 XML → 在 Test instance 导入 → Preview → Commit。考试必考"Update Set 冲突怎么处理"（选择"Accept Remote Update"或"Skip"）和"哪些东西不会被 Update Set 捕获"（答案：数据记录本身不会，只会捕获配置和代码；数据需要用 Import Sets 或 XML Export/Import）。

**忽视 Import Sets + Transform Maps 的标准流程** — 从 Excel/CSV 把数据导入 ServiceNow 的标准流程是：Import Set Table（暂存原始数据）→ Transform Map（字段映射 + Coalesce 判重 + Transform Script 数据清洗）→ Target Table（最终数据落地）。考试会问"Transform Script 在哪一步执行"以及"Coalesce 字段的作用"（答案：用作判重 key，决定是 Insert 还是 Update）。