Back to Details

make-scenario-building

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Make Scenario Building

Make 场景构建

This skill guides building a scenario in Make. A scenario is an automated workflow composed of modules connected together. Before building anything, Phase 1 below MUST be completed.
本技能指导如何在Make中构建场景。场景是由相互连接的模块组成的自动化工作流。在开始构建之前，必须完成以下第一阶段的内容。

Phase 1: Understand the Business Need & Identify Modules

阶段1：理解业务需求并确定模块

Phase 1 has three steps. Do not skip or rush any of them.
阶段1包含三个步骤，请勿跳过或仓促完成任何一步。

Step 1: Clarify the Business Use Case

步骤1：明确业务用例

The first job is to understand exactly what the user wants to automate. Use an adaptive interview approach:
  1. Start conversational. Ask 1-2 focused questions about what they want to achieve:
    • What task or process do they want to automate?
    • Which systems or services are involved?
  2. Drill deeper based on answers. Once the basics are clear, clarify:
    • What triggers the automation? (time interval, webhook, manual execution)
    • What data moves between systems and in which direction?
    • Are there any conditions, branching logic, or error handling needs?
  3. If answers are vague, get structured. Ask explicitly:
    • "What is the source system and what data are you pulling from it?"
    • "What is the destination system and what should happen there?"
    • "Should this run on a schedule, on-demand, or when an event occurs?"
CRITICAL — Provider disambiguation (MUST follow): When the user mentions a generic category OR describes a capability without naming a specific app, the agent MUST ask which provider/service they use BEFORE proceeding to Step 2. Never assume a provider.
Common ambiguous categories and their possible providers (non-exhaustive — apply the same logic to any category not listed):
  • Forms/surveys: Google Forms, Typeform, JotForm, Tally, Microsoft Forms, SurveyMonkey, ...
  • AI/LLM: OpenAI, Anthropic, Google AI, Make AI, Azure OpenAI, Cohere, ...
  • Email: Gmail, Outlook, SendGrid, Mailchimp, SMTP, ...
  • Calendar: Google Calendar, Outlook Calendar, Calendly, ...
  • Cloud storage: Google Drive, Dropbox, OneDrive, Box, ...
  • CRM: Salesforce, HubSpot, Pipedrive, Zoho CRM, ...
  • Databases: Airtable, Google Sheets, PostgreSQL, MySQL, MongoDB, ...
  • Project management: Jira, Asana, Monday.com, Trello, ClickUp, Linear, ...
  • Messaging/chat: Slack, Discord, Microsoft Teams, Telegram, ...
This also applies when the user describes a capability rather than naming an app. Words like "summarize", "analyze sentiment", "feedback form", "send a notification", or "store data" describe what they want to do — not which service to use. Ask.
Bad: User says "list responses from my feedback form and post a sentiment summary into Discord." Agent assumes Google Forms and OpenAI and proceeds. Good: Same request. Agent asks: "Which form tool holds your responses — Google Forms, Typeform, JotForm, or something else? And for sentiment analysis, do you want to use OpenAI, Anthropic, Make AI, or another AI service?"
Different providers have different modules, capabilities, and connection requirements — guessing wastes time and produces wrong blueprints.
Continue until the use case can be clearly articulated in one paragraph. Every app in the scenario must be explicitly identified by name — if any app is still a generic category or implied by a capability description, ask before proceeding. Do NOT proceed to Step 2 until the business need is fully understood.
首先要准确理解用户想要自动化的内容。采用自适应访谈方法：
  1. 以对话形式开场。提出1-2个聚焦于目标的问题：
    • 他们想要自动化哪些任务或流程？
    • 涉及哪些系统或服务？
  2. 根据回答深入挖掘。在明确基础信息后，进一步确认：
    • 自动化的触发条件是什么？（时间间隔、webhook、手动执行）
    • 数据在系统间如何流转，方向是什么？
    • 是否存在条件判断、分支逻辑或错误处理需求？
  3. 若回答模糊，采用结构化提问。明确询问：
    • "源系统是什么？您要从中提取哪些数据？"
    • "目标系统是什么？在该系统中需要执行什么操作？"
    • 「此自动化应该按计划运行、按需运行，还是在事件发生时运行？"
关键要求——供应商歧义消除（必须遵守）：当用户提及通用类别或描述功能但未指定具体应用时，Agent必须先询问他们使用的供应商/服务，再进入步骤2。切勿假设供应商。
常见歧义类别及可能的供应商（非 exhaustive——对未列出的类别应用相同逻辑）：
  • 表单/调查：Google Forms、Typeform、JotForm、Tally、Microsoft Forms、SurveyMonkey等
  • AI/LLM：OpenAI、Anthropic、Google AI、Make AI、Azure OpenAI、Cohere等
  • 邮件：Gmail、Outlook、SendGrid、Mailchimp、SMTP等
  • 日历：Google Calendar、Outlook Calendar、Calendly等
  • 云存储：Google Drive、Dropbox、OneDrive、Box等
  • CRM：Salesforce、HubSpot、Pipedrive、Zoho CRM等
  • 数据库：Airtable、Google Sheets、PostgreSQL、MySQL、MongoDB等
  • 项目管理：Jira、Asana、Monday.com、Trello、ClickUp、Linear等
  • 消息/聊天：Slack、Discord、Microsoft Teams、Telegram等
