automation-flow-generate

Flow 中繼資料規格

概述

Salesforce Flow 是強大的自動化工具，可實現無需程式碼的複雜商業流程自動化。Flow 可以透過互動式畫面收集和處理資料、執行邏輯和計算、操作記錄、呼叫外部服務，並根據各種事件觸發。Flow 類型包括 Screen Flow（使用者引導）、Autolaunched Flow（背景處理）、Record-Triggered Flow（資料庫事件）和 Scheduled Flow（基於時間）。

目的

使用宣告式邏輯和分支自動化複雜的商業流程
透過 Screen Flow 引導使用者完成多步驟的資料收集和決策工作流程
自動對 Salesforce 記錄執行 CRUD 操作
透過 Autolaunched Flow 執行背景處理和整合
使用 Record-Triggered Flow 即時回應記錄變更
使用 Scheduled Flow 排程重複性任務和批次操作
建立可重複使用、可維護的自動化，管理員無需程式碼即可修改

Flow 產生管線

強制規定：您必須嚴格遵循此 3 步驟管線。沒有例外。沒有捷徑。不可跳過步驟。請勿手動建立 Flow 中繼資料 XML，或嘗試在此管線之外產生 Flow 中繼資料。請勿嘗試使用任何其他工具、API 或方法來產生 Flow 中繼資料。此管線是產生 Flow 的唯一受支援方式。任何偏離都會產生無效或損壞的中繼資料。

MCP 連線詳細資料

所有 3 個管線步驟都必須使用此 MCP 工具呼叫：

MCP 工具名稱： execute_metadata_action
action 參數 選擇要執行的管線步驟："fetchGroundedObjectMetadata"、"flowElementSelection" 或 "flowElementGeneration"

Flow 產生是嚴格的 3 步驟管線。所有步驟都必須依序呼叫。每個步驟都是必需的。沒有替代方法 — 這是產生 Flow 中繼資料的唯一方式：

步驟 1（必要）：取得 Grounded Object Metadata（`fetchGroundedObjectMetadata`）

取得與 Flow 產生要求相關的組織結構描述中繼資料。此步驟強制，且必須始終首先呼叫。

輸入（全部必要）：

userPrompt（字串，必要）：使用者的自然語言要求
inflightMetadata（陣列，必要）：來自本機 sfdx 專案的自訂物件/欄位。如果不需要，請使用空陣列 []。

輸出：

groundingMetadata（字串）：與要求相關的組織結構描述 Grounded Object Metadata，以 JSON 字串回傳。您必須直接將此傳遞給步驟 2 — 它已經是字串，不需要再次序列化。

步驟 2（必要）：Flow 元素選擇（`flowElementSelection`）

根據使用者提示和 grounded metadata 選擇 Flow 元素（指派、決策、記錄操作等）及其連線。此步驟強制，且必須在步驟 1 之後呼叫。

輸入（全部必要）：

userPrompt（字串，必要）：使用者的自然語言要求（必須與步驟 1 的值相同）
groundingMetadata（字串，必要）：組織結構描述中繼資料（必須是步驟 1 輸出的確切字串 — 直接傳遞，不要再次序列化）
operationId（字串，必要）：操作 ID（首次呼叫使用空字串 ""）

輸出：

operationId（字串）：操作 ID。您必須將此傳遞給步驟 3。
userOutput（字串）：後續步驟的推理。您可以向使用者顯示此內容。

步驟 3（必要）：Flow 元素產生（`flowElementGeneration`）

逐個元素產生 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 或 invocable action 回傳錯誤。沒有最大迭代次數 — 無論需要多少次呼叫，都要繼續。
當 isComplete 為 true 時，從 result 欄位中提取 Flow 中繼資料。
如果回傳錯誤，停止迴圈並向使用者顯示錯誤。

嚴格限制（關鍵）— 這些規則適用於產生管線回傳的 XML：

請勿修改任何區塊內的內容、值或子節點。
請勿新增新的節點、標籤、屬性或文字（不要新增缺少的標籤、X/Y 座標等）。
請勿移除任何現有節點。

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 的強制決策邏輯（資料型別：陣列）

必要 — 首先：掃描本機 sfdx 專案，尋找與使用者 Flow 要求相關的自訂物件和欄位。
如果找到相關的自訂物件：您必須提取並以結構化物件陣列傳遞（請參閱上方格式）
如果沒有找到相關的自訂物件：您必須傳遞空陣列 []（不是字串 "[]"）
絕不：在 inflightMetadata 中傳遞文字描述、指示或字串表示
強制：資料型別必須是陣列，不是字串

