副作用（Side Effects）总览
动作类型（action types）不只是修改本体（Ontology）里的对象，还能把数据"送出去"，去接入你组织里既有的业务流程。这一篇先建立整体心智模型：副作用是什么、有哪两种、分别解决什么问题。
https://www.palantir.com/docs/foundry/action-types/side-effects-overview/
原始标题：Side effects · Overview
一句话速览
副作用（Side Effects）总览：动作类型（action types）不只是修改本体（Ontology）里的对象，还能把数据"送出去"，去接入你组织里既有的业务流程。
什么是"副作用（side effect）"
当本体成为某个决策流程的"记录系统"时，动作除了改数据，还需要向外通报或联动。
在 Foundry 里，动作类型（action types）的核心职责是：用 规则（rules） 来定义对本体对象的修改（增、删、改）。但一个组织真实的决策流程，往往不止"改个字段"这么简单——你常常需要：
- 在系统里发生变动时，通知（notify）相关的人，让他们能及时响应；
- 当"真相来源"在 Foundry 之外的系统时，去集成（integrate）那个外部系统，这种把决策"编排"出去的模式有时被称为 decision orchestration（决策编排）。
简单说：副作用就是把数据"送出 Foundry"——它不是改本体本身，而是动作执行后顺带发生的、对外部世界的影响。下面这张分层图帮你理解它在本体流程里的位置。
两种副作用类型：通知 vs Webhook
两者都"把数据送出去"，但送的对象和灵活度差别很大。
官方文档明确指出，动作类型的副作用主要有两种：
对象：Foundry 平台内的用户 方式：平台内弹窗 / 邮件 灵活度：可配置"谁、在什么内容下"收到提醒
适合：让人知道"发生了什么"，并附上链接快速跳转处理。
对象：Foundry 之外的系统 方式：发起 HTTP 请求（REST API / ERP） 灵活度：极高，可写回外部源系统
适合：把决策结果真正"写回"外部系统，或接入消息系统做更灵活的提醒。
一句话区分：通知是对"人"说话，Webhook 是对"系统"说话。下两节分别展开它们各自能做什么。后面几篇（notifications / webhooks 及其配置教程）会手把手带你把它们配起来。
通知（notification）能做什么
实时流程里，让人第一时间知道系统里发生了什么变化。
通知允许你灵活地配置：当某个动作被应用时，该如何通知用户。它最典型的用途，是向平台上的用户发送一封邮件或一条平台内提醒。
- 可以指定接收人（recipients）：固定的人/组、动作参数里的用户、对象属性里的用户、甚至用函数动态算出来；
- 可以配置内容（content）：主题、正文、可选链接（指向对象、Workshop 应用、新建对象等）；
- 可以支持邮件的自定义 HTML，做更高级的排版。
通知非常适合实时流程：当系统里"工单被改派""风险被标记"这类事件发生时，立刻让人去响应。
Webhook 能做什么
当"真相来源"在 Foundry 之外时，把决策结果写回外部系统。
Webhook 让你能以极高的灵活度连接 Foundry 之外的系统，包括向一个 REST API 或 ERP 系统发送请求。这意味着你可以：
- 把决策结果写回（write back）到组织里的其他源系统；
- 通过接入消息系统，更灵活地给用户发通知（相比平台内建的通知）。
这就是前面提到的 decision orchestration（决策编排）：本体里做出的决定，顺着 Webhook 流回外部系统，让两套系统保持一致。
何时用哪一个
先判断"接收方是人还是系统"，再决定。
把前两节合起来，决策其实很简单：
选择决策树how to choose
问自己两个问题
- 接收方是人吗？ 是 → 用通知（让人知道并响应）。
- 接收方是 Foundry 之外的系统吗？ 是 → 用 Webhook（把数据/决策写回去）。
- 既要通知人、又要联动系统？ 可以两者都配：用 Webhook 接消息系统发提醒，或用通知 + Webhook 双管齐下。
下一篇我们先深入通知：它能发给谁、内容怎么配、有哪些限制。之后再讲 Webhook 与各自的配置教程，以及定时触发构建。
一页带走
延伸阅读 · 相关页面
按主题横向跳转，不必顺着目录一篇篇读。
常见问题速答 · FAQ
关于「副作用（Side Effects）总览」，读者最常问的几个问题。