这一要求同样适用于用户描述功能而非指定应用的情况。诸如"总结"、"情感分析"、"反馈表单"、"发送通知"或"存储数据"等词汇描述的是要执行的操作，而非使用的服务。此时必须询问用户。
错误示例：用户说"列出我反馈表单的回复，并将情感分析结果发布到Discord"。Agent假设使用Google Forms和OpenAI并继续操作。 正确示例：相同请求下，Agent询问："您的回复存储在哪个表单工具中——Google Forms、Typeform、JotForm还是其他工具？对于情感分析，您希望使用OpenAI、Anthropic、Make AI还是其他AI服务？"
不同供应商的模块、功能和连接要求各不相同——猜测会浪费时间并生成错误的蓝图。
继续沟通，直到可以用一段话清晰描述用例。场景中的每个应用都必须明确指定名称——如果任何应用仍为通用类别或通过功能描述隐含，请在进入步骤2前询问用户。在完全理解业务需求前，切勿进入步骤2。

Step 2: Identify Make Modules

步骤2：确定Make模块

Once the use case is clear, map it to Make modules using the MCP tools available from the Make MCP server:
  1. Find relevant apps. Use the 
    apps_recommend
    tool (or a similarly named tool if unavailable) with a description of the user's need. This returns recommended Make apps for the involved systems.
    • One app per call. Never batch multiple apps in a single 
      apps_recommend
      call. Call separately for each distinct app/service. These calls can run in parallel.
  2. List available modules. For each relevant app, use the 
    app_modules_list
    tool (or similarly named) to see what modules (triggers, actions, searches, transformers) are available. Pass the 
    appVersion
    returned by 
    apps_recommend
    .
  3. Get app documentation. For each app, call 
    app_documentation_get
    using the exact 
    appName
    value returned by 
    apps_recommend
    (do not abbreviate or modify it). This returns detailed capabilities and module descriptions. Call once per app, not per module.
  4. Select modules. Pick the specific modules needed:
    • Trigger module — what starts the scenario (e.g., Watch New Rows, Webhook, Schedule)
    • Action modules — what the scenario does (e.g., Create Record, Send Message, Update Row)
    • Utility modules — if needed for data transformation, iteration, aggregation, routing, or error handling
If a tool is not found by exact name, search for similarly named tools on the Make MCP server. The key capability needed is: recommending apps and listing their modules.
Module name verification: Never guess module names. Always verify via 
app_modules_list
. Case and spelling must match exactly.
No scheduler module: There is no scheduler module in Make. Scheduling is a scenario-level setting, not a module. The scenario always starts with the first module (trigger or action). Scheduling is configured separately via the 
scenario_scheduling_update
tool.
IMPORTANT: As modules are identified, record the following details from the tool responses — they are needed in subsequent phases:
  • App name (exact name as returned by the tool)
  • App version (exact version as returned by the tool)
  • Module name (exact technical name/slug of each module you plan to use)
明确用例后，使用Make MCP服务器提供的MCP工具将其映射到Make模块：
  1. 查找相关应用。使用
    apps_recommend
    工具（若不可用则使用名称类似的工具），传入用户需求描述。该工具会返回与涉及系统对应的推荐Make应用。
    • 每次调用仅针对一个应用。切勿在单次
      apps_recommend
      调用中批量处理多个应用。针对每个不同的应用/服务单独调用，这些调用可以并行执行。
  2. 列出可用模块。对于每个相关应用，使用
    app_modules_list
    工具（或名称类似的工具）查看可用的模块（触发器、操作、搜索、转换器）。传入
    apps_recommend
    返回的
    appVersion
    。
  3. 获取应用文档。对于每个应用，使用
    apps_recommend
    返回的准确
    appName
    调用
    app_documentation_get
    （请勿缩写或修改）。该工具会返回详细的功能和模块描述。每个应用调用一次，而非每个模块调用一次。
  4. 选择模块。挑选所需的特定模块：
    • 触发模块——启动场景的条件（例如：Watch New Rows、Webhook、Schedule）
    • 操作模块——场景要执行的操作（例如：Create Record、Send Message、Update Row）
    • 实用模块——如需进行数据转换、迭代、聚合、路由或错误处理则使用
若未找到名称完全匹配的工具，请在Make MCP服务器上搜索名称类似的工具。核心需求是：推荐应用并列出其模块。
模块名称验证：切勿猜测模块名称。始终通过
app_modules_list
验证。大小写和拼写必须完全匹配。
无调度模块：Make中没有调度模块。调度是场景级别的设置，而非模块。场景始终从第一个模块（触发器或操作）开始。调度通过
scenario_scheduling_update
工具单独配置。
重要提示：在确定模块时，记录工具返回的以下详细信息——后续阶段需要这些信息：
  • 应用名称（工具返回的准确名称）
  • 应用版本（工具返回的准确版本）
  • 模块名称（计划使用的每个模块的准确技术名称/别名）

Step 2.5: Look Up Reference Templates

步骤2.5：查找参考模板

Once apps and modules are identified, search the Make public template library for similar scenarios. Studying an existing template's blueprint reveals canonical module versions, mapper shapes, and aggregator/feeder bindings that aren't visible from 
app-module_get
alone.
Recommended whenever the planned flow includes:
  • An aggregator (
    util:TextAggregator
    , 
    builtin:BasicAggregator
    , etc.)
  • A Make AI Tools module or any AI provider module
  • An app you haven't configured earlier in this session
  • Multi-module composition (more than 2-3 modules, branching, iteration)
