快速开始:采购审批流程
本教程用一套最小采购申请完成“定义资产 → 构建流程 → 发布 → 运行验证”的闭环。完成后，申请人可以提交采购申请，部门负责人审批，高额采购会继续进入财务审批。
1. 准备工作
开始前确认：
- 当前应用有一个状态为 DEVELOPING 的可编辑版本。
- 已准备 Applicant、Department Manager、Finance Approver 三类测试用户或角色。
- 申请人的部门能够解析出部门负责人。
- 你有流程资产编辑和应用发布权限。
2. 创建字段
进入 Process Designer → Task Configuration → Fields，创建以下自定义字段：
| Label | Field Type | 关键配置 |
|---|---|---|
| Applicant Department | Department | 单选部门 |
| Amount | Number | 可配置货币单位 |
| Category | Select | Hardware、Software、Service |
| Required Date | Date | 日期 |
| Reason | Text Area | 长文本 |
| Attachments | Attachment | 按需要限制数量和类型 |
| Department Review Comment | Text Area | 部门经理填写审核意见 |
| Department Review Result | Select | 选项为 Approved、Rejected；由工作流自动写入 |
| Finance Review Comment | Text Area | 财务审批人填写审核意见 |
| Finance Review Result | Select | 选项为 Approved、Rejected；由工作流自动写入 |
Field Key 在字段保存时由系统自动生成，不需要也不能由用户填写。后续配置流程条件、处理人规则或 TQL 时，应从编辑器提供的字段候选项选择，不要根据 Label 猜测 Key。
标题、状态、创建人、处理人、创建时间等使用系统字段，不要创建同义字段。
Department Review Result 和 Finance Review Result 不设置默认值，也不要求申请人或审批人手工选择。它们的初始值为空，由对应 Approve / Reject 流转的 Post Function 写入。
预期结果： Fields 列表同时显示系统字段和上述十个自定义字段。
3. 创建表单
先理解两类绑定，避免把审核表单误当成 Task Type 的第四种表单：
- Task Type 表单 只有 Create Form、Edit Form 和 View Form 三个位置。
- 流转表单 绑定在 Workflow 的具体流转上，用户点击 Approve 或 Reject 时才打开。
进入 Task Configuration → Forms，创建以下表单资产：
purchaseCreate：Create Form。申请人创建任务时填写标题、部门、金额、类别、需求日期、原因和附件。
purchaseView：View Form。只读展示申请信息、Department Review Result、Department Review Comment、Finance Review Result 和 Finance Review Comment，作为统一任务详情。本案例提交后不开放业务字段编辑，因此 Edit Form 也选择purchaseView；如果业务允许申请人修改未结束的任务，可改为复用purchaseCreate，或单独创建purchaseEdit。managerReview：Department Review 的流转表单。申请信息只读，只允许部门经理填写 Department Review Comment。
financeReview：Finance Review 的流转表单。申请信息只读，只允许财务审批人填写 Finance Review Comment。
此时只创建表单资产，不需要立即绑定 Task Type。完成工作流和权限方案后，再在第 6 节统一建立引用关系。
预期结果： Forms 列表中有 purchaseCreate、purchaseView、managerReview 和 financeReview 四个表单资产。
4. 创建步骤和工作流
在 Task Configuration → Steps 创建：
- Department Review
- Finance Review
Step 是可以被多个 Workflow 引用的业务环节资产，不只是当前流程节点的显示名称。工作流中的 Human Activity 绑定 Step 后，运行任务会记录该 Step 的稳定 stepCode；跨流程报表、TQL、办理时长和 SLA 等统计才能把不同 Workflow 中的同一业务环节聚合在一起。
例如，Purchase Approval 和 Expense Reimbursement 两个流程都需要财务审批时，应让两个流程的财务人工节点共同引用这里创建的 Finance Review Step。这样后续可以跨两个流程统计 Finance Review 的任务量、平均办理时长和 SLA 违约率。不要在两个流程中分别创建仅名称相同的临时节点，否则它们没有共同的 Step 标识，无法作为同一个可复用业务环节可靠统计。
Department Review 同理：如果其他流程也存在同一语义的部门审核环节，应复用这个 Step；如果职责、统计口径或 SLA 定义不同，则应创建独立 Step，避免把不同业务阶段错误合并。
再进入 Task Configuration → Workflows，创建：
- Name：Purchase Approval
- Key：按界面规则填写稳定标识，例如
PURCHASEAPPROVAL；保存后不要仅为修改显示名称而更换 Key - Category：Procurement
- Allow Revoke：按业务需要开启
在画布中配置：
Start → Department Review → Amount Gateway
├─ 低额 → Approved
└─ 高额 → Finance Review → Approved
Department Review / Finance Review 拒绝 → Rejected
上图中的配置分为路由、处理人、表单、校验和结果写入五部分：
- Task Type 绑定
purchaseCreate（Create）和purchaseView（View / Edit）。 - Department Review 的处理人从 Applicant Department 解析部门负责人；Finance Review 的处理人选择 Finance Approver 角色。
- Department Review 通过后进入 Amount Gateway。低额连线配置
Amount < 10000，直接到 Approved；高额连线配置Amount >= 10000，进入 Finance Review。 - 选中 Department Review 的 Approve、Reject 离开连线，在右侧 Transition Form 选择
managerReview。 - 选中 Finance Review 的 Approve、Reject 离开连线，在右侧 Transition Form 选择
financeReview。 - 保持 Show Button 开启，并分别设置清晰的流转名称、确认文案和提示。
- 为审核意见增加必填校验：部门流转校验 Department Review Comment，财务流转校验 Finance Review Comment。
- 为 Department Review 的 Approve 流转添加 Functions → Set Task Field：Field Name 选择 Department Review Result，Field Value 填写
Approved。 - 为 Department Review 的 Reject 流转添加 Functions → Set Task Field：Field Name 选择 Department Review Result，Field Value 填写
Rejected。 - 为 Finance Review 的 Approve / Reject 流转按相同方式设置 Finance Review Result，分别写入
Approved/Rejected。
同一个审核表单可以同时绑定该节点的 Approve 和 Reject 流转。这样处理人无论批准还是拒绝，都会先打开对应流转表单并填写审核意见；校验通过且流转成功后，Set Task Field 再根据实际点击的流转自动写入审核结果。purchaseView 最终以只读方式统一展示意见和结果。
不要把 Result 字段做成审核人可编辑的 Select，也不要只依赖表单按钮修改页面显示。结果必须配置在对应流转的 Functions 中，才能保证保存的字段值与实际执行的 Approve / Reject 路径一致。
配置条件、校验器和 Functions 时，应从编辑器候选项选择字段。不要手工复制字段 Label 或系统生成的 Field Key，以免保存了无法在设计器中正确回显的字段引用。
下图是实际配置的工作流：
预期结果： 保存工作流后没有未连接节点；从 Start 至每个结束节点都有完整路径。
如果本机已经完成 Spark CLI 安装与认证，并安装了 Codex 集成 或 Claude Code 集成，可以直接把流程需求描述给 AI，由 AI 调用 Spark CLI 的语义化命令创建节点、连接路由、绑定 Step 和表单，并配置 Condition、Validator 与 Post Function。
建议在描述中明确目标 App、设计版本、节点、分支条件、处理人、流转表单、校验规则和字段写入规则。例如：
在 spark-sample 当前 DEVELOPING 版本中配置 Purchase Approval：
复用 Department Review 和 Finance Review Step；部门通过后按 Amount 分支，
小于 10000 直接通过，大于等于 10000 进入财务审批；任一审批拒绝则结束为 Rejected。
部门和财务流转分别绑定 managerReview、financeReview，审核意见必填，
Approve / Reject 后分别把对应 Review Result 写为 Approved / Rejected。
写入前先展示目标 App、版本、工作流和完整变更清单，等我确认后执行，最后运行流程检查。
AI 辅助配置不会替代设计评审。确认前应核对目标 App、版本和工作流；修改后仍需在流程设计器中检查图形结构，并在 TEST 环境执行真实用户、权限、组织和分支验证。命令能力和完整示例见 工作流语义化编辑。
5. 创建权限方案
第一次配置权限时，不需要从空白方案逐条创建授权规则。在 Data & Permission → Permissions 中点击 Import System Default，系统会复制一份可编辑的默认权限方案：
导入后进入 Configure 检查授权规则。为便于区分多个任务类型，可以使用 Edit 将方案名称修改为 Purchase Request Permission；本案例截图仍保留导入时的 Default Task Permission 名称。如果已经手工创建了一个空白方案，也可以进入 Configure，在空状态中导入同一套默认规则。
权限方案中的每一行都是一条 Permission Item + Grant Type + 可选 Grant Parameter 授权规则。对于本案例，导入的默认方案已经包含以下关键规则：
| Permission Item | Grant Type | 在采购流程中的作用 |
|---|---|---|
| Create Task | System User | 允许已登录用户创建采购申请 |
| View Task | Task Creator | Applicant 创建任务后，以任务创建人身份查看自己的申请 |
| View Task | Current Assignee | Department Manager 或 Finance Approver 收到待办后查看任务 |
| View Task | Historical Assignee | 已经处理过任务的审批人继续查看该任务 |
| Transition Task | Current Assignee | 只有当前待办处理人可以执行 Approve / Reject 等流转 |
| Revoke Task | Task Creator | Applicant 可以按工作流规则撤回自己创建的申请 |
| Log Work | Current Assignee | 允许当前处理人登记工时；它不控制 Approve / Reject |
这里不需要再为 Finance Approver 配置一条 System Role 的 View 或 Transition Task 权限。Finance Approver 角色用于 Workflow 中 Finance Review 的处理人分配；高额采购进入该节点并完成分配后，实际接收任务的用户就是 Current Assignee，会自动获得上表中的查看和流转权限。直接把 View 授予整个 Finance Approver 系统角色，会让该角色下所有用户都能查看绑定此权限方案的全部采购任务，而不只是高额分支。
如果业务要求 Applicant 在提交后仍能修改任务，可以额外添加 Edit Task + Task Creator；是否真正允许某个状态下编辑，还应同时由工作流状态和可用操作控制。Permission Item、Grant Type 和 Grant Parameter 的实际候选项来自当前系统扩展注册项，请从界面候选项选择。
6. 创建 Task Type
进入 Task Configuration → Task Types，创建：
- Task Type Key：
PURCHASE - Task Type Name：Purchase Request
- Category：Procurement
- Default Workflow：Purchase Approval
- Permission Schema：选择第 5 节确认过的权限方案（截图中为 Default Task Permission）
- Create Form：
purchaseCreate - View Form：
purchaseView - Edit Form：
purchaseView
managerReview 和 financeReview 不在 Task Type 中绑定，它们已经在 Workflow 的具体流转上通过 Transition Form 绑定。
预期结果： Task Type 列表显示 Purchase Request，完整度检查通过，并能看到默认工作流、权限方案和三个表单位置均已绑定。
7. 检查并选择验证环境
返回 Designer Overview，选择当前 DEVELOPING 版本并运行 readiness check，修复未连接节点、缺少处理人、未绑定资产或权限不完整等阻断项。
完成结构检查后，可以根据当前阶段选择验证环境：
- 快速配置和个人调试可以直接打开 DEV 运行环境，验证当前 DEVELOPING 版本。本快速开始采用这种方式，后续截图均来自 DEV 环境。
- 团队联调、正式验收或发布前验证可以查看当前版本与 TEST 已发布版本之间的资产差异，确认后再发布到 TEST。发布到 TEST 是可选步骤，并非完成本快速开始的前置条件。
就绪检查只能发现结构性问题，不能替代真实组织、角色、权限和运行数据验证。需要使用 TEST 时，发布细节见 测试与发布。
8. 在 DEV 运行验证
本节截图来自 DEV 环境。使用准备好的测试用户执行：
- Applicant 创建一条 Amount 小于 10000 的采购申请；Department Manager 审批通过后应直接进入 Approved。
- Applicant 创建一条 Amount 大于等于 10000 的采购申请；部门审批通过后应进入 Finance Review，Finance Approver 审批后进入 Approved。
- 在部门或财务环节再创建一条任务执行 Reject，确认进入 Rejected。
- 分别用 Applicant、Department Manager 和 Finance Approver 检查 My Created、My Pending 和已处理任务，确认只有目标用户能够查看和办理。
- 打开
purchaseView，确认每次 Approve / Reject 后对应的 Review Result 显示Approved/Rejected，审核意见保持为处理人输入的内容。
完成标准： DEV 中可以创建任务，处理人解析正确，两个金额分支和拒绝分支均按预期运行，表单、权限和审核结果可核对。如果选择发布到 TEST，应在 TEST 中重复同一组用例，并核对发布记录。