automation-flow-generate

目标

通过运行所需的 3 步 MCP 流程（fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration）生成 Salesforce Flow 元数据，并返回 Flow XML。

何时使用此技能

在以下情况下使用此技能：

• 创建任意类型的 Flow（Screen、Autolaunched、Record-Triggered、Scheduled）
• 生成 Flow 元数据 XML
• 无需代码即可自动化业务流程
• 构建由用户引导的工作流或后台自动化
• 排查与 Flow 相关的部署错误

规范

Flow 元数据规范

概述

Salesforce Flow 是功能强大的自动化工具，可在无需代码的情况下实现复杂的业务流程自动化。Flow 可以通过交互式屏幕收集和处理数据、执行逻辑和计算、操作记录、调用外部服务，以及根据各种事件触发。Flow 类型包括 Screen Flow（由用户引导）、Autolaunched Flow（后台处理）、Record-Triggered Flow（数据库事件）和 Scheduled Flow（基于时间）。

Flow 生成流程

强制要求：必须严格遵循以下 3 步流程。不得有任何例外。不得走捷径。不得跳过步骤。切勿手动创建 Flow 元数据 XML，也不要尝试在此流程之外生成 Flow 元数据。切勿尝试使用其他工具、API 或方法生成 Flow 元数据。此流程是生成 Flow 的唯一受支持方式。任何偏离都会导致元数据无效或损坏。

MCP 连接详情

必须使用此 MCP 工具调用全部 3 个流程步骤：

• MCP 工具名称： execute_metadata_action
• action 参数用于选择要运行的流程步骤："fetchGroundedObjectMetadata"、"flowElementSelection" 或 "flowElementGeneration"

Flow 生成采用严格的 3 步流程。必须按顺序调用全部步骤。每个步骤都不可或缺。没有其他可行方法——这是生成 Flow 元数据的唯一方式：

步骤 1（必需）：获取基于实际架构的对象元数据（fetchGroundedObjectMetadata）

获取与 Flow 生成请求相关的组织架构元数据。此步骤必不可少，且必须始终最先调用。

输入（全部必需）：

• userPrompt（STRING，必需）：用户的自然语言请求
• inflightMetadata（ARRAY，必需）：本地 sfdx 项目中的自定义对象/字段。如果无需提供，请使用空数组 []。

输出：

• groundingMetadata（STRING）：与请求相关的组织架构元数据，以 JSON 字符串形式返回。必须将其直接传递给步骤 2——它已经是字符串，无需再次序列化。

步骤 2（必需）：Flow 元素选择（flowElementSelection）

根据用户提示词和基于实际架构的元数据，选择 Flow 元素（赋值、决策、记录操作等）及其连接。此步骤必不可少，且必须在步骤 1 之后调用。

输入（全部必需）：

• userPrompt（STRING，必需）：用户的自然语言请求（必须与步骤 1 中的值相同）
• groundingMetadata（STRING，必需）：组织架构元数据（必须与步骤 1 输出中返回的字符串完全一致——直接传递，不要再次序列化）
• operationId（STRING，必需）：操作 ID（首次调用时使用空字符串 ""）

输出：

• operationId（STRING）：操作 ID。必须将其传递给步骤 3。
• userOutput（STRING）：后续步骤的推理过程。可以向用户展示此内容。

步骤 3（必需）：流程元素生成（flowElementGeneration）

逐个生成流程元数据元素。此步骤必不可少，必须在步骤 2 之后调用。必须循环重复调用，直到 isComplete 为 true。

输入（均为必填）：

• operationId（STRING，必填）：来自步骤 2 输出的操作 ID
• requestSource（STRING，必填）：请求来源。使用 "A4V" 获取 XML 格式的流程元数据。

输出：

• isComplete（BOOLEAN）：指示流程生成是否已完成。必须检查此值。
• result（STRING）：流程元素生成结果。仅当 isComplete 为 true 时才包含最终流程元数据。

强制要求：循环直到完成。绝不要暂停或询问用户是否继续。

• 流程可以包含任意数量的元素。每次调用只生成一个元素，因此可能需要多次迭代。
• 使用步骤 2 中的 operationId 和 requestSource 调用 flowElementGeneration（XML 输出请使用 "A4V"；JSON 输出请使用空字符串或其他值）。
• 每次调用后都检查 isComplete 输出和 result 字段。
• 如果 isComplete 为 false 且未返回错误，则必须再次调用 flowElementGeneration，并使用步骤 2 中的同一个 operationId。不要询问用户是否要继续。不要暂停。不要在循环过程中总结进度。只需持续调用——迭代次数没有上限。
• 当 isComplete 为 true 时，从 result 字段提取流程元数据。
• 如果返回错误，则停止循环并向用户说明错误。

