make-scenario-building
Use when creating a new Make scenario or editing an existing one — finding modules, connections and account-dependent values, wiring the flow, saving through scenario_create or scenario_patch. Not for explaining, running or debugging a scenario, or for API-call shells.
How do I install this agent skill?
npx skills add https://github.com/integromat/make-skills --skill make-scenario-buildingIs this agent skill safe to install?
- Gen Agent Trust Hubpass
The 'make-scenario-building' skill provides comprehensive and secure instructions for automating workflows on the Make.com platform. It follows security best practices, such as advising against the exposure of webhook URLs and verifying OAuth connection scopes. While the skill's primary function involves processing external data through AI models—which inherently creates a surface for indirect prompt injection—this is a standard characteristic of the platform, and no malicious patterns or deceptive behaviors were detected.
- Socketpass
No alerts
- Snykpass
Risk: LOW · No issues
What does this agent skill do?
Make scenarios — creating and editing
The tool descriptions carry each tool's rules; this skill carries the order of operations and the decisions the tools cannot make. A straight-line scenario needs nothing beyond the workflow below. Load a reference only when its trigger applies.
Ground rules. A 403 means the whole connection must be re-authorized with every permission — never one
tool. A content remark on a result is an instruction, not decoration. scenario_create/scenario_patch
make one save each: put everything one change needs in one call, and read a refused write's errors as a
free dry run. Say what you resolved an ambiguous value to ("the Sales channel", "next Monday") before the
call that acts on it. Details and the refusal contract: make-scenario-reference, when something is refused.
Build a new scenario
- Pin the design in words the user agrees with: every app by name (ask when they name a category — "email", "a form", "AI"), what starts it, what moves where, what happens to non-matching items.
environment_get→organizationId/teamId.app_findwith the user's words, once per goal. Given an instant and a polling trigger for the same source, say which you chose and why.module_specfor every planned module in one call,schemas: true— it gives each module's exactconfigshape and itsdynamicpaths.- Connections: reuse an id from
connection.existing; otherwise oneconnection_createfor every app, hand over the link,connection_getwhen the user says they are done. module_field_resolveeverydynamicpath independsOnorder, copyingvalueintoconfig. A polling trigger's start point is the/datapath — ask "existing items or from now?" before resolving it. (module_options_getis the same lookup keyed bymodule_spec'sdynamicFieldsand aconnectionId; use one or the other per field, not both.)- Compose the flat list: your ids, one
root: "main", everything elsefollowsorparent, oneconfigper module,filterfor a plain continue-or-stop gate. Google Sheets, Gmail, Make AI Tools or date math involved → App gotchas first. scenario_create,autoActivateoff unless asked. Fix everything inerrorsand resubmit; relaywarnings.- Verify, then
scenario_activate. On-demand:scenario_runwithinputs. Polling/scheduled: activate,scenario_run,scenario_execution_get. Webhook: the user sends one real request —scenario_rundoes not exercise a webhook. Then givehttps://<zone>.make.com/<teamId>/scenarios/<scenarioId>.
Edit an existing scenario
scenario_getfor structure andlastEdit;scenario_module_getonly for the modules you will change.- Adding modules:
app_findandmodule_spec(schemas: true)as above; resolvedynamicpaths against the module's currentconfig. - One
scenario_patchwithexpectedLastEditand every operation the change needs. Send only theconfigdomains you changed. Fix every{{<id>.field}}reference a removed or moved module leaves dangling in the same call. - A module added in a call gets its id on save, so wiring onto it is a second call with the returned
lastEdit. Verify from the response'smodulesecho.
A webhook whose payload is unknown
payloadShape: "learned" in module_spec, or a bare gateway:CustomWebHook: create with the trigger alone →
the user sends one real request (or scenario_trigger_learn first) → scenario_trigger_inspect →
scenario_patch the rest. Do not activate a webhook scenario whose fields nobody has seen.
Decisions the tools leave to you
- Filter vs if-else vs router. Skip non-matching items and nothing else →
filter. Non-matching items need their own action →builtin:BasicIfElse(+builtin:BasicMergeto rejoin). Several arms that may all fire →builtin:BasicRouter. - Do not over-build. No error handlers, aggregators or variables unless the design needs them.
References — load only on the trigger
| Trigger | Reference |
|---|---|
| Mapping a trigger's or on-demand input, a whole bundle or an array element; a mapped field came back empty | Mapping |
| A value must be transformed (dates, text, arrays, conditionals) | IML functions |
| More than a straight line: routers, if-else + merge, multi-condition filters, iterating, aggregating | Flow control |
| The scenario is on-demand, calls another scenario, or is called by one or by an agent | Subscenarios |
| Placing a Make AI Agent module with tools | AI agents |
| A run must remember earlier runs (dedup, counters), or a payload needs a fixed schema | Data stores |
| The user asks for retries or fallbacks, or failure/data loss is unacceptable — most scenarios need none | Error handling |
| Finalizing a Google Sheets, Gmail or Make AI Tools config, or a date expression | App gotchas |
A complete scenario_create call to pattern from | Examples |
How can the creator link this skill?
Add the canonical catalog link to the repository README so users can inspect current installs and available audits. The publishing guide covers the complete discovery path.
<a href="https://skillzs.dev/skills/integromat/make-skills/make-scenario-building">View make-scenario-building on skillZs</a>