Scoped Application Development for ServiceNow 介绍如何在 ServiceNow 中构建范围化应用（scoped application），以获得隔离性与可移植性。
一、为何使用范围化应用 资料以对比形式说明：全局范围存在命名冲突隐患、可移植性差、安全较为开放、无法发布到商店、依赖关系隐式；范围化应用则通过 x_ 前缀防止命名冲突，借助 Update Set 实现可移植性，跨范围访问受控，可发布到商店，依赖关系显式声明。
二、创建范围化应用 方式一：通过 Studio（推荐）。步骤为：进入 System Applications > Studio，点击 Create Application，填写 Name（如 "My Custom App"）、Scope（如 "x_mycom_myapp"，自动生成）、Version（如 1.0.0），并在 Runtime access 中勾选需要跨范围访问的表。 方式二：通过 MCP 调用 snow_create_application，传入 name、scope、version、description 参数。
三、范围命名规范 格式为 x_[vendor]_[app]。资料示例：x_acme_hr（ACME Corp HR App）、x_mycom_inventory（My Company Inventory）、x_snc_global（ServiceNow Global）。
四、表命名 范围化表自动加上前缀。Studio 中表名为 "task_tracker"，实际表名为 "x_mycom_myapp_task_tracker"。创建记录使用 GlideRecord 并 initialize、setValue、insert。
五、范围化应用中的 Script Include 资料给出 TaskManager 示例，通过 Class.create() 定义，initialize 中设置表名，createTask 方法插入记录，getTask 方法查询记录。若需被其他范围访问，需将 Accessible from 设为 "All application scopes"。
六、跨范围访问 调用其他范围的 Script Include 有两种方式：一是直接调用（前提是可访问），如 new x_mycom_myapp.TaskManager()；二是使用 GlideScopedEvaluator，通过 putVariable 与 evaluateScript 执行。访问其他范围表时，需先用 GlideRecord 的 isValid() 检查是否有访问权限，无权限则记录错误并返回，有权限则正常查询。
七、应用属性 在 Application > Properties 中定义属性，如 x_mycom_myapp.default_priority，类型为 string，值 3；可在 Application > Modules 中创建 Properties 模块指向 sys_properties_list.do 并带查询参数。读取使用 gs.getProperty，写入使用 gs.setProperty（需管理员权限）。
八、应用文件结构 资料给出目录示例，包含 Tables（x_mycom_myapp_task、x_mycom_myapp_config）、Script Includes（TaskManager、ConfigUtils）、Business Rules（Validate Task）、UI Pages（task_dashboard）、REST API（Task API）、Scheduled Jobs（Daily Cleanup）以及 Application Properties（default_priority、enable_notifications）。
九、范围化应用中的 REST API 以 Scripted REST API 为例，资源路径为 /api/x_mycom_myapp/tasks，方法 GET，使用 GlideRecord 查询活跃任务并组装返回体，包含 result 与 count。调用示例为 curl GET 请求并携带 Authorization: Bearer token 头。
十、应用依赖 在 Application > Dependencies 中声明依赖，如 sn_hr_core、sn_cmdb。代码中可用 GlidePluginManager.isActive 检查插件是否激活，示例为 com.snc.hr.core 与 sn_hr_core.hr_case。
十一、发布到商店 发布前检查清单包括：所有表具备 ACL、无硬编码 sys_id、无硬编码实例 URL、所有依赖已声明、属性有默认值、文档完整、测试通过、无全局范围修改、Update Set 已在干净实例上测试。版本管理采用 Major.Minor.Patch，示例：1.0.0 初始发布、1.1.0 新增功能、1.1.1 缺陷修复、2.0.0 破坏性变更。
十二、常见错误与对策 资料列出若干错误：全局修改导致无法干净部署，对策是保持变更在范围内；硬编码 sys_id 在其他实例失败，对策是使用属性或查找；缺少 ACL 造成安全漏洞，对策是为所有表创建 ACL；缺少错误处理导致静默失败，对策是加入 try/catch 与日志；直接访问全局表引发升级冲突，对策是使用引用而非复制。
十三、最佳实践 包括单一职责（每个业务功能一个应用）、显式依赖（声明全部需求）、属性驱动（无需改代码即可配置）、防御性编码（操作前检查访问权限）、文档（提供 README 与发布说明）、测试（对关键功能做自动化测试）、版本管理（使用语义化版本）。