import_cloudflow_flow
Manage CloudFlow. Creates every flow of a previously exported bundle in the authenticated tenant. Imports are create-only: each call creates new draft flows with new IDs — nothing is published and no schedule is activated until the target tenant publishes. Requirements declared by the bundle are ...
This record as markdown: /tools/doit/import-cloudflow-flow.md
What import_cloudflow_flow does on Doit
AI agents use import_cloudflow_flow to create or update resources in Doit, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Doit environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
bundle | object | Yes | Portable, tenant-neutral export of one or more flows. Contains no credentials, tenant identifiers, schedules, or execution state; tenant-scoped references are d |
dryRun | boolean | — | |
options | object | — | |
bindings | object | — | Requirement key → target-tenant resource ID. Keys must be declared in the bundle's requirements. Run with `?dryRun=true` first to list required keys and candida |
Idempotency-Key | string | Yes | |
customerContext | string | — | Scope the request to a specific customer by ID. Required for DoiT employees (whose token isn't tied to a single customer); omit for direct customer users. |
Parameters from the server's own tool schema.
Why import_cloudflow_flow is rated Medium
An AI agent can call import_cloudflow_flow faster than any human can review: one bad instruction and it creates or modifies resources in Doit by the hundred, each call as confident as the last.
Risk signalsHigh parameter count (74 properties) · Bulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
The rule that runs import_cloudflow_flow safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Doit, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For import_cloudflow_flow, this is the rule to start with:
import_cloudflow_flow stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Doit, apply this rule, and every import_cloudflow_flow call is checked against it from then on.
Questions about import_cloudflow_flow
Manage CloudFlow. Creates every flow of a previously exported bundle in the authenticated tenant. Imports are create-only: each call creates new draft flows with new IDs — nothing is published and no schedule is activated until the target tenant publishes. Requirements declared by the bundle are resolved through bindings (requirement key → target-tenant resource ID). Unbound connections and Datastore tables leave the referencing nodes flagged incomplete; unbound global variables are auto-created. Pass options.createMissingTables: true to create missing Datastore tables from the schemas embedded in the bundle (structure only, never row data). Dry-run: pass ?dryRun=true to validate without writing. The response is an import plan: per-requirement resolutions with candidate bindings in the target tenant, the flows that would be created, and every validation issue at once. Idempotency-Key is required even with dryRun. Same key/request replays within 24 hours; different request fails with 422, an in-progress match with 409. Dry-runs validate existing fingerprints without storing a replay. codeNode: JavaScript (default) uses $nodes["<node name>"] and $variables; Python uses nodes and variables. Upstream values are lists. A top-level return produces {message: value}; no return gives JS {} / Python {message: null}. Bare input is not injected; accessing it as upstream data fails the node. A schema (JSON Schema string) is required. The API fingerprints MCP tracking parameters; a changed client/server version can cause a same-key conflict. Keep the original request context and key. If an HTTP failure has only generic text, do not infer a status or retry automatically. It is categorised as a Write tool in the Doit MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
import_cloudflow_flow accepts 6 parameters: bundle, dryRun, options, bindings, Idempotency-Key, customerContext. Required: bundle, Idempotency-Key. The full parameter table on this page comes from the server's own tool schema.
Register the Doit MCP server in PolicyLayer and add a rule for import_cloudflow_flow: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Doit. Nothing to install.
import_cloudflow_flow is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the import_cloudflow_flow rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for import_cloudflow_flow. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
import_cloudflow_flow is provided by the Doit MCP server (@doitintl/doit-mcp-server). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Doit, and thousands of servers like it.
This server
Across the catalogue