Skip allowed for single-module trigger → single-action flows with well-known apps and no aggregation/AI.
How:
  1. public-templates_list
    with 
    name: <use-case keywords>
    and 
    usedApps: <app slugs from Step 2>
  2. If matches found, pick the highest-
    usage
    one with the most app overlap
  3. public-templates_get-blueprint
    to fetch the full structure
  4. Use as STRUCTURAL reference — NOT as the literal blueprint to copy. Templates often implement a slightly different pattern (e.g., per-item loop vs digest-style aggregation). Note diffs and present them to the user in Step 3.
If 
public-templates_get*
returns "Organization-bound request can't be used outside of the Organization Context", retry once; if it persists, reconnect the Make MCP server (
/mcp
reauth) and retry. If still failing, proceed without — the template is a nice-to-have reference, not a requirement.
See Templates Lookup for search patterns, blueprint-diffing tips, and MCP workarounds.
确定应用和模块后，在Make公共模板库中搜索类似场景。研究现有模板的蓝图可以发现规范的模块版本、映射器结构以及聚合器/馈线绑定，这些信息无法仅通过
app-module_get
获取。
建议在以下情况使用：
  • 计划的流程包含聚合器（
    util:TextAggregator
    、
    builtin:BasicAggregator
    等）
  • 包含Make AI Tools模块或任何AI供应商模块
  • 包含您在本次会话中尚未配置过的应用
  • 多模块组合（超过2-3个模块、分支、迭代）
可跳过的情况：单模块触发器→单操作流程，涉及知名应用且无聚合/AI功能。
操作方法：
  1. 使用
    public-templates_list
    ，参数为
    name: <用例关键词>
    和
    usedApps: <步骤2中的应用别名>
  2. 若找到匹配项，选择
    usage
    最高且应用重叠最多的模板
  3. 使用
    public-templates_get-blueprint
    获取完整结构
  4. 将其作为结构参考——而非直接复制的字面蓝图。模板通常实现略有不同的模式（例如：逐项循环vs摘要式聚合）。记录差异并在步骤3中向用户展示。
若
public-templates_get*
返回"Organization-bound request can't be used outside of the Organization Context"，重试一次；若仍失败，重新连接Make MCP服务器（
/mcp
重新授权）并再次重试。若依旧失败，则无需模板继续操作——模板是可选参考，非必需项。
有关搜索模式、蓝图差异对比技巧和MCP解决方法，请参阅模板查找。

Step 3: Present the Module Composition & Get Confirmation

步骤3：展示模块组合并获取确认

Present the proposed module sequence to the user using flowchart notation:
Linear flow:
Trigger: Google Sheets - Watch New Rows → Slack - Send Message → Google Drive - Upload File
Branching flow (with If-Else + Merge) — mutually exclusive branches that converge:
Trigger: Webhook → HTTP - Make a Request → If-Else
  ├─ If (status = "success"): Slack - Send Message
  └─ Else: Email - Send Error
→ Merge → Google Sheets - Log Result
Branching flow (with Router) — multiple branches can fire, no convergence:
Trigger: Webhook → HTTP - Make a Request → Router
  ├─ Route A (status = success): Slack - Send Message
  └─ Route B (priority = high): Email - Send Alert
Flow with iteration:
Trigger: Schedule → Google Sheets - Search Rows → Iterator → Slack - Send Message (for each row)
For each module in the sequence, briefly note:
  • The app and module name
  • What it does in this scenario (1 sentence)
Then ask the user: "Does this module composition achieve what you need? Should I adjust any steps?"
Do NOT proceed beyond Phase 1 until the user confirms the composition is correct. The literal scenario layout and module configuration will be handled in subsequent phases.
使用流程图符号向用户展示提议的模块序列：
线性流程：
Trigger: Google Sheets - Watch New Rows → Slack - Send Message → Google Drive - Upload File
分支流程（含If-Else + Merge）——互斥分支汇合：
Trigger: Webhook → HTTP - Make a Request → If-Else
  ├─ If (status = "success"): Slack - Send Message
  └─ Else: Email - Send Error
→ Merge → Google Sheets - Log Result
分支流程（含Router）——多个分支可触发，无需汇合：
Trigger: Webhook → HTTP - Make a Request → Router
  ├─ Route A (status = success): Slack - Send Message
  └─ Route B (priority = high): Email - Send Alert
含迭代的流程：
Trigger: Schedule → Google Sheets - Search Rows → Iterator → Slack - Send Message (for each row)
对于序列中的每个模块，简要说明：
  • 应用和模块名称
  • 该模块在本场景中的作用（1句话）
然后询问用户："此模块组合是否满足您的需求？是否需要调整任何步骤？"
在用户确认组合正确前，切勿进入阶段1之后的内容。场景的实际布局和模块配置将在后续阶段处理。

Phase 1 Output

阶段1输出

Once the user confirms, produce a Scenario Plan summary to carry into subsequent phases. This is the working reference — do not lose it.
undefined
用户确认后，生成场景计划摘要，用于后续阶段。这是工作参考文档——请勿丢失。
undefined

Scenario Plan

场景计划

Use case: <one paragraph summary> Trigger type: <schedule | webhook | manual | event-based>
用例：<一段话摘要> 触发类型：<schedule | webhook | manual | event-based>

Modules

模块

#AppApp VersionModule (slug)Module LabelRole in scenario
1...............
2...............
#应用应用版本模块（别名）模块标签在场景中的角色
1...............
2...............

