Back to Details

generating-flow

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Goal

目标

Generate Salesforce Flow metadata by running the required 3-step MCP pipeline (fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration) and return the flow XML.
通过运行必需的三步MCP流水线（fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration）生成Salesforce Flow元数据，并返回Flow XML。

When to Use This Skill

何时使用此技能

Use this skill when you need to:
  • Create any type of Flow (Screen, Autolaunched, Record-Triggered, Scheduled)
  • Generate Flow metadata XML
  • Automate business processes without code
  • Build user-guided workflows or background automation
  • Troubleshoot deployment errors related to Flows
在以下场景中使用此技能：
  • 创建任意类型的Flow（Screen、Autolaunched、Record-Triggered、Scheduled）
  • 生成Flow元数据XML
  • 无需代码即可自动化业务流程
  • 构建用户引导式工作流或后台自动化流程
  • 排查与Flow相关的部署错误

Specification

规范

Flow Metadata Specification

Flow元数据规范

Overview

概述

Salesforce Flows are powerful automation tools that enable complex business process automation without code. Flows can collect and process data through interactive screens, execute logic and calculations, manipulate records, call external services, and trigger based on various events. Flow types include Screen Flows (user-guided), Autolaunched Flows (background processing), Record-Triggered Flows (database events) and Scheduled Flows (time-based).
Salesforce Flow是强大的自动化工具，无需代码即可实现复杂的业务流程自动化。Flow可以通过交互式界面收集和处理数据、执行逻辑与计算、操作记录、调用外部服务，并可基于多种事件触发。Flow类型包括Screen Flow（用户引导式）、Autolaunched Flow（后台处理）、Record-Triggered Flow（数据库事件触发）和Scheduled Flow（基于时间触发）。

Purpose

用途

  • Automate complex business processes with declarative logic and branching
  • Guide users through multi-step data collection and decision workflows via Screen Flows
  • Perform CRUD operations on Salesforce records automatically
  • Execute background processing and integrations via Autolaunched Flows
  • React to record changes in real-time with Record-Triggered Flows
  • Schedule recurring tasks and batch operations with Scheduled Flows
  • Create reusable, maintainable automation that admins can modify without code
  • 使用声明式逻辑和分支自动化复杂业务流程
  • 通过Screen Flow引导用户完成多步骤数据收集和决策工作流
  • 自动对Salesforce记录执行CRUD操作
  • 通过Autolaunched Flow执行后台处理和集成
  • 使用Record-Triggered Flow实时响应记录变更
  • 通过Scheduled Flow调度重复任务和批处理操作
  • 创建管理员无需代码即可修改的可复用、可维护自动化流程

Flow Generation Pipeline

Flow生成流水线

MANDATORY: You MUST follow this exact 3-step pipeline. No exceptions. No shortcuts. No skipping steps. Do NOT manually create flow metadata XML or attempt to generate flow metadata outside of this pipeline. Do NOT attempt to use any other tool, API, or method to generate flow metadata. This pipeline is the ONLY supported way to generate flows. Any deviation will produce invalid or broken metadata.
强制要求：必须严格遵循此三步流水线，无例外，无捷径，不能跳过任何步骤。不得手动创建Flow元数据XML，也不得尝试通过此流水线以外的方式生成Flow元数据。不得使用任何其他工具、API或方法生成Flow元数据。此流水线是生成Flow的唯一受支持方式，任何偏离都会生成无效或损坏的元数据。

MCP Connection Details

MCP连接详情

All 3 pipeline steps MUST be called using this MCP tool:
  • MCP Tool Name: 
    execute_metadata_action
  • The 
    action
    parameter     selects which pipeline step to run: 
    "fetchGroundedObjectMetadata"
    , 
    "flowElementSelection"
    , or 
    "flowElementGeneration"
