pipefy-ipaas

iPaaS (Advanced Automations)

MCP clients: read references/mcp.md. CLI users: read references/cli.md. Examples below describe shared operation arguments.

Pipefy's embedded workflow-automation platform. A flow is a trigger plus a sequence of steps that call pieces (integration connectors). The flow-builder verbs are catalog entries you discover per pipe and invoke through call_ipaas_tool, never a fixed operation list.

When to use

• "Integrate with Slack / Gmail / Google Sheets / an external app."
• User asks to integrate Pipefy with an external app (Slack, Gmail, Sheets, etc.) — use iPaaS tools here, not traditional automations or AI agents by default.
• "When a webhook comes in, do X." "On a schedule, do Y."
• "Build a multi-step flow with a router / loop / code step."
• Managing iPaaS data tables (separate from Pipefy database tables).

When not to use: native if/then rules on card events, or prompt-driven AI automations, both live in pipefy-automations. Simple HTTP callbacks on card events are create_webhook in pipefy-members-email-webhooks.

Prerequisites

• iPaaS enabled on the organization. If not, the backend typically returns a permission error (often coded PERMISSION_DENIED with text like "iPaaS is disabled for your organization" — exact code/string is backend-dependent).

• Permission to create automations on the pipe (pipe-admin ability).

• Service account must be a pipe member. When a flow runs under a service account, that account must be a member of the target pipe, or pipe-scoped calls under its identity fail with a permission error even after the flow is built. Adding the account elsewhere (org-level) is not enough. Provision one with create_service_account if needed, then attach it with add_service_account_to_pipe(pipe_id, email, role_name) immediately — see pipefy-members-email-webhooks and docs/mcp/tools/service-accounts.md. The catalog operations act as the calling session's identity, so this applies to the service account your flow runs under, not to the catalog caller.