Flow

流程

<flowchart notation from Step 3>

This table is the source of truth for which apps and modules will be used. Subsequent phases will reference it directly.

**CRITICAL — Plan adherence:** Once the user confirms the Scenario Plan, treat it as a binding contract. If during Phase 2 a reason emerges to change the module composition, flow structure, or branching pattern (e.g., switching from If-Else + Merge to Router, adding or removing modules, changing the trigger type), STOP and present the proposed change to the user with a clear explanation of why, along with an updated plan summary highlighting what has changed. Do NOT silently deviate from the confirmed plan.

---
<步骤3中的流程图符号>

该表格是将使用的应用和模块的权威来源。后续阶段将直接参考此表格。

**关键要求——遵守计划**：用户确认场景计划后，将其视为具有约束力的约定。若在阶段2中出现需要更改模块组合、流程结构或分支模式的情况（例如：从If-Else + Merge切换为Router、添加或删除模块、更改触发类型），**立即停止**并向用户展示提议的更改，清晰说明原因，并提供突出显示更改内容的更新计划摘要。切勿擅自偏离已确认的计划。

---

Phase 2: Configure, Deploy & Verify

阶段2：配置、部署与验证

Once the user confirms the module composition from Phase 1, proceed through these steps:
用户确认阶段1的模块组合后，执行以下步骤：

Step 1: Secure Connections (REQUIRED — never auto-select)

步骤1：安全连接（必填——切勿自动选择）

CRITICAL — STOP and ask before proceeding. This is an interactive checkpoint. For EVERY app that needs a connection — even if only one matching connection exists — list the options and ask the user which connection to use. Do NOT auto-select a connection. Do NOT call any module-specific RPCs (
rpc_execute
for spreadsheet lists, channel lists, folder lists, etc.) until the user has explicitly confirmed a connection for every app. This is a hard gate: no confirmation, no RPCs.
  1. Extract connection requirements. Before checking connections, call 
    extract_blueprint_components
    with the unconfigured blueprint (all modules placed, parameters empty). This returns the authoritative list of: which modules need connections, the connection type for each, and the required OAuth scopes. Use this output — not manual inspection of the Scenario Plan — as the definitive checklist. Builtin modules (
    builtin:BasicRouter
    , 
    builtin:BasicFeeder
    , 
    json:ParseJSON
    , etc.) do NOT need connections. AI agent modules (
    ai-local-agent:RunLocalAIAgent
    ) are NOT builtin — they require an AI provider connection via 
    makeConnectionId
    .
  2. Check existing connections (with scope verification). Call 
    connections_list
    with the target 
    teamId
    . List all connections without a type filter first, then match by 
    accountName
    in the results — the 
    type
    filter matches 
    accountName
    , NOT the Make app name (e.g., Google Sheets uses 
    "google"
    , Gmail uses 
    "google-email"
    , Slack uses 
    "slack2"
    or 
    "slack3"
    ).
    Scope verification (CRITICAL for OAuth connections): For each matching connection, compare its scopes against the required scopes from 
    extract_blueprint_components
    . A connection that authenticates successfully but lacks a required scope will cause 403/permission errors at runtime. If a matching connection exists but its scopes are insufficient, do NOT attempt to use it — either expand its scopes (see 
    make-module-configuring
    skill, connections reference, Step 3a) or create a new connection with the correct scopes.
  3. Ask the user to pick. For each app, present a numbered list and WAIT for the user's reply:
    • If matching connections exist (even just one), list ALL of them with name, ID, metadata (email, workspace), and scope status (sufficient / insufficient). Always include "Create a new connection" as the last option: 
      I found these existing Google connections:
1. "Google - Marketing" (ID: 12345, email: marketing@acme.com) — scopes: sufficient
2. "Google - Personal" (ID: 12346, email: me@gmail.com) — scopes: insufficient (missing Google Drive file access)
3. Create a new connection

Which one should I use for Google Sheets?
      Even if there is only one match, still ask. Connections with insufficient scopes should be listed but flagged — offer scope expansion or new connection creation for those.
    • If no matching connection exists, inform the user and create a credential request via 
      credential_requests_create
      , including the required scopes from 
      extract_blueprint_components
      .
  4. Confirm all connections are ready. Do NOT proceed to Step 2 until every required connection has a user-confirmed connection ID.