Flow generation is a strict 3-step pipeline. ALL steps must be called in order. Every step is required. There is no alternative approach — this is the only way to generate flow metadata:
所有三步流水线必须通过以下MCP工具调用：
  • MCP工具名称： 
    execute_metadata_action
  • action
    参数    用于选择流水线步骤：
    "fetchGroundedObjectMetadata"
    、
    "flowElementSelection"
    或
    "flowElementGeneration"
Flow生成是严格的三步流水线，必须按顺序调用所有步骤，每一步都是必需的。没有替代方案——这是生成Flow元数据的唯一方式：

Step 1 (REQUIRED): Fetch Grounded Object Metadata (
fetchGroundedObjectMetadata
)

步骤1（必需）：获取基础对象元数据（
fetchGroundedObjectMetadata
）

Fetches org schema metadata relevant to the flow generation request. This step is mandatory and must always be called first.
Inputs (all required):
  • userPrompt (STRING, REQUIRED): The user's natural language request
  • inflightMetadata (ARRAY, REQUIRED): Custom objects/fields from local sfdx project. Use empty array 
    []
    if none needed.
Outputs:
  • groundingMetadata (STRING): Grounded object metadata for org schema relevant to the request, returned as a JSON string. You must pass this directly to Step 2 — it is already a string and does not need to be serialized again.
获取与Flow生成请求相关的组织架构元数据。此步骤是强制性的，必须始终首先调用。
输入（均为必填）：
  • userPrompt（字符串，必填）：用户的自然语言请求
  • inflightMetadata（数组，必填）：来自本地sfdx项目的自定义对象/字段。如果不需要，使用空数组
    []
输出：
  • groundingMetadata（字符串）：与请求相关的组织架构基础对象元数据，以JSON字符串形式返回。必须直接将其传递给步骤2——它已经是字符串，无需再次序列化。

Step 2 (REQUIRED): Flow Element Selection (
flowElementSelection
)

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

Selects flow elements (assignments, decisions, record ops, etc.) and their connections based on the user prompt and grounded metadata. This step is mandatory and must be called after Step 1.
Inputs (all required):
  • userPrompt (STRING, REQUIRED): The user's natural language request (must be the same value as Step 1)
  • groundingMetadata (STRING, REQUIRED): Org schema metadata (must be the exact string returned from Step 1 output — pass it directly, do NOT serialize it again)
  • operationId (STRING, REQUIRED): Operation ID (use empty string 
    ""
    for first call)
Outputs:
  • operationId (STRING): Operation ID. You must pass this to Step 3.
  • userOutput (STRING): Reasoning for next steps. You can show this to the user.
根据用户提示和基础元数据选择Flow元素（赋值、决策、记录操作等）及其关联关系。此步骤是强制性的，必须在步骤1之后调用。
输入（均为必填）：
  • userPrompt（字符串，必填）：用户的自然语言请求（必须与步骤1中的值完全相同）
  • groundingMetadata（字符串，必填）：组织架构元数据（必须是步骤1输出的精确字符串——直接传递，不得再次序列化）
  • operationId（字符串，必填）：操作ID（首次调用使用空字符串
    ""
    ）
输出：
  • operationId（字符串）：操作ID。必须将其传递给步骤3。
  • userOutput（字符串）：下一步的推理说明，可展示给用户。

Step 3 (REQUIRED): Flow Element Generation (
flowElementGeneration
)

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

Generates flow metadata element by element. This step is mandatory and must be called after Step 2. Must be called repeatedly in a loop until 
isComplete
is 
true
.
Inputs (all required):
  • operationId (STRING, REQUIRED): Operation ID from Step 2 output
  • requestSource (STRING, REQUIRED): The source of the request. Use 
    "A4V"
     to get flow metadata in XML format.
Outputs:
  • isComplete (BOOLEAN): Indicates if the flow generation is complete. You must check this value.
  • result (STRING): Result of the flow element generation. Contains the final flow metadata only when 
    isComplete
    is 
    true
    .