严格限制（重要）——这些规则适用于生成管线返回的 XML：

• 请勿修改任何块内的内容、值或子节点。
• 请勿添加新节点、标签、属性或文本（不要补充缺失的标签、X/Y 坐标等）。
• 请勿删除任何现有节点。

画布模式。 全新的基于画布的流程需要包含一个 <processMetadataValues> 条目，其中 CanvasMode=AUTO_LAYOUT_CANVAS（与 BuilderType 无关），否则流程会以自由布局模式打开。严格限制禁止手动编辑 XML，因此该条目必须由生成管线提供——如果返回的 XML 中缺少此条目，请指出管线存在缺口；不要手动编辑。非画布类型（例如 CustomerLifecycle）不包含此条目——不要将其标记为问题。

inflightMetadata 格式

数据类型：数组（不是字符串）

严格命名约定——必须完全遵循：

属性	正确名称	不要使用
对象 API 名称	apiName	objectApiName、name、objectName
字段 API 名称	apiName	fieldApiName、name、fieldName
字段类型	type	fieldType、dataType
查找目标	referenceTo	relatedTo、lookupTo、reference

需要自定义对象时（展示多种字段数据类型的示例格式）：

[
  {
    "type": "CustomObject",
    "apiName": "CustomerRequest__c",
    "label": "Customer Request",
    "fields": [
      {
        "apiName": "Status__c",
        "type": "Picklist",
        "label": "Status",
        "values": ["New", "In Progress", "Completed"]
      },
      {
        "apiName": "Priority__c",
        "type": "Number",
        "label": "Priority"
      },
      {
        "apiName": "AssignedTo__c",
        "type": "Lookup",
        "label": "Assigned To",
        "referenceTo": "User"
      },
      {
        "apiName": "Description__c",
        "type": "Textarea",
        "label": "Description"
      },
      {
        "apiName": "Email__c",
        "type": "Email",
        "label": "Contact Email"
      },
      {
        "apiName": "DueDate__c",
        "type": "Date",
        "label": "Due Date"
      },
      {
        "apiName": "IsUrgent__c",
        "type": "Boolean",
        "label": "Is Urgent"
      },
      {
        "apiName": "Amount__c",
        "type": "Currency",
        "label": "Amount"
      }
    ],
    "relationships": []
  }
]

支持的字段类型：Text、Textarea、Number、Picklist、Lookup、Email、Phone、URL、Date、Datetime、Boolean、Checkbox、Currency、Percent

不需要自定义对象时：

[]

inflightMetadata 的强制决策逻辑（数据类型：数组）

1. 必需 - 首先：扫描本地 sfdx 项目，查找与用户的工作流请求相关的自定义对象和字段。
2. 如果找到相关的自定义对象：必须将其提取并以结构化对象数组的形式传递（参见上述格式）
3. 如果未找到相关的自定义对象：必须传递空数组 []（不能是字符串 "[]"）
4. 绝对不能：在 inflightMetadata 中传递文本描述、说明或字符串表示形式
5. 强制要求：数据类型必须为数组，不能是字符串

适用于相关自定义对象的 Vibes 说明：

• 提取对象元数据并映射到 JSON 属性：
  • apiName：对象的 API 名称（自定义对象需带 __c 后缀）
  • label：对象的显示标签
  • type：设为 "CustomObject"
  • fields：字段对象数组，每个对象包含：
    • apiName：字段的 API 名称（自定义字段需带 __c 后缀）
    • type：字段类型（Text、Number、Picklist、Lookup 等）
    • label：字段的显示标签
    • values：（仅限 Picklist）选项值数组
    • referenceTo：（仅限 Lookup）目标对象的 API 名称
• 仅包含与正在生成的工作流相关的对象和字段

强制增强规则

• userPrompt：必需。
  • 如果用户请求单个工作流：按原样使用用户的提示词。
  • 如果用户请求多个工作流：必须拆分请求，并为每个工作流单独编写一个聚焦的 userPrompt。每个 userPrompt 只能描述一个工作流。不要将整个多工作流请求作为单个 userPrompt 传递。示例请参阅下文的多个工作流部分。
• inflightMetadata：必需。始终使用数组数据类型。
  • 无需自定义对象时，必须使用 []（空数组）
  • 需要自定义对象时，必须使用结构化对象数组
  • 绝不能使用字符串 "[]"，这是错误的
  • 绝不能使用文本描述，只能使用结构化对象元数据

工作流模式指南

管道会根据 userPrompt 选择工作流元素。提示词含糊会导致管道选择错误的结构，从而生成无法部署的元数据。当请求符合以下某种模式时，必须在传递给 Step 1 和 Step 2 的 userPrompt 中明确说明意图，以便管道选择正确的元素。