关键要求——停止操作并询问用户。这是一个交互式检查点。对于每个需要连接的应用——即使只有一个匹配的连接——列出所有选项并询问用户使用哪个连接。切勿自动选择连接。在用户明确确认每个应用的连接前，切勿调用任何模块特定的RPC（用于电子表格列表、频道列表、文件夹列表等的
rpc_execute
）。这是硬性要求：未确认连接，禁止调用RPC。
  1. 提取连接要求。在检查连接前，使用未配置的蓝图（所有模块已放置，参数为空）调用
    extract_blueprint_components
    。该工具会返回权威列表：哪些模块需要连接、每个模块的连接类型以及所需的OAuth权限范围。使用此输出——而非手动检查场景计划——作为最终检查清单。内置模块（
    builtin:BasicRouter
    、
    builtin:BasicFeeder
    、
    json:ParseJSON
    等）无需连接。AI Agent模块（
    ai-local-agent:RunLocalAIAgent
    ）不属于内置模块——它们需要通过
    makeConnectionId
    连接AI供应商。
  2. 检查现有连接（含权限范围验证）。使用目标
    teamId
    调用
    connections_list
    。先列出所有无类型筛选的连接，然后根据结果中的
    accountName
    匹配——
    type
    筛选匹配的是
    accountName
    ，而非Make应用名称（例如：Google Sheets使用
    "google"
    ，Gmail使用
    "google-email"
    ，Slack使用
    "slack2"
    或
    "slack3"
    ）。
    权限范围验证（OAuth连接必填）：对于每个匹配的连接，将其权限范围与
    extract_blueprint_components
    返回的所需权限范围进行对比。成功认证但缺少所需权限范围的连接会在运行时导致403/权限错误。若存在匹配的连接但权限范围不足，切勿尝试使用——要么扩展其权限范围（参阅make-module-configuring技能的连接参考步骤3a），要么创建具有正确权限范围的新连接。
  3. 请用户选择。对于每个应用，提供编号列表并等待用户回复：
    • 若存在匹配连接（即使只有一个），列出所有连接的名称、ID、元数据（邮箱、工作区）以及权限范围状态（充足/不足）。始终将"创建新连接"作为最后一个选项： 
      我找到以下现有Google连接：
1. "Google - Marketing"（ID: 12345，邮箱：marketing@acme.com）——权限范围：充足
2. "Google - Personal"（ID: 12346，邮箱：me@gmail.com）——权限范围：不足（缺少Google Drive文件访问权限）
3. 创建新连接

您要为Google Sheets使用哪个连接？
      即使只有一个匹配项，也必须询问。权限范围不足的连接应列出并标记——为这些连接提供扩展权限范围或创建新连接的选项。
    • 若无匹配连接，告知用户并通过
      credential_requests_create
      创建凭证请求，包含
      extract_blueprint_components
      返回的所需权限范围。
  4. 确认所有连接已准备就绪。在每个所需连接都获得用户确认的连接ID前，切勿进入步骤2。

Step 2: Configure Each Module

步骤2：配置每个模块

Configure modules left to right (upstream to downstream) following the 
make-module-configuring
skill:
  1. Read the module interface (
    app-module_get
    with instructions format)
  2. Load dynamic field options via RPCs (now that connections are confirmed)
  3. Fill parameters and mapper
  4. Validate each module individually (
    validate_module_configuration
    )
按照
make-module-configuring
技能从左到右（上游到下游）配置模块：
  1. 读取模块接口（使用指令格式调用
    app-module_get
    ）
  2. 通过RPC加载动态字段选项（现在已确认连接）
  3. 填写参数和映射器
  4. 单独验证每个模块（
    validate_module_configuration
    ）

Step 3: Validate the Blueprint

步骤3：验证蓝图

Call 
validate_blueprint_schema
on the complete blueprint JSON to catch structural issues before submission.
对完整的蓝图JSON调用
validate_blueprint_schema
，在提交前发现结构问题。

Step 4: Create the Scenario

步骤4：创建场景

Call 
scenarios_create
with the validated blueprint. The blueprint must include a top-level 
metadata
object — see Blueprint Construction — Deployment Checklist for the required structure.
Scheduling type for webhook/instant trigger scenarios: When the first module is a webhook or instant trigger (
listener: true
), always use 
{"type": "immediately"}
as the scheduling type when calling 
scenario_scheduling_update
. Never use 
"indefinitely"
for webhook scenarios — it causes scenario activation to fail with "Invalid interval." Scheduled (polling) scenarios should use 
"indefinitely"
with an interval; webhook scenarios must use 
"immediately"
.
使用验证后的蓝图调用
scenarios_create
。蓝图必须包含顶层
metadata
对象——有关所需结构，请参阅蓝图构建——部署清单。
Webhook/即时触发场景的调度类型：当第一个模块是webhook或即时触发器（
listener: true
）时，调用
scenario_scheduling_update
时始终使用
{"type": "immediately"}
作为调度类型。切勿对webhook场景使用
"indefinitely"
——这会导致场景激活失败，提示"Invalid interval"。计划（轮询）场景应使用
"indefinitely"
并设置间隔；webhook场景必须使用
"immediately"
。

Step 5: Activate the Scenario

步骤5：激活场景

Newly created scenarios are inactive by default. Call 
scenarios_activate
before attempting to run. Skipping this step causes 
scenarios_run
to fail.
新创建的场景默认处于未激活状态。在尝试运行前调用
scenarios_activate
。跳过此步骤会导致
scenarios_run
失败。

Step 6: Run & Verify

步骤6：运行与验证

Run the scenario and confirm it succeeds before handing off to the user.
  1. Execute. Call 
    scenarios_run
    to trigger an immediate run.
  2. Check the result. Call 
    executions_list
    for the scenario, then 
    executions_get
    on the most recent execution. Inspect the 
    status
    field:
    • 1
      = success — proceed to Step 7.
    • 3
      = error — continue to step 3.
  3. Diagnose the failure. Read 
    error.message
    and 
    error.causeModule
    from the execution result. Common runtime issues that pass schema validation:
    • Mapped fields resolving to 
      undefined
      or 
      null
      at runtime (e.g., 
      {{2.mimeType}}
      when the upstream module produced no output for that field)
    • Type conversion errors on optional parameters left at defaults
    • Missing or expired connection tokens
  4. Fix and retry. To update the scenario after diagnosis:
    • Call 
      scenarios_deactivate
      on the scenario
    • Call 
      scenarios_update
      with the corrected blueprint
    • Call 
      scenarios_activate
      to re-enable
    • Call 
      scenarios_run
      again and repeat from step 2