MANDATORY: Loop until complete. NEVER pause or ask the user to confirm continuation.
  • A flow can have any number of elements (10, 15, or more). Each call generates one element at a time, so you may need many iterations. This is expected and normal.
  • Call 
    flowElementGeneration
    with the 
    operationId
    from Step 2 and 
    requestSource
    (use 
    "A4V"
    for XML output, empty string or other value for JSON).
  • Check the 
    isComplete
    output and the 
    result
    field after each call.
  • If 
    isComplete
    is 
    false
    and no errors are returned, you MUST call 
    flowElementGeneration
    again with the same 
    operationId
     from Step 2. Do NOT ask the user if they want to continue. Do NOT pause. Do NOT summarize progress mid-loop. Just keep calling.
  • Do NOT stop until 
    isComplete
    is 
    true
    or the invocable action returns errors. There is no maximum number of iterations — keep going regardless of how many calls it takes.
  • When 
    isComplete
    is 
    true
    , extract the flow metadata from the 
    result
    field.
  • If errors are returned, stop the loop and surface the error to the user.
STRICT CONSTRAINTS (CRITICAL):
  • DO NOT modify the content, values, or child nodes inside any block.
  • DO NOT add new nodes, tags, attributes, or text (do not add missing labels, X/Y coordinates, etc.).
  • DO NOT remove any existing nodes.
逐个生成Flow元数据元素。此步骤是强制性的，必须在步骤2之后调用。必须循环调用此步骤，直到
isComplete
为
true
。
输入（均为必填）：
  • operationId（字符串，必填）：来自步骤2输出的操作ID
  • requestSource（字符串，必填）：请求来源。使用**
    "A4V"
    **可获取XML格式的Flow元数据。
输出：
  • isComplete（布尔值）：表示Flow生成是否完成。必须检查此值。
  • result（字符串）：Flow元素生成的结果。仅当
    isComplete
    为
    true
    时，才包含最终的Flow元数据。
强制要求：循环调用直至完成，不得暂停或询问用户是否继续。
  • 一个Flow可以包含任意数量的元素（10个、15个或更多）。每次调用生成一个元素，因此可能需要多次迭代。这是预期且正常的情况。
  • 使用步骤2中的
    operationId
    和
    requestSource
    （使用
    "A4V"
    获取XML输出，空字符串或其他值获取JSON）调用
    flowElementGeneration
    。
  • 每次调用后检查
    isComplete
    输出和
    result
    字段。
  • 如果
    isComplete
    为
    false
    且未返回错误，则必须使用步骤2中的**相同
    operationId
    **再次调用
    flowElementGeneration
    。不得询问用户是否继续，不得暂停，不得在循环中途总结进度，只需持续调用。
  • 不得停止，直到
    isComplete
    为
    true
    或可调用操作返回错误。没有最大迭代次数限制——无论需要调用多少次，都要继续执行。
  • 当
    isComplete
    为
    true
    时，从
    result
    字段中提取Flow元数据。
  • 如果返回错误，则停止循环并向用户展示错误信息。
严格约束（至关重要）：
  • 不得修改任何块内的内容、值或子节点。
  • 不得添加新的节点、标签、属性或文本（不得添加缺失的标签、X/Y坐标等）。
  • 不得删除任何现有节点。

inflightMetadata Format

inflightMetadata格式