當自訂物件相關時給 Vibes 的指示：

提取物件中繼資料並對應到 JSON 屬性：
- apiName：物件的 API 名稱（自訂物件需加上 __c 後綴）
- label：物件的顯示標籤
- type：設定為 "CustomObject"
- fields：欄位物件陣列，每個包含：
  - apiName：欄位的 API 名稱（自訂欄位需加上 __c 後綴）
  - type：欄位型別（Text、Number、Picklist、Lookup 等）
  - label：欄位的顯示標籤
  - values：（僅 Picklist）Picklist 值陣列
  - referenceTo：（僅 Lookup）目標物件 API 名稱
僅包含與要產生的 Flow 相關的物件和欄位

強制增強規則

userPrompt：必要。
- 如果使用者要求單一 Flow：直接使用使用者的提示。
- 如果使用者要求多個 Flow：您必須拆分要求，並為每個 Flow 撰寫獨立、聚焦的 userPrompt。每個 userPrompt 必須只描述一個 Flow。請勿將整個多 Flow 要求作為單一 userPrompt 傳遞。請參閱下方多個 Flow 區段的範例。
inflightMetadata：必要。始終使用陣列資料型別。
- 當不需要自訂物件時，必須使用 []（空陣列）
- 當自訂物件相關時，必須使用結構化物件陣列
- 絕不使用字串 "[]" — 這是錯誤的
- 絕不使用文字描述 — 僅使用結構化物件中繼資料

強制：多個 Flow = 多個獨立管線

首先：在呼叫任何管線步驟之前，檢查使用者的要求是否包含多個 Flow。如果是，您必須將其拆分為獨立的單一 Flow 提示。每個 Flow 都有自己的 3 步驟管線，其 userPrompt 僅描述該 Flow。

絕不將多 Flow 要求作為單一 userPrompt 欄位傳遞。絕不將多個 Flow 描述合併到一個 userPrompt 中。

當使用者要求多個 Flow（例如，「為我的應用程式建立 Flow：1) ... 2) ... 3) ...」）時，您必須：

拆分要求為獨立的個別 Flow 描述。
為每個 Flow 執行獨立的 3 步驟管線，使用僅描述該 Flow 的 userPrompt。
依序執行所有管線 — 一個接一個，絕不並行。不要在第一個 Flow 後停止。不要等待使用者要求您繼續。不要總結並停止。持續進行，直到每個要求的 Flow 都已完全產生。

錯誤 — 多個 Flow 合併到一個 userPrompt：

{
  "userPrompt": "為應用程式建立 Flow：1) ResourceAllocation__c 上的 Record-Triggered Flow 以更新 Resource__c。2) 用於分配資源的 Screen Flow。3) Supply__c 上的 Record-Triggered Flow 以自動標記 Low_Stock__c。",
  ...
}

正確 — 為每個 Flow 獨立呼叫：

Flow 1 — 步驟 1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "建立名為 Tenant_Onboarding 的 Screen Flow，擷取租戶詳細資料，選擇 Status__c = 'Vacant' 的 Unit__c，建立 Lease__c...",
  "inflightMetadata": [...]
}

然後使用步驟 1 的 groundingMetadata 呼叫步驟 2（flowElementSelection），然後使用步驟 2 的 operationId 呼叫步驟 3（flowElementGeneration）。

Flow 2 — 步驟 1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "建立名為 Generate_Onboarding_Checklist 的 Autolaunched Flow，給定 Lease__c Id 輸入，查詢 OnboardingTask__c...",
  "inflightMetadata": [...]
}

然後為此 Flow 呼叫步驟 2 和步驟 3。

Flow 3 — 步驟 1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "建立名為 Sync_Unit_On_Lease_Changes 的 Record-Triggered Flow，在插入和更新 Lease__c 時...",
  "inflightMetadata": [...]
}

然後為此 Flow 呼叫步驟 2 和步驟 3。

強制規則：

