用 Grist 状态变化自动通知对应负责人

表格里的状态变化常常意味着有人需要接手工作。员工把费用记录改成“已提交审核”之后，如果还要另外找出负责人、复制信息并手动发邮件，同一件事就要做两遍。Grist 的 Automations 可以把数据变化作为触发条件，再发送动态邮件或把记录交给外部服务处理。

本文根据 Grist Help Center《Automations》全文翻译整理。原文未注明个人作者，来源及维护方为 Grist。核对日期为 2026-10-05；页面为未固定版本的在线帮助。本文围绕费用审核邮件展开，保留原文 webhook 替代动作的边界，不扩展为独立的 webhook 队列教程。

谁可以配置自动化

只有文档的 Owner 可以通过左侧导航的 Tools 菜单进入自动化设置。要创建触发器，点击绿色的 Create new trigger，在弹窗中给触发器命名，并选择要监视数据变化的表。

例如，给费用表 Expenses 创建“费用提交审核通知”。命名时写清业务动作和对象，后续查看日志时会更容易识别。一个触发器的配置分为 General、Condition 和 Actions 三部分。

在 General 中，可以调整名称、添加说明，也可以更改触发器检查的表。修改监视表之后，应重新检查条件列、收件人列和模板变量是否仍指向正确字段，不能仅凭旧名称判断配置仍然有效。这是编者补充的配置检查建议。

用条件定义“进入待审核状态”

原文的例子是一张员工费用表：员工提交费用，由经理审核。希望发送通知的时刻，是 Status 变成 Submitted for review。

1. 在 Condition 中为 Status 添加筛选条件，只保留 Submitted for review，取消其他状态。
2. 查看 Raw Data 区域。满足筛选条件的行会被高亮，这有助于核对当前定义的待审核集合。
3. 根据业务需要设置 required columns。这些必填列未填完时，记录不会触发动作。例如可以要求负责人邮件已填，避免记录尚不完整就进入通知流程。
4. 指定何时通知。对于“状态变成待审核”这个场景，选择 A row enters this view：当一行进入由条件定义的视图时触发。

这里“进入视图”由条件是否满足来判断，不是用户打开某个页面。原本不满足条件的记录，修改后同时满足筛选与必填要求，才符合所描述的进入场景。若记录已经在待审核集合中，仅修改一个普通字段，不能把它当然理解成再次进入视图。

除了界面筛选，Grist 也允许用 Python 编写自定义筛选。原文没有给出该部分代码，因此本文不编造一个未经核对的过滤表达式。对于简单状态判断，先使用界面的列筛选，更容易直接比对哪些行被纳入。

编者提醒：实际业务还应检查状态来回切换、补填必填字段和负责人更换是否导致重复或漏发。本文没有对这些行为做产品实测，也不承诺“恰好一次”投递；需要在测试文档中核对实际规则。

把通知交给这一行对应的经理

条件配置好后，点击 + Add Action。原文提供两种动作：Send an email 与 Create a webhook。费用审核使用前者。

选择 Dynamic recipient，并指定费用表中的 Manager Email 列。该列记录每名员工对应经理的邮箱。当费用记录满足触发条件时，收件地址从触发行的这一列读取，因此不同记录可以发给不同负责人。

收件人必须已有该文档的访问权限。 原文在邮件配置前后均强调这一限制。仅仅在单元格里填入一个邮箱，不会自动给该邮箱的用户授权；没有文档访问权的人不会收到这类邮件。排查未发送时，既要检查邮箱值，也要检查对应用户的文档访问权限。

接着填写邮件主题与正文。两者都支持用双花括号包围的变量占位符，正文还支持 Markdown。应从实际表列选择变量并预览解析结果，而不是把界面中的列显示名机械当作可用变量标识。

编者设计邮件内容时建议保留最少、足够的审核信息：这是哪笔费用、由谁提交、需要什么动作，以及回到文档的位置。双花括号模板只是将记录值插入通知内容，并不证明接收端会按某种安全策略转义所有富文本；本次没有审计模板渲染器。对于可由普通协作者编辑的字段，应核对它们是否可能改变邮件中的链接或误导收件人。

同样，Manager Email 应来自受控的负责人映射或经过核验的数据。该列若可被任意改写，就可能把通知交给错误的现有协作者。Grist“只有有访问权的人才收到邮件”的条件很有帮助，但不能替代你对负责人归属和通知字段的检查。

可选动作：把记录 POST 到 webhook

如果后续流程由 Slack、Zapier、Make 或你自己的 API 完成，可以选择 Create a webhook。该动作会把触发行的数据发送到外部 URL。填写 Grist 应发送 POST 请求的端点地址；如果端点要求身份验证，按实际接口要求在 Authorization 字段添加令牌或凭据。原文还说明，也可以在 Document Settings 中单独配置 webhook。

本文不提供真实令牌或可直接发送业务数据的端点。配置这类动作前，应确认目标 URL 是受信任的接收服务，并审阅将离开 Grist 的记录字段；令牌属于秘密，不应放进公开稿件、截图或普通表格字段。使用 HTTPS、限制令牌权限和为外发内容做最小化处理，是编者针对这一步补充的部署建议。本文没有实际调用 webhook，也没有验证端点鉴权或队列行为。

观察投递：总览页面与单触发器监控

Grist 提供两处观察入口。若要检查整个文档的自动化，在 Automations 页面顶部点击 Monitoring：

• Delivery log 显示动作详情。成功、被拒绝的动作以及错误都可以在这里检查。
• Pending 显示排队等待处理的动作。进入队列不等于通知已经送达。

若要检查某一个触发器，可以在该触发器配置页面观察 Action Monitor。修改 Raw Data 中的数据并触发自动化后，该窗口会显示相应动作详情。

Raw Data 不是沙箱。 在这里改一行，就真的改了文档中的记录。即使触发器已经禁用，这些数据修改仍然有效。禁用触发器时，邮件动作会在监视器中显示 BLOCKED - TRIGGER DISABLED，这说明发送动作受到阻止，不表示刚才的数据改动被回滚。

因此，安全的检查方式是在文档副本或专门的测试文档里，使用明确的测试记录和有相应访问权的测试收件人。先观察筛选高亮是否正确，再查看动作生成与日志状态，最后核对实际收件内容。不要为了“试一下触发器”，在真实费用记录上反复切换业务状态。

从一条通知建立可维护的流程

这个例子的关键配置可以归为五个决定：监视 Expenses；筛选 Status = Submitted for review；用必填列确保记录完整；在行进入该集合时触发；从 Manager Email 选择已有文档访问权的负责人。邮件主题和正文解释需要处理的事情，监控页面则帮助区分已投递、被拒绝、发生错误与仍在等待的动作。

交付业务使用前，还应把负责人映射的维护方式和通知失败后的人工处理方式写清楚。这不是原文声称已经完成的步骤，也不是本次已验证的运行效果，而是让该配置能长期使用的编辑补充。

来源与校核说明

原文：Grist Help Center，Automations。原文未提供个人署名及明确发表日期，本文未推定。不依据 Grist 软件的开源许可推定帮助文章的转载权。

本文完整覆盖原文的 General、Condition、邮件动作、webhook 动作和 Monitoring 章节；配图为原创。仅完成正文、界面名称及风险的静态核对，未创建触发器、未修改任何 Grist 文档、未发送邮件、未调用外部端点。原文未提供待执行脚本；静态检查不构成对产品注入防护、权限实现或投递可靠性的安全认证。