动作类型详解

动作·提交条件（Submission Criteria）

提交条件决定一个动作能不能被提交。它把业务规则"焊"进数据编辑权限里， 保证本体数据质量与编辑治理。这一篇讲清它是什么、由什么组成、怎么配置。

全部目录 ← 上一篇 动作·提交条件 下一篇 →
原文 Palantir Foundry · Action types 预计阅读 9 分钟 含 互动演示 + 6 道测验
本文来源 · Source 内容整理自 Palantir Foundry 官方文档：
https://www.palantir.com/docs/foundry/action-types/submission-criteria/
原始标题：Action types · Submission criteria
★

一句话速览

动作·提交条件（Submission Criteria）：提交条件决定一个动作能不能被提交。它把业务规则"焊"进数据编辑权限里，保证本体数据质量与编辑治理。这一篇讲清它是什么、由什么组成、怎么配置。

1 提交条件 = "这条动作现在能不能交"
提交条件（submission criteria）是判断一个动作能否被提交的一组条件
2 条件 + 运算符
条件（condition）是单一的比较检查：在中间用一个运算符，比较两个值
3 比、比什么
运算符定义两个值之间的比较
4 失败消息与测试运行
失败消息（failure message）定义当动作无法提交时，向用户展示什么错误
1

一句话：提交条件 = "这条动作现在能不能交"

Submission criteria（原名 validations）决定动作是否可提交。

提交条件（submission criteria）是判断一个动作能否被提交的一组条件。它把业务规则编码进 数据编辑权限里，从而保证本体（Ontology）的数据质量与编辑治理。

Submission criteria are the conditions that determine whether an action can be submitted. 提交条件是决定一个动作能否被提交的那些条件。

提交条件由条件（conditions）和运算符（operators）组合而成：把"基于上下文的值" （比如当前用户、某个参数）与"静态信息"拼成一条逻辑判断。它可以纳入对象、关系、甚至用户信息来做判断。

两个关键点：① 只有当所有提交条件都满足时，动作才允许提交； ② 提交条件独立于"用户能否编辑这个动作类型本身"的权限——它是提交那一刻的额外校验。 同一个对象类型可以有多个动作类型（增/改/删），每个动作类型有自己独立的提交条件。
2

它由什么组成：条件 + 运算符

一个条件是比较两个值；运算符把多个条件拼起来。

条件（condition）是单一的比较检查：在中间用一个运算符，比较两个值。每个条件要么通过、要么失败。 运算符（operator）则用来把不同的条件组合、嵌套，写出贴近真实业务流程的复杂逻辑。

条件 Condition
一条"值 A 运算符 值 B"的判断。例如：当前用户是否属于某组、某参数值是否等于预期。
运算符 Operator
把多个条件用"全部满足 / 任一满足 / 都不满足"等逻辑组合、甚至嵌套，构成完整规则。

举个航空业的例子：航司想修改某航班（Flight）关联的飞机（Aircraft）。动作本身允许用户改链接， 但航司只希望特定的用户（如飞行调度员）能这么改，并且只允许使用仍在运营状态的飞机。 用提交条件就能把"用户属于某组"和"飞机状态为运营中"这两条绑在一起，缺一不可。

3

三种条件模板：从哪拿要比较的值

Current user / Parameter / Execution context。

条件模板拿什么值来比较典型用途
Current user 当前用户提交动作的人：用户 ID、所属组（group IDs）、MultiPass 属性（如组织）。限制"只有某角色的人能提交"。
Parameter 参数动作参数区里定义的参数（由用户或其他应用传入）。把业务规则嵌进参数，挡掉不合规的数据。
Execution context 执行上下文动作是在什么上下文被评估的，例如是否在某个本体场景（Ontology Scenario）内提交。场景内允许规划者试算，正式环境只允调度者。
Current user 细节：用户 ID 被当作字符串，可与静态 ID 列表或存放 ID 的字符串参数比较。组（group）选项可基于 用户直接或继承的组成员身份判断。MultiPass 属性被当成字符串列表处理。
坑：别对组/标记/组织成员用 NOT。平台支持"作用域令牌（scoped token）"——它只携带用户权限的子集， 可能缺少 NOT 要检查的那条属性，于是条件反而通过、发给了不该有的权限。这是典型的误配置。
支持范围：提交条件不支持附件（attachment）与对象集（object set）参数，这两类会从选择面板里被移除。
4