如果有 N 個 Flow 要產生，則必須有 N 個獨立的 3 步驟管線，且所有 N 個管線都必須執行。沒有例外。不要在只產生一個 Flow 後停止。
您必須在開始下一個 Flow 的管線之前，完全完成目前 Flow 的 3 步驟管線（包括迴圈步驟 3，直到 isComplete 為 true 或回傳錯誤）。 請勿跨 Flow 交錯或並行管線。所有事情都是依序的 — 絕不並行。
完成一個 Flow 的管線後，立即開始下一個 Flow 的管線。不要在 Flow 之間暫停、總結或等待使用者確認。
對於每個 Flow，您必須掃描本機 sfdx 專案，以使用特定於該 Flow 提示的自訂物件/欄位填入 inflightMetadata。
每個 Flow 管線必須有自己的 inflightMetadata，僅包含與該特定 Flow 相關的物件/欄位。

範例工具呼叫

範例 1：僅標準物件（無自訂物件）

步驟 1 — fetchGroundedObjectMetadata：

{
  "userPrompt": "建立名為 Daily_Good_Morning 的 Scheduled Flow，每天上午 6:00 執行，並向執行使用者寄送一封說早安的電子郵件。",
  "inflightMetadata": []
}

步驟 2 — flowElementSelection：

{
  "userPrompt": "建立名為 Daily_Good_Morning 的 Scheduled Flow，每天上午 6:00 執行，並向執行使用者寄送一封說早安的電子郵件。",
  "groundingMetadata": "<來自步驟 1 的 groundingMetadata 字串 — 直接傳遞，不要再次序列化>",
  "operationId": ""
}

步驟 3 — flowElementGeneration（在迴圈中呼叫）：

{
  "operationId": "<來自步驟 2 的 operationId>",
  "requestSource": "A4V"
}

使用相同的 operationId 重複呼叫，直到 isComplete 為 true 或回傳錯誤。Flow 可以有任意數量的元素，因此請預期多次迭代。當 isComplete 為 true 時，從 result 欄位中提取 Flow 中繼資料。使用 "requestSource": "A4V" 以 XML 格式取得 Flow 中繼資料。

範例 2：使用本機 sfdx 專案中的自訂物件

步驟 1 — fetchGroundedObjectMetadata：

{
  "userPrompt": "建立一個 Flow，在 Customer Request 被指派時更新其狀態",
  "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": "建立一個 Flow，在 Customer Request 被指派時更新其狀態",
  "groundingMetadata": "<來自步驟 1 的 groundingMetadata 字串 — 直接傳遞，不要再次序列化>",
  "operationId": ""
}

步驟 3 — flowElementGeneration（在迴圈中呼叫）：

{
  "operationId": "<來自步驟 2 的 operationId>",
  "requestSource": "A4V"
}

強制最佳實務

始終遵循 3 步驟管線：fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration。這是產生 Flow 中繼資料的唯一方式。沒有替代方案。
請勿在此管線之外手動建立 Flow 中繼資料 XML、JSON 或任何其他格式。
當使用者明確要求修正已產生 Flow XML 中的驗證或部署錯誤時，您被允許對 XML 進行有針對性的手動編輯以解決這些錯誤。這是「禁止手動中繼資料」規則的唯一例外。
請勿嘗試透過跳過步驟或合併步驟來「最佳化」。每個步驟都是原子性的且必需的。
絕不跳過管線中的任何步驟。所有 3 個步驟都是必需的。
絕不嘗試在未呼叫所有 3 個步驟的情況下產生 Flow 中繼資料。
絕不在任何情況下偏離此管線 — 即使您認為自己知道 Flow 結構。
對於單一 Flow 要求：您必須使用使用者提示作為 userPrompt。
對於多個 Flow 要求：您必須為每個 Flow 執行獨立的 3 步驟管線依序（一個接一個，絕不並行），且您必須執行所有管線 — 不要在第一個 Flow 後停止。
您必須將 Flow 需求放在 userPrompt 中，而不是 inflightMetadata 中。
inflightMetadata 僅用於來自本機專案的自訂物件/欄位中繼資料（請參閱上方）。沒有例外。
步驟 3 必須使用步驟 2 的相同 operationId 在迴圈中呼叫，直到 isComplete 為 true 或回傳錯誤。Flow 可以有任意數量的元素 — 不要提前停止，不要暫停詢問使用者是否要繼續，無論需要多少次迭代。
您必須僅在 isComplete 為 true 時從 result 欄位中提取 Flow 中繼資料。

關鍵驗證檢查清單（每次 Flow 產生前後都必須驗證）

未能完全遵循此檢查清單將導致 Flow 中繼資料損壞或遺失。