DATA TYPE: ARRAY (not string)
STRICT NAMING CONVENTION - MUST FOLLOW EXACTLY:
PropertyCorrect NameDo NOT Use
Object API name
apiName
objectApiName
, 
name
, 
objectName
Field API name
apiName
fieldApiName
, 
name
, 
fieldName
Field type
type
fieldType
, 
dataType
Lookup target
referenceTo
relatedTo
, 
lookupTo
, 
reference
When custom objects are needed (sample format showing multiple field data types):
json
[
  {
    "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": []
  }
]
Supported field types: Text, Textarea, Number, Picklist, Lookup, Email, Phone, URL, Date, Datetime, Boolean, Checkbox, Currency, Percent
When no custom objects needed:
json
[]
数据类型：数组（而非字符串）
严格命名约定 - 必须完全遵循：
属性正确名称禁止使用
对象API名称
apiName
objectApiName
, 
name
, 
objectName
字段API名称
apiName
fieldApiName
, 
name
, 
fieldName
字段类型
type
fieldType
, 
dataType
查找目标
referenceTo
relatedTo
, 
lookupTo
, 
reference
当需要自定义对象时（示例格式展示多种字段数据类型）：
json
[
  {
    "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
当不需要自定义对象时：
json
[]

MANDATORY Decision Logic for inflightMetadata (DATA TYPE: ARRAY)

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

  1. REQUIRED - First: Scan the local sfdx project for custom objects and fields that are relevant to the user's flow request.
  2. If relevant custom objects ARE found: You MUST extract and pass them as an array of structured objects (see format above)
  3. If NO relevant custom objects found: You MUST pass an empty array 
    []
    (NOT the string 
    "[]"
    )
  4. NEVER: Pass text descriptions, instructions, or string representations in inflightMetadata
  5. MANDATORY: The data type MUST be ARRAY, not STRING
Instructions for Vibes when custom objects ARE relevant:
  • Extract the object metadata and map to JSON properties: 
    • apiName
      : The object's API name (with 
      __c
      suffix for custom objects)
    • label
      : The object's display label
    • type
      : Set to 
      "CustomObject"
    • fields
      : Array of field objects, each containing: 
      • apiName
        : The field's API name (with 
        __c
        suffix for custom fields)
      • type
        : The field type (Text, Number, Picklist, Lookup, etc.)
      • label
        : The field's display label
      • values
        : (Picklist only) Array of picklist values
      • referenceTo
        : (Lookup only) The target object API name
  • Include only objects and fields that are relevant to the flow being generated
  1. 必需 - 首先：扫描本地sfdx项目，查找与用户Flow请求相关的自定义对象和字段。
  2. 如果找到相关自定义对象：必须将其提取为结构化对象数组（见上述格式）并传递
  3. 如果未找到相关自定义对象：必须传递空数组
    []
    （而非字符串
    "[]"
    ）
  4. 禁止：在inflightMetadata中传递文本描述、说明或字符串表示形式
  5. 必需：数据类型必须是数组，而非字符串
当自定义对象相关时的操作说明：
  • 提取对象元数据并映射到JSON属性： 
    • apiName
      ：对象的API名称（自定义对象需带
      __c
      后缀）
    • label
      ：对象的显示标签
    • type
      ：设置为
      "CustomObject"
    • fields
      ：字段对象数组，每个字段包含： 
      • apiName
        ：字段的API名称（自定义字段需带
        __c
        后缀）
      • type
        ：字段类型（Text、Number、Picklist、Lookup等）
      • label
        ：字段的显示标签
      • values
        ：（仅Picklist类型）Picklist值数组
      • referenceTo
        ：（仅Lookup类型）目标对象的API名称
  • 仅包含与要生成的Flow相关的对象和字段

🎯 Mandatory Enhancement Rules

🎯 强制增强规则

  • userPrompt: REQUIRED.
    • If the user requests a single flow: use the user's prompt as-is.
    • If the user requests multiple flows: you MUST split the request and write a separate, focused 
      userPrompt
      for each individual flow      . Each 
      userPrompt
      must describe only ONE flow. Do NOT pass the entire multi-flow request as a single 
      userPrompt
      . See the multiple flows section below for examples.
  • inflightMetadata: REQUIRED. Always use ARRAY data type.
    • MUST use 
      []
      (empty array) when no custom objects needed
    • MUST use structured array of objects when custom objects are relevant
    • NEVER use string 
      "[]"
      - this is incorrect
    • NEVER use text descriptions - only structured object metadata
  • userPrompt：必填。
    • 如果用户请求单个Flow：直接使用用户的提示内容。
    • 如果用户请求多个Flow：必须拆分请求，为每个单独的Flow编写独立、聚焦的
      userPrompt
      。每个
      userPrompt
      只能描述一个Flow。不得将多Flow请求作为单个
      userPrompt
      传递。请参阅下方多Flow部分的示例。
  • inflightMetadata：必填，始终使用数组数据类型。
    • 当不需要自定义对象时，必须使用
      []
      （空数组）
    • 当自定义对象相关时，必须使用结构化对象数组
    • 禁止使用字符串
      "[]"
      - 必须使用
      []
      （数组）
    • 禁止使用文本描述 - 仅允许结构化对象元数据