计划触发的工作流（“每天”“每周”“每周日”“每周运行一次，晚上 10 点”）

定期按时间触发的工作流属于计划触发工作流。计划配置位于开始元素中：triggerType 为 Scheduled，且 <schedule> 块包含 <frequency>（例如 Weekly）、<startDate> 和 <startTime>。不要期望在 FlowScheduledPath 元素上设置 startDate/startTime——计划触发工作流的运行频率配置位于 <start><schedule>，而非计划路径。

要为计划触发工作流选择记录，请将记录条件放在开始元素的筛选条件中（在 <start> 上设置 <object> 和 <filters>）。这样，工作流会针对每条符合条件的记录运行一次，并将 $Record 绑定到该记录。优先采用此方式，而不是添加一个循环来重新查询并遍历同一个对象——由开始元素筛选记录的计划触发工作流无需使用循环来遍历触发对象的记录。

当提示词包含“每周运行一次／每周日／每天某个时间”时，userPrompt 应说明：计划触发器、触发频率、开始时间，以及触发对象上的记录筛选条件。

“Autolaunched”按字面含义处理

“autolaunched”／“no-trigger”请求会构建一个无触发器工作流（开始元素上没有 triggerType、object 或 <schedule>）——应将“针对每个……／当 X 时”或时间意图放在正文中，而不是触发器中；只有在用户要求时才添加触发器。

统计相关记录（“统计所有相关 X”“X 的数量”）

要存储记录数量，请使用一个单独的赋值元素，设置 <operator>AssignCount</operator>，将集合（记录查询结果）赋给一个 Number 变量。不要为一次计数生成两个赋值元素，也不要让两个赋值元素使用相同的 name——赋值名称重复，或两个赋值执行同一次逻辑计数，都会导致部署失败。一次查询 → 一个 AssignCount 赋值 → 一次记录更新。

不要臆造提示词未要求的操作

只生成提示词要求的元素。如果提示词指定了触发器，但没有指定操作（例如“创建一个在记录创建时触发的流”，却没有说明行为），不要添加 Chatter 帖子、电子邮件或其他未要求的操作。像 chatterPost 这样的未要求操作会生成引用未定义类型的元数据，并导致部署失败。如果确实没有指定要执行的行为，则生成最简有效触发器，不要臆造副作用。

强制要求：多个流 = 多条独立流水线

首先：调用任何流水线步骤之前，检查用户的请求是否包含多个流。如果是，必须将请求拆分为多个仅包含单个流的提示词。每个流都必须使用只描述该流的独立 userPrompt，执行各自的 3 步流水线。

绝不要将包含多个流的请求作为单个 userPrompt 字段传入。绝不要将多个流的描述合并到一个 userPrompt 中。

当用户请求创建多个流时（例如，“为我的应用创建流：1）…… 2）…… 3）……”），必须：

1. 拆分请求，分别描述每个流。
2. 为每个流分别运行一条 3 步流水线，使用只描述该流的 userPrompt。
3. 按顺序执行所有流水线——逐条执行，绝不能并行。不要在第一个流之后停止。不要等用户要求你继续。不要总结后就停止。继续执行，直到所有请求的流都已生成完毕。

错误 - 将多个流合并到一个 userPrompt 中：

{
  "userPrompt": "Create flows for the app: 1) Record-Triggered Flow on ResourceAllocation__c to update Resource__c. 2) Screen Flow to allocate resources. 3) Record-Triggered Flow on Supply__c to auto-flag Low_Stock__c.",
  ...
}

正确 - 为每个流分别调用：

流 1 - 步骤 1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "Create a Screen Flow named Tenant_Onboarding that captures tenant details, selects a Unit__c with Status__c = 'Vacant', creates Lease__c...",
  "inflightMetadata": [...]
}

然后使用步骤 1 中的 groundingMetadata 调用步骤 2（flowElementSelection），再使用步骤 2 中的 operationId 调用步骤 3（flowElementGeneration）。

流 2 - 步骤 1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "Create an Autolaunched Flow named Generate_Onboarding_Checklist that given a Lease__c Id input, queries OnboardingTask__c...",
  "inflightMetadata": [...]
}

然后为此流调用步骤 2 和步骤 3。

流 3 - 步骤 1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "Create a Record-Triggered Flow named Sync_Unit_On_Lease_Changes that on insert and update of Lease__c...",
  "inflightMetadata": [...]
}

然后为此流调用步骤 2 和步骤 3。

强制规则：