[ ] 管線：所有 3 個步驟都嚴格依序呼叫（fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration）。沒有步驟被跳過。
[ ] 無手動中繼資料：Flow 中繼資料不是在此管線之外以任何方式手動建立、修改或產生的
[ ] 無偏離：沒有使用替代工具、API 或方法代替或與此管線並行
[ ] userPrompt 包含單一 Flow 提示。如果使用者要求多個 Flow，則要求已拆分，且每個管線收到描述僅一個 Flow 的獨立 userPrompt
[ ] userPrompt 一致地傳遞給步驟 1 和步驟 2（相同的值）
[ ] inflightMetadata 是陣列資料型別（不是字串）
[ ] inflightMetadata 在不需要自訂物件時為 []
[ ] inflightMetadata 包含透過掃描本機 sfdx 專案提取的相關自訂物件/欄位的結構化物件
[ ] inflightMetadata 不包含 "[]"（字串）— 必須是 []（陣列）
[ ] inflightMetadata 不包含文字描述或指示
[ ] groundingMetadata 從步驟 1 輸出直接傳遞給步驟 2 輸入（它已經是字串 — 不要再次序列化）
[ ] operationId 從步驟 2 輸出傳遞給步驟 3 輸入
[ ] requestSource 應始終設定為 "A4V"
[ ] 步驟 3 使用步驟 2 的相同 operationId 在迴圈中呼叫，直到 isComplete 為 true 或回傳錯誤 — 無論多少次迭代，都不要暫停、不要詢問使用者是否繼續
[ ] 多個 Flow：每個 Flow 的完整管線在開始下一個 Flow 的管線之前完成（不交錯）
[ ] result 欄位僅在 isComplete 為 true 時用於提取 XML Flow 中繼資料
[ ] 不新增至 XML：未新增原始管線輸出中不存在的元素、屬性或屬性。未插入任何內容（沒有 <label>、<description> 或任何其他節點）。最終 XML 必須與管線回傳的完全相同。
[ ] 錯誤修正例外：如果使用者明確要求修正驗證/部署錯誤，則允許對 XML 進行有針對性的手動編輯，且「不新增至 XML」/「無手動中繼資料」限制不適用於這些編輯。

您可能也喜歡

openhue

386Kproductivity

Control Philips Hue lights and scenes via the OpenHue CLI.

openclaw

獲取

eightctl

384Kproductivity

控制 Eight Sleep 智慧床墊（狀態、溫度、鬧鐘、排程）。

steipete

獲取

office-productivity

46Kproductivity

Office productivity workflow covering document creation, spreadsheet automation, presentation generation, and integration with LibreOffice and Microsoft Office formats.

sickn33

獲取

繼續探索

瀏覽 productivity 熱門 Skills 最近更新

automation-flow-generate

相關技能

目標

何時使用此技能

規格

Flow 中繼資料規格

概述

目的

Flow 產生管線

MCP 連線詳細資料

步驟 1（必要）：取得 Grounded Object Metadata（`fetchGroundedObjectMetadata`）

步驟 2（必要）：Flow 元素選擇（`flowElementSelection`）

步驟 3（必要）：Flow 元素產生（`flowElementGeneration`）

inflightMetadata 格式

inflightMetadata 的強制決策邏輯（資料型別：陣列）

強制增強規則

強制：多個 Flow = 多個獨立管線

範例工具呼叫

強制最佳實務

關鍵驗證檢查清單（每次 Flow 產生前後都必須驗證）

您可能也喜歡

openhue

eightctl

office-productivity

繼續探索

automation-flow-generate

相關技能

目標

何時使用此技能

規格

Flow 中繼資料規格

概述

目的

Flow 產生管線

MCP 連線詳細資料

步驟 1（必要）：取得 Grounded Object Metadata（fetchGroundedObjectMetadata）

步驟 2（必要）：Flow 元素選擇（flowElementSelection）

步驟 3（必要）：Flow 元素產生（flowElementGeneration）

inflightMetadata 格式

inflightMetadata 的強制決策邏輯（資料型別：陣列）

強制增強規則

強制：多個 Flow = 多個獨立管線

範例工具呼叫

強制最佳實務

關鍵驗證檢查清單（每次 Flow 產生前後都必須驗證）

您可能也喜歡

openhue

eightctl

office-productivity

繼續探索

步驟 1（必要）：取得 Grounded Object Metadata（`fetchGroundedObjectMetadata`）

步驟 2（必要）：Flow 元素選擇（`flowElementSelection`）

步驟 3（必要）：Flow 元素產生（`flowElementGeneration`）