MANDATORY: Multiple Flows = Multiple Separate Pipelines

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

FIRST: Before calling any pipeline step, check if the user's request contains multiple flows. If it does, you MUST split it into separate single-flow prompts. Each flow gets its own 3-step pipeline with its own 
userPrompt
that describes ONLY that one flow.
NEVER pass a multi-flow request as a single 
userPrompt
field. NEVER club multiple flow descriptions into one 
userPrompt
.
When the user requests multiple flows (e.g., "Create flows for my app: 1) ... 2) ... 3) ..."), you MUST:
  1. Split the request into separate individual flow descriptions.
  2. Run a separate 3-step pipeline for each flow, using a 
    userPrompt
    that describes ONLY that one flow.
  3. Execute ALL pipelines SEQUENTIALLY — one after another, NEVER in parallel. Do NOT stop after the first flow. Do NOT wait for the user to ask you to continue. Do NOT summarize and stop. Keep going until every requested flow has been fully generated.
WRONG - Multiple flows clubbed into one userPrompt:
json
{
  "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.",
  ...
}
CORRECT - Separate call for EACH flow:
Flow 1 - Step 1 (fetchGroundedObjectMetadata):
json
{
  "userPrompt": "Create a Screen Flow named Tenant_Onboarding that captures tenant details, selects a Unit__c with Status__c = 'Vacant', creates Lease__c...",
  "inflightMetadata": [...]
}
Then call Step 2 (
flowElementSelection
) with the 
groundingMetadata
from Step 1, then Step 3 (
flowElementGeneration
) with the 
operationId
from Step 2.
Flow 2 - Step 1 (fetchGroundedObjectMetadata):
json
{
  "userPrompt": "Create an Autolaunched Flow named Generate_Onboarding_Checklist that given a Lease__c Id input, queries OnboardingTask__c...",
  "inflightMetadata": [...]
}
Then call Step 2 and Step 3 for this flow.
Flow 3 - Step 1 (fetchGroundedObjectMetadata):
json
{
  "userPrompt": "Create a Record-Triggered Flow named Sync_Unit_On_Lease_Changes that on insert and update of Lease__c...",
  "inflightMetadata": [...]
}
Then call Step 2 and Step 3 for this flow.
Mandatory Rules:
  • If there are N flows to generate, there MUST be N separate 3-step pipelines and ALL N pipelines MUST be executed. No exceptions. Do NOT stop after generating only one flow.
  • You MUST fully complete the current flow's 3-step pipeline (including looping Step 3 until 
    isComplete
    is 
    true
    or errors are returned) BEFORE starting the next flow's pipeline.     Do NOT interleave or parallelize pipelines across flows. Everything is SEQUENTIAL — NEVER parallel.
  • After completing a flow's pipeline, immediately start the next flow's pipeline. Do NOT pause, summarize, or wait for user confirmation between flows.
  • For each flow, you MUST scan the local sfdx project to populate 
    inflightMetadata
    with custom objects/fields specific to that flow prompt.
  • Each flow pipeline MUST have its own 
    inflightMetadata
    containing only the objects/fields relevant to that particular flow.