Repeat the diagnose-fix-retry cycle until the execution succeeds or the issue requires user intervention (e.g., missing input data, external service unavailable). If user action is needed, explain the error and what to do before retrying.
运行场景并确认成功后再交付给用户。
  1. 执行。调用
    scenarios_run
    触发立即运行。
  2. 检查结果。调用
    executions_list
    获取场景执行记录，然后对最新的执行记录调用
    executions_get
    。检查
    status
    字段：
    • 1
      = 成功——进入步骤7。
    • 3
      = 错误——继续步骤3。
  3. 诊断失败原因。读取执行结果中的
    error.message
    和
    error.causeModule
    。常见的通过架构验证但运行时出现的问题：
    • 映射字段在运行时解析为
      undefined
      或
      null
      （例如：上游模块未生成该字段的输出时使用
      {{2.mimeType}}
      ）
    • 留空默认值的可选参数出现类型转换错误
    • 连接令牌缺失或过期
  4. 修复并重试。诊断后更新场景：
    • 对场景调用
      scenarios_deactivate
    • 使用修正后的蓝图调用
      scenarios_update
    • 调用
      scenarios_activate
      重新启用
    • 再次调用
      scenarios_run
      并从步骤2重复
重复诊断-修复-重试循环，直到执行成功或问题需要用户干预（例如：缺少输入数据、外部服务不可用）。若需要用户操作，解释错误并告知解决方案后再重试。

Step 7: Provide the Scenario URL

步骤7：提供场景URL

Always give the user the scenario URL after creation: 
https://<zone>.make.com/<teamId>/scenarios/<scenarioId>
(uses team ID, not organization ID).
创建场景后，务必向用户提供场景URL：
https://<zone>.make.com/<teamId>/scenarios/<scenarioId>
（使用团队ID，而非组织ID）。

Core Concepts Reference

核心概念参考

When composing scenarios, consult these feature docs to understand how Make's building blocks work. Read the relevant files before using these features in a module composition.
组合场景时，请查阅这些功能文档以了解Make构建块的工作原理。在模块组合中使用这些功能前，请阅读相关文件。

Foundational

基础

  • Bundles — The unit of data flowing between modules. Understand bundle multiplicity before composing flows.
  • Mapping — Connecting data between modules. Field mapping, data types, collections, arrays, functions/formulas.
  • Connections — Authenticating modules with external services. OAuth, API keys, connection reuse.
  • Bundles——模块间流转的数据单元。在组合流程前，请理解bundle的多样性。
  • Mapping——模块间的数据连接。字段映射、数据类型、集合、数组、函数/公式。
  • Connections——模块与外部服务的认证。OAuth、API密钥、连接复用。

Triggers & Scenario Composition

触发器与场景组合

  • Scheduling & Triggers — How scenarios start: instant triggers, polling triggers, schedules, manual/on-demand.
  • Webhooks — Instant triggers via HTTP endpoints. Custom webhooks and app-specific webhooks.
  • Subscenarios — Parent/child scenario composition. Sync and async calls, inputs/outputs, reuse.
  • Scheduling & Triggers——场景启动方式：即时触发器、轮询触发器、计划、手动/按需。
  • Webhooks——通过HTTP端点实现的即时触发器。自定义webhook和应用特定webhook。
  • Subscenarios——父/子场景组合。同步和异步调用、输入/输出、复用。

Data Flow Patterns

数据流模式

  • Iterations — Processing arrays item-by-item. Implicit iterators, explicit Iterator, specialized iterators, Repeater.
  • Aggregations — Collapsing multiple bundles into one. Array, Text, Numeric, and Table aggregators.
  • Data Stores — Persistent key-value storage across scenario runs. Deduplication, state, cross-scenario data sharing.
  • Iterations——逐项处理数组。隐式迭代器、显式Iterator、专用迭代器、Repeater。
  • Aggregations——将多个bundle合并为一个。数组、文本、数值和表格聚合器。
  • Data Stores——跨场景运行的持久键值存储。去重、状态、跨场景数据共享。

Flow Control

流程控制

  • Routing — Router module: multiple routes, multiple can fire, cannot merge back. Fallback routes.
  • Branching — If-Else module: mutually exclusive branches, can merge back.
  • Merging — Merge module: converges If-Else branches into single flow.
  • Filtering — Input filters: pass/block bundles on conditions. Includes filter-vs-router decision guide.
  • Routing——Router模块：多个路由，可同时触发，无法汇合。 fallback路由。
  • Branching——If-Else模块：互斥分支，可汇合。
  • Merging——Merge模块：将If-Else分支汇合为单一流程。
  • Filtering——输入过滤器：根据条件通过/阻止bundle。包含过滤器vs路由器决策指南。

Router vs If-Else Decision Guide

Router vs If-Else决策指南

Choose If-Else + Merge when:
  • Branches are mutually exclusive (only one should run per bundle)
  • Branches need to converge into shared downstream modules (e.g., update a record, send a confirmation)
  • The logic follows an "if A, do X; else if B, do Y; else do Z" pattern
Choose Router when:
  • Multiple routes can fire for the same bundle (e.g., log to Sheets AND alert on Slack)
  • Routes are independent endpoints with no shared follow-up steps
  • You need parallel processing paths that don't converge