• 如果需要生成 N 个流，就必须执行 N 条独立的 3 步流水线，且必须执行全部 N 条流水线。没有例外。不要只生成一个流就停止。
• 必须先完整完成当前流的 3 步流水线（包括循环执行步骤 3，直到 isComplete 为 true 或返回错误），然后才能开始下一个流的流水线。 不要交错执行或并行执行各流的流水线。一切都必须按顺序执行——绝不并行。
• 完成一个流的流水线后，立即开始下一个流的流水线。不要在各流之间暂停、总结或等待用户确认。
• 对于每个流，都必须扫描本地 sfdx 项目，并根据该流的提示词填充 inflightMetadata 中的自定义对象和字段。
• 每条流的流水线都必须有自己的 inflightMetadata，其中只包含与该流相关的对象和字段。

工具调用示例

示例 1：仅使用标准对象（无自定义对象）

步骤 1 - fetchGroundedObjectMetadata：

{
  "userPrompt": "Create a scheduled-triggered Flow named Daily_Good_Morning that runs daily at 6:00 AM and sends an email to the running user saying good morning.",
  "inflightMetadata": []
}

步骤 2 - flowElementSelection：

{
  "userPrompt": "Create a scheduled-triggered Flow named Daily_Good_Morning that runs daily at 6:00 AM and sends an email to the running user saying good morning.",
  "groundingMetadata": "<groundingMetadata string from Step 1 — pass directly, do not serialize again>",
  "operationId": ""
}

步骤 3 - flowElementGeneration（循环调用）：

{
  "operationId": "<operationId from Step 2>",
  "requestSource": "A4V"
}

按照步骤 3 循环调用（使用相同的 operationId，requestSource: "A4V"），直到 isComplete 为 true 或返回错误；然后从 result 中提取 XML。

示例 2：使用本地 sfdx 项目中的自定义对象

步骤 1 - fetchGroundedObjectMetadata：

{
  "userPrompt": "Create a flow that updates the status of a Customer Request when it's assigned",
  "inflightMetadata": [
    {
      "type": "CustomObject",
      "apiName": "CustomerRequest__c",
      "label": "Customer Request",
      "fields": [
        {
          "apiName": "Status__c",
          "type": "Picklist",
          "label": "Status",
          "values": ["New", "In Progress", "Completed"]
        },
        {
          "apiName": "AssignedTo__c",
          "type": "Lookup",
          "label": "Assigned To",
          "referenceTo": "User"
        }
      ],
      "relationships": []
    }
  ]
}

步骤 2 - flowElementSelection：

{
  "userPrompt": "Create a flow that updates the status of a Customer Request when it's assigned",
  "groundingMetadata": "<groundingMetadata string from Step 1 — pass directly, do not serialize again>",
  "operationId": ""
}

步骤 3 - flowElementGeneration（循环调用）：

{
  "operationId": "<operationId from Step 2>",
  "requestSource": "A4V"
}

完全按照示例 1 的步骤 3 循环调用。

关键验证清单（每次生成流程之前和之后都必须验证）

未严格遵循此清单将导致流程元数据损坏或缺失。

• 管道：严格按顺序调用全部 3 个步骤（fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration）。不得跳过、合并任何步骤，也不得用其他工具/API 替代。这条管道是生成流程元数据的唯一方式。
• 不手动创建元数据：不得在管道之外创建、修改或生成流程元数据，也不得向返回的 XML 中添加任何元素/属性（例如 <label>、<description> 或任何其他节点）。最终 XML 必须与管道返回的内容完全一致。**例外：**如果用户明确要求修复已生成 XML 中的验证/部署错误，则允许进行有针对性的手动修改。
• userPrompt 包含单个流程提示词（多流程请求应拆分，每个流程分别使用一个 userPrompt），其中包含流程需求（而非 inflightMetadata），并且在步骤 1 和步骤 2 中传入的内容完全相同。
• inflightMetadata 的数据类型为数组（不得为字符串 "[]"）；无需自定义对象时应为 []，否则应包含从本地 sfdx 项目扫描出的结构化对象/字段元数据，绝不能包含文本描述。
• 将步骤 1 输出中的 groundingMetadata 直接传入步骤 2 的输入（它已经是字符串，不要再次序列化）。
• 步骤 3 必须循环调用，使用步骤 2 返回的相同 operationId，requestSource 始终为 "A4V"，直到 isComplete 为 true 或返回错误为止；不得暂停、不得要求用户继续，无论需要迭代多少次。只有在 isComplete 为 true 时，才从 result 中提取 XML。
• 多流程：必须先按顺序完成每个流程的完整管道，再开始下一个流程（不得并行或交错执行），并且必须生成所有请求的流程——不要在第一个流程后停止。
• 画布模式（只读）：基于画布的新建流程，其 XML 中应包含 <processMetadataValues> 条目，CanvasMode=AUTO_LAYOUT_CANVAS。如果缺少该条目，应指出管道存在缺陷——不得手动编辑（严格约束禁止这样做）。CustomerLifecycle 等非画布类型不包含此条目，不要将其标记为问题。