**首先：**在调用任何流水线步骤之前，检查用户的请求是否包含多个Flow。如果是，必须将其拆分为单独的单Flow提示。每个Flow都有自己的三步流水线，且对应的
userPrompt
仅描述该单个Flow。
不得将多Flow请求作为单个
userPrompt
字段传递，不得将多个Flow描述合并到一个
userPrompt
中。
当用户请求多个Flow时（例如：“为我的应用创建Flow：1) ... 2) ... 3) ...”），必须：
  1. 拆分请求，将其拆分为单独的单个Flow描述。
  2. 为每个Flow运行独立的三步流水线，使用仅描述该单个Flow的
    userPrompt
    。
  3. 按顺序执行所有流水线——逐个执行，不得并行。不得在生成第一个Flow后停止，不得等待用户要求继续，不得总结后停止。持续执行，直到所有请求的Flow都完全生成为止。
错误示例 - 多Flow合并到一个userPrompt：
json
{
  "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.",
  ...
}
正确示例 - 为每个Flow单独调用：
Flow 1 - 步骤1（fetchGroundedObjectMetadata）：
json
{
  "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
）。
Flow 2 - 步骤1（fetchGroundedObjectMetadata）：
json
{
  "userPrompt": "Create an Autolaunched Flow named Generate_Onboarding_Checklist that given a Lease__c Id input, queries OnboardingTask__c...",
  "inflightMetadata": [...]
}
然后为此Flow调用步骤2和步骤3。
Flow 3 - 步骤1（fetchGroundedObjectMetadata）：
json
{
  "userPrompt": "Create a Record-Triggered Flow named Sync_Unit_On_Lease_Changes that on insert and update of Lease__c...",
  "inflightMetadata": [...]
}
然后为此Flow调用步骤2和步骤3。
强制规则：
  • 如果需要生成N个Flow，则必须有N个独立的三步流水线，且必须执行所有N个流水线，无例外。不得仅生成一个Flow后停止。
  • **必须完全完成当前Flow的三步流水线（包括循环步骤3直到
    isComplete
    为
    true
    或返回错误），然后再开始下一个Flow的流水线。**不得在Flow之间交错或并行执行流水线。所有操作都是顺序执行的——绝对不能并行。
  • 完成一个Flow的流水线后，立即开始下一个Flow的流水线。不得在Flow之间暂停、总结或等待用户确认。
  • 对于每个Flow，必须扫描本地sfdx项目，以与该Flow提示相关的自定义对象/字段填充
    inflightMetadata
    。
  • 每个Flow流水线必须有自己的
    inflightMetadata
    ，仅包含与该特定Flow相关的对象/字段。

Example Tool Calls

工具调用示例

Example 1: Standard objects only (no custom objects)
Step 1 - fetchGroundedObjectMetadata:
json
{
  "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": []
}
Step 2 - flowElementSelection:
json
{
  "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": ""
}
Step 3 - flowElementGeneration (call in a loop):
json
{
  "operationId": "<operationId from Step 2>",
  "requestSource": "A4V"
}
Call repeatedly with the same 
operationId
until 
isComplete
is 
true
or errors are returned. A flow can have any number of elements, so expect multiple iterations. When 
isComplete
is 
true
, extract the flow metadata from the 
result
field. Use 
"requestSource": "A4V"
to get flow metadata in XML format.
Example 2: With custom objects from local sfdx project
Step 1 - fetchGroundedObjectMetadata:
json
{
  "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": []
    }
  ]
}
Step 2 - flowElementSelection:
json
{
  "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": ""
}
Step 3 - flowElementGeneration (call in a loop):
json
{
  "operationId": "<operationId from Step 2>",
  "requestSource": "A4V"
}
Call repeatedly with the same 
operationId
until 
isComplete
is 
true
or errors are returned. A flow can have any number of elements, so expect multiple iterations. When 
isComplete
is 
true
, extract the flow metadata from the 
result
field. Use 
"requestSource": "A4V"
to get flow metadata in XML format.
示例1：仅使用标准对象（无自定义对象）
步骤1 - fetchGroundedObjectMetadata：
json
{
  "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：
json
{
  "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（循环调用）：
json
{
  "operationId": "<operationId from Step 2>",
  "requestSource": "A4V"
}
使用相同的
operationId
重复调用，直到
isComplete
为
true
或返回错误。一个Flow可以包含任意数量的元素，因此可能需要多次迭代。当
isComplete
为
true
时，从
result
字段中提取Flow元数据。使用
"requestSource": "A4V"
获取XML格式的Flow元数据。
示例2：使用来自本地sfdx项目的自定义对象
步骤1 - fetchGroundedObjectMetadata：
json
{
  "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：
json
{
  "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（循环调用）：
json
{
  "operationId": "<operationId from Step 2>",
  "requestSource": "A4V"
}
使用相同的
operationId
重复调用，直到
isComplete
为
true
或返回错误。一个Flow可以包含任意数量的元素，因此可能需要多次迭代。当
isComplete
为
true
时，从
result
字段中提取Flow元数据。使用
"requestSource": "A4V"
获取XML格式的Flow元数据。

Mandatory Best Practices

强制最佳实践

  • ALWAYS follow the 3-step pipeline: fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration. This is the ONLY way to generate flow metadata. There are no alternatives.
  • Do NOT manually create flow metadata XML, JSON, or any other format outside of this pipeline.
  • Do NOT attempt to "optimize" by skipping steps or combining steps. Each step is atomic and required.
  • NEVER skip any step in the pipeline. All 3 steps are required.
  • NEVER try to generate flow metadata without calling all 3 steps.
  • NEVER deviate from this pipeline under any circumstance — even if you think you know the flow structure.
  • For single flow requests: you MUST use the user prompt as 
    userPrompt
    .
  • For multiple flow requests: you MUST run a separate 3-step pipeline for each flow SEQUENTIALLY (one after another, NEVER in parallel), and you MUST execute ALL of them — do NOT stop after the first flow.
  • You MUST put flow requirements in 
    userPrompt
    , NOT in 
    inflightMetadata
    .
  • inflightMetadata
    is ONLY for custom object/field metadata from local project (see above). No exceptions.
  • Step 3 MUST be called in a loop with the same 
    operationId
    from Step 2 until 
    isComplete
    is 
    true
    or errors are returned. A flow can have any number of elements — do NOT stop early, do NOT pause to ask the user if they want to continue, regardless of how many iterations it takes.
  • You MUST only extract the flow metadata from the 
    result
    field when 
    isComplete
    is 
    true
    .
  • 始终遵循三步流水线：fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration。这是生成Flow元数据的唯一方式，没有替代方案。
  • 不得在此流水线以外手动创建、修改或生成Flow元数据XML、JSON或任何其他格式。
  • 不得通过跳过步骤或合并步骤来“优化”流程。每个步骤都是独立且必需的。
  • 禁止跳过流水线中的任何步骤，所有三步都是必需的。
  • 禁止不调用所有三步就尝试生成Flow元数据。
  • 禁止在任何情况下偏离此流水线——即使你认为自己了解Flow结构。
  • 对于单Flow请求：必须使用用户的提示作为
    userPrompt
    。
  • 对于多Flow请求：必须为每个Flow运行独立的三步流水线，且按顺序执行（逐个执行，不得并行），并且必须执行所有流水线——不得在生成第一个Flow后停止。
  • 必须将Flow需求放入
    userPrompt
    ，不得放入
    inflightMetadata
    。
  • inflightMetadata
    仅用于来自本地项目的自定义对象/字段元数据（见上文），无例外。
  • 步骤3必须使用步骤2中的相同
    operationId
    循环调用，直到
    isComplete
    为
    true
    或返回错误。一个Flow可以包含任意数量的元素——不得提前停止，不得暂停询问用户是否继续，无论需要多少次迭代。
  • 仅当
    isComplete
    为
    true
    时，才能从
    result
    字段中提取Flow元数据。

CRITICAL Verification Checklist (MUST VERIFY BEFORE AND AFTER EVERY FLOW GENERATION)

关键验证清单（每次Flow生成前后必须验证）

Failure to follow this checklist exactly will result in broken or missing flow metadata.
  • Pipeline: ALL 3 steps are called in strict order (fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration). No step is skipped.
  • No manual metadata: Flow metadata is NOT manually created, modified, or generated outside of this pipeline by any means
  • No deviation: No alternative tools, APIs, or methods were used instead of or alongside this pipeline
  • userPrompt contains a single flow prompt. If user requested multiple flows, the request was split and each pipeline received a separate 
    userPrompt
    describing only one flow
  • userPrompt is passed consistently to both Step 1 and Step 2 (same value)
  • inflightMetadata is ARRAY data type (NOT string)
  • inflightMetadata is 
    []
    when no custom objects needed
  • inflightMetadata contains structured objects extracted by scanning the local sfdx project for relevant custom objects/fields
  • inflightMetadata does NOT contain 
    "[]"
    (string) - must be 
    []
    (array)
  • inflightMetadata does NOT contain text descriptions or instructions
  • groundingMetadata from Step 1 output is passed directly to Step 2 input (it is already a string — do NOT serialize it again)
  • operationId from Step 2 output is passed to Step 3 input
  • requestSource should be set to 
    "A4V"
    always
  • Step 3 is called in a loop with the same 
    operationId
    from Step 2 until 
    isComplete
    is 
    true
    or errors are returned — no pausing, no asking the user to continue, no matter how many iterations
  • Multi-flow: Each flow's full pipeline is completed before starting the next flow's pipeline (no interleaving)
  • result field is used to extract the XML flow metadata only when 
    isComplete
    is 
    true
  • No additions to XML: NO elements, attributes, or properties were added that were not present in the original pipeline output. Nothing was inserted (no 
    <label>
    , 
    <description>
    , or any other node). The final XML must be identical to what the pipeline returned.
不严格遵循此清单将导致Flow元数据损坏或缺失。
  • 流水线：所有三步都严格按顺序调用（fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration），未跳过任何步骤。
  • 无手动元数据：未通过任何方式在此流水线以外手动创建、修改或生成Flow元数据
  • 无偏离：未使用任何替代工具、API或方法替代或配合此流水线
  • userPrompt包含单个Flow提示。如果用户请求多个Flow，则已拆分请求，每个流水线都收到仅描述一个Flow的独立
    userPrompt
  • userPrompt一致地传递给步骤1和步骤2（值相同）
  • inflightMetadata是数组数据类型（而非字符串）
  • inflightMetadata在不需要自定义对象时为
    []
  • inflightMetadata包含通过扫描本地sfdx项目提取的相关自定义对象/字段的结构化对象
  • inflightMetadata不包含
    "[]"
    （字符串） - 必须是
    []
    （数组）
  • inflightMetadata不包含文本描述或说明
  • 步骤1输出的
    groundingMetadata
    直接传递给步骤2输入（它已经是字符串——不得再次序列化）
  • 步骤2输出的
    operationId
    传递给步骤3输入
  • requestSource始终设置为
    "A4V"
  • 步骤3使用步骤2中的相同
    operationId
    循环调用，直到
    isComplete
    为
    true
    或返回错误——无论需要多少次迭代，都不得暂停、不得询问用户是否继续
  • 多Flow：每个Flow的完整流水线完成后，才开始下一个Flow的流水线（无交错执行）
  • 仅当
    isComplete
    为
    true
    时，才从
    result
    字段中提取XML Flow元数据
  • 无XML修改：未添加任何流水线输出中不存在的元素、属性或属性，未插入任何内容（无
    <label>
    、
    <description>
    或任何其他节点），最终XML必须与流水线返回的完全一致。",