选择If-Else + Merge的情况：
  • 分支是互斥的（每个bundle仅应运行一个分支）
  • 分支需要汇合到共享的下游模块（例如：更新记录、发送确认）
  • 逻辑遵循"如果A则执行X；否则如果B则执行Y；否则执行Z"的模式
选择Router的情况：
  • 同一bundle可触发多个路由（例如：记录到Sheets并在Slack上发出警报）
  • 路由是独立端点，无共享后续步骤
  • 需要无需汇合的并行处理路径

Advanced

进阶

  • AI Agents — Make AI Agents (New) with tool-calling. Module tools, scenario tools, MCP tools. Non-deterministic logic.
  • Error Handling — Error handlers per module (Break, Commit, Ignore, Resume, Rollback). Throw module. Only suggest when user explicitly asks.
  • Blueprint Construction — Guidelines for building scenario blueprints programmatically via MCP.
  • Quick Patterns — Compressed MCP call chains for common one-shot scenarios (Slack message, Google Sheets, Airtable, email).
  • AI Agents——Make AI Agents（新版），支持工具调用。模块工具、场景工具、MCP工具。非确定性逻辑。
  • Error Handling——每个模块的错误处理程序（Break、Commit、Ignore、Resume、Rollback）。Throw模块。仅在用户明确询问时建议使用。
  • Blueprint Construction——通过MCP以编程方式构建场景蓝图的指南。
  • Quick Patterns——常见一次性场景的压缩MCP调用链（Slack消息、Google Sheets、Airtable、邮件）。

Common App Gotchas

常见应用陷阱

High-frequency configuration mistakes that cause silent failures or hard-to-diagnose runtime errors. Check these before finalizing module configuration in Phase 2 Step 2.
高频配置错误会导致静默失败或难以诊断的运行时错误。在阶段2步骤2中完成模块配置前，请检查这些内容。

Google Sheets: 
valueInputOption
Required for Write Modules

Google Sheets：写入模块需要
valueInputOption

addRow
and 
updateRow
always require 
"valueInputOption": "USER_ENTERED"
in the mapper (not parameters). Without it, the API returns 
400: INVALID_ARGUMENT — 'valueInputOption' is required
. There is no default — the field must be present:
json
"mapper": {
  "valueInputOption": "USER_ENTERED",
  "values": { "0": "{{1.name}}", "1": "{{1.email}}" }
}
validate_module_configuration
will catch this if called — this is exactly why validation is mandatory per module.
addRow
和
updateRow
始终需要在映射器（而非参数）中设置
"valueInputOption": "USER_ENTERED"
。缺少该参数时，API会返回
400: INVALID_ARGUMENT — 'valueInputOption' is required
。该参数无默认值——必须显式设置：
json
"mapper": {
  "valueInputOption": "USER_ENTERED",
  "values": { "0": "{{1.name}}", "1": "{{1.email}}" }
}
调用
validate_module_configuration
会捕获此问题——这正是每个模块都必须验证的原因。

Google Sheets: Spreadsheet IDs from 
listSpreadsheets
RPC

Google Sheets：
listSpreadsheets
RPC返回的电子表格ID

IDs returned by the 
listSpreadsheets
RPC (e.g., 
1abc123def456
) must be prefixed with 
/
when placed in the 
spreadsheetId
parameter for 
mode: "select"
/ 
from: "drive"
modules:
  • Correct: 
    "/1abc123def456"
  • Wrong: 
    "1abc123def456"
Only applies to select-mode. Map-mode accepts the raw ID.
listSpreadsheets
RPC返回的ID（例如：
1abc123def456
）在
mode: "select"
/ 
from: "drive"
模块的
spreadsheetId
参数中使用时，必须添加前缀
/
：
  • 正确：
    "/1abc123def456"
  • 错误：
    "1abc123def456"
仅适用于选择模式。映射模式接受原始ID。

Webhook Scenarios: Scheduling Type

Webhook场景：调度类型

When the first module is a webhook (
gateway:CustomWebHook
or any instant trigger), always use 
{"type": "immediately"}
for scheduling. Using 
"indefinitely"
causes scenario activation to fail with "Invalid interval." See Step 4 above.
当第一个模块是webhook（
gateway:CustomWebHook
或任何即时触发器）时，调度类型必须使用
{"type": "immediately"}
。使用
"indefinitely"
会导致场景激活失败，提示"Invalid interval"。请参阅上述步骤4。

Gmail / Google Email: 
accountName
Is 
"google-email"
, Not 
"google"

Gmail / Google Email：
accountName
为
"google-email"
，而非
"google"

The 
google-email
app (Gmail) uses a different connection type than Google Sheets, Calendar, and Drive. When filtering 
connections_list
:
  • Google Sheets / Calendar / Drive: 
    accountName: "google"
  • Gmail (
    google-email
    ): 
    accountName: "google-email"
A generic 
"google"
OAuth connection will NOT work for Gmail modules (
google-email:sendAnEmail
, 
google-email:TriggerNewEmail
). It lacks the required Gmail scopes and uses a different connection type entirely. Always verify via 
extract_blueprint_components
that you have the correct connection type — do not assume all Google apps share one connection.
google-email
应用（Gmail）使用的连接类型与Google Sheets、Calendar和Drive不同。筛选
connections_list
时：
  • Google Sheets / Calendar / Drive：
    accountName: "google"
  • Gmail（
    google-email
    ）：
    accountName: "google-email"