运算符与取值：怎么比、比什么

运算符会按参数类型预筛；值可以是参数、静态值或"空"。

运算符定义两个值之间的比较。为简化配置，系统会按参数类型预筛只显示合法的运算符；一旦改了参数，用到它的条件都要重配。

单值参数常用运算符

运算符含义
is左值完全等于右值。
is not左值与右值不相等。
matches左值匹配某个正则（如 ^[AEI]）。
is less than / is greater than or equals数值比较（小于 / 大于等于）。

多值参数常用运算符

运算符含义
includes左值中至少有一个等于右值。
includes any左值中至少有一个等于右值列表中的某一个。
is included in左值等于右值列表中的某一个。
each is / each is not左值全部等于 / 全都不等于右值。

值（value）是比较的另一侧：可以基于某个已有参数、一个静态值，或"无值（no value）"—— 后者用来判断第一个值是否为空（null）。在航班例子里：调度员的组用静态值选定（每次都一样）； 飞机"在运营"则要求状态属性等于静态值 Yes。最后用逻辑运算符把多个条件串起来，可嵌套、可要求"全部/任一/都不"。

点我看航班例子的完整配置思路 →
5

失败消息与测试运行

不满足条件时，告诉用户"为什么被拦"。

失败消息（failure message）定义当动作无法提交时，向用户展示什么错误。根层级上的每个条件与逻辑运算符都有自己的失败消息； 底层条件不通过时，显示的是其对应父级的失败消息。

哪都能看到：只要条件不满足，这条消息会在 Foundry 各处（Object Explorer、Workshop、Quiver）对用户显示， 明确告诉他们"为什么被拦下"。

另外，你可以用本体管理器（Ontology Manager）里的测试运行（test run）， 针对一组给定的参数值，验证你的提交条件到底会如何评估。这在正式上线前很有用。

6

动手：该用哪种条件模板？

逐个场景判断。点选项看解析。

一页带走

① 提交条件 = 能否提交
决定动作此刻能不能交；所有条件都满足才放行，独立于编辑权限。
② 组成：条件 + 运算符
条件比较两个值；运算符组合、嵌套多个条件成业务规则。
③ 三模板取值
Current user（谁提交）/ Parameter（带什么参数）/ Execution context（在哪提交）。
④ 消息 + 测试
失败消息说明被拦原因；用 test run 验证条件评估。别对组用 NOT。

延伸阅读 · 相关页面

按主题横向跳转，不必顺着目录一篇篇读。

常见问题速答 · FAQ

关于「动作·提交条件（Submission Criteria）」，读者最常问的几个问题。

提交条件 = "这条动作现在能不能交"是什么？
提交条件（submission criteria）是判断一个动作能否被提交的一组条件。它把业务规则编码进 数据编辑权限里，从而保证本体（Ontology）的数据质量与编辑治理。
它由什么组成：条件 + 运算符？
条件（condition）是单一的比较检查：在中间用一个运算符，比较两个值。每个条件要么通过、要么失败。运算符（operator）则用来把不同的条件组合、嵌套，写出贴近真实业务流程的复杂逻辑。
运算符与取值：怎么比、比什么？
运算符定义两个值之间的比较。为简化配置，系统会按参数类型预筛只显示合法的运算符；一旦改了参数，用到它的条件都要重配。
失败消息与测试运行是什么？
失败消息（failure message）定义当动作无法提交时，向用户展示什么错误。根层级上的每个条件与逻辑运算符都有自己的失败消息；底层条件不通过时，显示的是其对应父级的失败消息。
全部目录 ← 上一篇：参数·性能考量 下一篇：动作·接口 →