SQL Server触发器不能实现节点跳转，仅能执行原子性状态变更；应只维护status和approval_steps等状态字段，后续流程由应用层监听事件推进，跨系统操作须剥离至Logic Apps等外部服务。
SQL Server 触发器本身不能实现“节点跳转”这种业务层概念——它只响应 INSERT/UPDATE/DELETE 事件，执行原子性状态变更，不负责路由、分支或跨系统调度。
触发器里写 IF…ELSE 判断审批结果并 UPDATE 下一节点？
常见误解是把工作流引擎逻辑塞进触发器：比如在 AFTER UPDATE 中检查 status = 'approved' 就去 UPDATE workflow_nodes SET current = 1 WHERE node_id = 2。这看似“跳转”，实则埋下三类隐患：
- 硬编码节点 ID（如
node_id = 2）导致流程变更时必须改触发器代码，无法动态适配新增/跳过环节 - 多个并发更新可能因事务隔离级别不同，造成同一请求被重复推进到下一节点
- 若跳转需调用外部系统（如发邮件、调 API），触发器会直接报错：
ERROR 1422（MySQL）或 SQL Server 中隐式提交失败
真正该让触发器干的事：只更新状态机字段
触发器唯一安全职责是维护主表的 status 和关联表的原子状态。例如用户提交后，触发器应：
- 插入一条新记录到
approval_steps表，level = 1，status = 'pending' - 将主表
request.status设为'pending_first_approval'（不是'approved_by_mgr'） - 绝不主动查“谁是下一级审批人”或写
next_node_id字段
后续节点推进由应用层监听 approval_steps 变更事件完成——比如轮询服务发现 level=1 AND status='approved'，再查配置表确认 level=2 是否启用，最后插入 level=2 的待审记录。
为什么不能用视图或跳转对象模拟节点流转？
有人尝试用 CREATE VIEW 指向不同节点表来“跳转”，比如 CREATE VIEW current_node AS SELECT * FROM node_1 WHERE active=1。这是无效的：
- 视图只是查询别名，不改变数据流向，也不触发任何逻辑
- SQL Server 不支持运行时切换视图底层表（即所谓“动态跳转”）
- 即便配合触发器修改视图定义（
ALTER VIEW），也会引发缓存失效、权限重校验等副作用，且无法保证事务一致性
跨系统动作必须剥离到应用层或 Logic Apps
如果你需要“审批通过后自动触发 Azure Logic Apps 工作流”，正确路径是：
- 触发器只做：
INSERT INTO approval_steps (request_id, level, status) VALUES (@req_id, 2, 'pending') - 应用服务或独立轮询任务监听
approval_steps表新增status = 'pending'记录 - 该服务调用
HTTP POST到 Logic Apps 的 webhook endpoint，或使用 SQL Server 连接器在 Logic Apps 中轮询该表 - Logic Apps 内部处理通知、超时、重试等，不依赖数据库内任何 I/O 操作
绕过这层解耦，硬要在触发器里调 sp_OACreate 或链接服务器发 HTTP 请求，轻则失败，重则锁死整个事务链路。