通用的
"google"
OAuth连接无法用于Gmail模块（
google-email:sendAnEmail
、
google-email:TriggerNewEmail
）。它缺少所需的Gmail权限范围，且使用完全不同的连接类型。始终通过
extract_blueprint_components
验证是否使用了正确的连接类型——切勿假设所有Google应用共享一个连接。

IML Date Boundaries: No 
endOfDay()
/ 
startOfDay()
Functions

IML日期边界：无
endOfDay()
/ 
startOfDay()
函数

IML does not have 
endOfDay()
, 
startOfDay()
, 
beginningOfDay()
, or similar boundary functions. Attempting to use them produces an "Unknown function" error. To construct day boundaries, use 
formatDate
to extract the date portion and concatenate a literal time:
Start of day: {{formatDate(now; "YYYY-MM-DD")}}T00:00:00Z
End of day:   {{formatDate(now; "YYYY-MM-DD")}}T23:59:59Z
This is the one valid use of date + literal time concatenation. The general rule "never concatenate separate date and time strings" (see IML Expressions) applies to full ISO 8601 datetimes where both parts are dynamic — it does not prohibit combining a 
formatDate
date-only result with a fixed literal time component.
IML没有
endOfDay()
、
startOfDay()
、
beginningOfDay()
或类似的边界函数。尝试使用这些函数会产生"Unknown function"错误。要构造日期边界，请使用
formatDate
提取日期部分并拼接固定时间：
Start of day: {{formatDate(now; "YYYY-MM-DD")}}T00:00:00Z
End of day:   {{formatDate(now; "YYYY-MM-DD")}}T23:59:59Z
这是日期+固定时间拼接的唯一有效用法。通用规则"切勿拼接单独的日期和时间字符串"（参阅IML表达式）适用于日期和时间部分均为动态的完整ISO 8601日期时间——不禁止将
formatDate
的仅日期结果与固定时间分量组合。

Make AI Tools (
ai-tools:Ask
): Model Is Required, No Default

Make AI Tools（
ai-tools:Ask
）：模型为必填项，无默认值

The 
model
parameter in 
ai-tools:Ask
(and other Make AI Toolkit modules) is required — there is no default value. Omitting it causes a 400 error at runtime. When using Make's AI Provider (
ai-provider
connection), use tier slug names: 
"small"
, 
"medium"
, or 
"large"
. (Older docs mention 
low/medium/high
— these are stale; the runtime rejects them with 
Model X not allowed for Make AI Provider
.) Only 
small
is empirically verified for 
ai-tools:Summarize
v2 as of 2026-05; the others follow Make UI conventions but should be confirmed via the Module dropdown. The dropdown labels surface as e.g. "SmallModel: gpt-5-nano. Reasoning: minimal." — match those slugs. Do not use provider-specific model IDs (e.g., 
"gpt-4o-mini"
) with the Make AI Provider — they are not valid tier names and will fail. The 
RpcGetModels
RPC currently fails through the MCP server (org-context bug), so the model list cannot be queried programmatically — inspect the UI dropdown if unsure. See make-mcp-reference — Known MCP server bugs for the org-context bug.
No Make AI Provider connection? If the user has no 
ai-provider
connection and cannot create one, check 
connections_list
for alternative AI provider connections (
openai-gpt-3
, 
anthropic-claude
, 
gemini-ai-*
) and use the corresponding app-specific module instead of 
ai-tools:Ask
. These modules accept provider-specific model IDs. See Blueprint Construction — AI Tools for details.
ai-tools:Ask
（及其他Make AI Toolkit模块）中的
model
参数为必填项——无默认值。省略该参数会在运行时导致400错误。使用Make的AI供应商（
ai-provider
连接）时，请使用层级别名：
"small"
、
"medium"
或
"large"
。（旧文档提及
low/medium/high
——这些已过时；运行时会拒绝这些值，提示
Model X not allowed for Make AI Provider
。）截至2026-05，
small
已通过经验证可用于
ai-tools:Summarize
v2；其他层级遵循Make UI约定，但应通过模块下拉列表确认。下拉列表标签显示为例如"SmallModel: gpt-5-nano. Reasoning: minimal."——匹配这些别名。切勿将供应商特定的模型ID（例如：
"gpt-4o-mini"
）用于Make AI供应商——它们不是有效的层级名称，会导致失败。目前
RpcGetModels
RPC通过MCP服务器调用失败（组织上下文bug），因此无法通过编程方式查询模型列表——若不确定，请查看UI下拉列表。有关组织上下文bug，请参阅make-mcp-reference — 已知MCP服务器bug。
无Make AI Provider连接？：若用户没有
ai-provider
连接且无法创建，请检查
connections_list
中的替代AI供应商连接（
openai-gpt-3
、
anthropic-claude
、
gemini-ai-*
），并使用相应的应用特定模块替代
ai-tools:Ask
。这些模块接受供应商特定的模型ID。有关详细信息，请参阅蓝图构建——AI工具。

Official Documentation

官方文档

Related Skills

相关技能

  • make-module-configuring — HOW to configure each module: parameters, connections, mapping, webhooks, data stores, IML expressions, validation
  • make-mcp-reference — MCP server configuration, scopes, access control, and troubleshooting
  • make-module-configuring——如何配置每个模块：参数、连接、映射、webhook、数据存储、IML表达式、验证
  • make-mcp-reference——MCP服务器配置、权限范围、访问控制和故障排除