Zapier

The Process Owner

The visual editor gives me paths, loops, filters, delays and built-in forms with conditional logic — enough to route a purchase request. But I found no public information on approval steps with approvers by role, substitutes, deadlines that escalate, or versioning that leaves running instances on their original version, and without those a process change puts the forty requests already in flight at risk. 2 5

Report an error

The Integration Engineer

The visual no-code editor gives me Paths, Filters, Looping, Delay and Scheduling, and Forms with conditional logic ship on all plans — solid branching, but nothing I can hand a business owner for people-work. We found no public information on approval steps assigned to roles, substitutes, deadlines with escalation, or versioning that keeps running workflows on their original version when the process changes. 2 5

Report an error

The Operations Analyst

The visual editor is real and deep — Paths for if/then routing, multiple loops with steps after loops, unlimited paths, forms with conditional logic, filters, scheduling — but everything I need for an invoice approval is absent from the captured pages: no evidence of approval steps, approvers by role, substitutes, deadlines or escalation, and nothing on versioning a workflow that is already running. We found no public information on a task inbox for participants or a test-before-publish mode for the process itself. 2 5

Report an error

The Head of IT

A visual no-code editor with Paths, multiple loops, Filters and Delay, and a Forms product with conditional logic — but this is trigger-to-action plumbing. We found no public information on approval steps assigned to roles or groups, substitutes, deadlines or escalation chains, and nothing on versioning a workflow so that instances already running stay on their original version. 2 5

Report an error

The Data Protection Officer

The visual editor shows branching paths, loops, scheduling and built-in forms with conditional logic, so the modelling basics are real. We found no public information on approval steps assigned to roles or groups, substitutes, deadlines with escalation, or versioning that keeps running workflows on their original version — and an approval record of employees' behaviour is the first thing I ask to see, so its absence from the captured pages decides this. 1 2 5

Report an error

The Skeptic

The visual editor earns its keep on logic: paths, filters, looping with steps after the loop, unlimited paths in the new Workflow Manager, plus a real forms product with conditional logic and a tables store. The human apparatus this criterion lives on is unevidenced — we found no public information on approval steps, approver roles or substitutes, deadlines and escalation, or versioning of a workflow that already has runs in flight. The automation modes from deterministic to fully agentic are a control-flow story, not an accountability one. 1 2 5

Report an error

The Process Owner

Nine thousand apps is a count, not a catalogue: nothing captured documents which triggers and actions each connector supports or who maintains it, and I found no public information naming Microsoft 365 or a DACH ERP such as SAP or DATEV among them. The any-API webhook step, a documented platform API and custom integrations built in code under source control lift it above a logo wall, but I found no public information on an on-premise agent or self-hosted runner reaching our internal databases. 2 5 6 14

Report an error

The Integration Engineer

The catalogue is a count, not a catalogue — 9,000+ apps and 66,000+ triggers and actions with no per-connector action documentation and no DACH ERP or accounting connector evidenced — but the generic side is genuinely strong: webhooks, raw API requests on an existing authentication, a codeable developer platform with CLI, source control and UI-to-CLI conversion, and a documented API that creates fully configured Zaps. What decides it for me: we found no public information on an on-premise agent or self-hosted runner reaching internal databases, no SOAP or database steps, and maintenance ownership is only implied through the third-party developer programmes. 2 5 6 7 8 13

Report an error

The Operations Analyst

Generic reach is genuinely documented — webhooks to any API without code, a documented API to create fully configured Zaps programmatically, per-connection authentication selection, and custom connectors built in code on the platform CLI with source control and version export. What I did not find: a single named connector relevant to DACH back offices, an on-premise agent or runner for systems behind the firewall, or any statement of who maintains each of the 9,000+ connectors. 2 5 6 7 14

Report an error

The Head of IT

Beyond the 9,000-plus app directory there is a generic webhook step ("Connect to any API without writing code"), a documented REST API down to per-action inputs and outputs, and custom integrations buildable in code via the Platform CLI and kept in a team's source control. What I cannot see is any way to reach systems behind our firewall: we found no public information on an on-premise agent or runner, database or SOAP steps, or connector maintenance ownership — and no DACH ERP such as SAP or DATEV is named on the captured pages. 2 5 6 7

Report an error

The Data Protection Officer

Generic HTTP and webhook steps, a documented API for assembling workflows, and custom integrations written in code and kept in source control give genuine reach. The connector catalogue is published as a count rather than named connectors with their triggers, actions and maintenance ownership, and we found no public information on any way to reach systems behind the firewall. 2 5 6 7 14

Report an error

The Skeptic

Nine thousand apps is a logo count — the captured pages state the number without documenting which actions any named connector supports or who maintains it, and we found no public information on German-market systems like DATEV or SAP among them. The genuine substance is generic reach and custom code: webhooks to any API without code, a developer platform that builds private integrations in code with HTTP middleware and versioned deploys from the CLI, and a documented API for building workflows programmatically. Two caveats bite: raw Custom Actions and API Requests are closed to new integrations since July 2024, and we found no public information on any on-premise agent or runner for systems behind a firewall. 2 5 7 8 14

Report an error

The Process Owner

A failed run shows as an error in Zap history with an email per the user's notification settings, throttled requests are retried automatically, monitoring charts error spikes with per-request logs filterable by timeframe and user, and log retention is published per product. I found no public information on replaying a failed run from the failing step, queueing and concurrency controls, a public status page with an uptime commitment, or stated runtime limits. 2 7 9 10 12

Report an error

The Integration Engineer

Errors land in Zap history with email alerts, throttling and stale-auth responses trigger automatic retries of the step, monitoring shows per-request logs filterable by timeframe, log type and user email, and retention is stated per product with custom periods on Company and Enterprise — plus step-level observability and Log Streaming as named controls. But my 3 a.m. test is replay: we found no public information on replaying a failed run from the failing step, on configurable back-off, on runtime and throughput limits, or on a status page and uptime commitment. 1 5 7 9 10 12

Report an error

The Operations Analyst

Failed runs display in Zap history with an email notification, the connector platform retries automatically on throttling and expired authentication, and there is monitoring with filters by timeframe, log type and user email plus step-level observability — but alerts reach an inbox rather than a channel. We found no public information on runtime or throughput limits, replay of a run from the failing step, a public status page, or an SLA, and configurable retention of Zap content appears only on Company and Enterprise plans. 2 7 9 10

Report an error

The Head of IT

Failures surface in Zap history with email notification, throttled and stale-authentication responses are automatically refreshed and retried, and Enterprise lists observability and log streaming. But we found no public information on replaying a failed run from the failing step, error paths, documented runtime or payload limits, or a public status page with incident history — and the captured pages confirm Zaps simply pause at the task limit when pay-per-task billing is off. 1 2 7 10

Report an error

The Data Protection Officer

Failures are shown in the workflow history with email alerts, throttled and expired-authentication requests are retried automatically, and the retention schedule states periods per product — for instance function run content held seven days in logs, nine months in the account and up to four months in backups. We found no public information on replaying a failed run from the failing step, a dedicated error workflow, runtime or payload limits, or a public status page with incident history. 2 7 9 10 12

Report an error

The Skeptic

Failures are not silent: errors land in Zap history with email notification per the user's settings, and the monitoring pages show every request with error messages and logs filterable by timeframe, log type and user email. Automatic retry exists only inside integration code — a throttled 429 or an expired OAuth token triggers a retry — and we found no public information on replaying a failed run from the failing step, on error paths, on runtime and throughput limits, or on a status page and uptime commitment. Enterprise observability and step-level visibility in the Workflow Manager are the strongest promises, both stated without the operational detail a production buyer needs. 2 5 9 10 12

Report an error

The Process Owner

Team plans include SAML single sign-on, shared folders with admin and collaborator roles and granular per-member permissions, plus a governance view of every workflow run with its owner and the systems involved; retention of Zap content and history is documented and can be shortened on Company and Enterprise. I found no public information on where connection credentials are stored, SCIM provisioning, separate development and production environments with controlled publishing, or an exportable audit trail of changes — the answers a works council will demand of me. 1 2 9 12

Report an error

The Integration Engineer

SAML SSO on the Team plan, granular per-member permissions across triggers and actions, shared folders with Managed Connections, AI Guardrails, allow/deny policies on SDK credentials, and a genuinely detailed retention-and-deletion schedule with export of Zap history put the basics in place. The trail is the weak leg: Asset History is only named as a platform control, and we found no public information on an exportable audit log of changes and approvals, external secret stores, SCIM provisioning, payload redaction, or what the record captures about individual users — a works council would want more than this. 1 2 11 12

Report an error

The Operations Analyst

SAML SSO, shared Zaps and folders with granular permissions, advanced admin and app controls, allow/deny policies on SDK credentials, a governance view of every run with its owner and systems involved, and an unusually detailed retention-and-deletion schedule per product are all documented. We found no public information on how connection credentials are stored, and the audit trail of workflow changes appears only as a control named Asset History with no description of what it records about individual users — which matters when an approval record documents employee behaviour. 1 2 11 12

Report an error

The Head of IT

SAML SSO on the Team plan, granular permissions per team member, a single view of every workflow run with its owner and the systems involved, and a published retention schedule with configurable retention on Company and Enterprise — that clears my SSO and inventory-with-owners requirements. The rest does not follow: we found no public information on where connection credentials are stored, an exportable audit trail of changes, SCIM provisioning, or separate test and production environments with a publishing approval. 1 2 12

Report an error

The Data Protection Officer

SAML single sign-on, admin and collaborator roles over shared folders and connections, a central view of every workflow run with its owner, shorter configurable retention of workflow content on Company and Enterprise plans, and a per-action approval checkpoint before an AI agent touches a connection give a works council something to work with. We found no public information on export of the audit trail, SCIM provisioning, external secret stores, field-level masking of payloads in logs, or certifications, and the only statement about individuals is that monitoring logs can be filtered by user email. 1 2 9 11 12

Report an error

The Skeptic

SAML single sign-on, shared Zaps, folders and app connections, and advanced admin permissions on Enterprise are documented, and the retention schedule is unusually concrete, per product, with shorter Zap-content retention configurable on Company and Enterprise plans. The works-council items are homepage labels without captured documentation — Managed Connections, AI Guardrails, Asset History, Log Streaming — and we found no public information on where connection credentials are stored, on an exportable audit trail of changes, or on separate development and production environments. Seeing every agent action and workflow run with its owner is the right promise, made once, in one line. 1 2 11 12

Report an error

The Process Owner

The captured plan pages describe one cloud service, and I found no public information on a hosting region or a self-hosted edition. Export of Zap workflows, history and account data is offered before account deletion, though no format is documented for it, and only developer-built integrations — not our approval workflows — can be converted between tools and kept in source control. 2 4 12 14

Report an error

The Integration Engineer

Export of Zap workflows, account data and Zap history is documented, and an export-before-deletion path to switch providers is promised under the EU Data Act terms — that is real, but the format is not documented. We found no public information on a selectable hosting region, a self-hosted or on-premise edition, or the engine's licence, and the portability evidence that is documented covers developer-integration code (converting between Platform UI and CLI) rather than the customer's own workflows. 4 12 13 14

Report an error

The Operations Analyst

Cloud-only with no stated region anywhere in the captured pages and no self-hosted edition evidenced. Export options do exist — Zap workflows, Zap history and account data, plus a documented process to take content to a new provider before deleting the account — but the export format is unstated, so I cannot credit documented JSON or BPMN portability; the only format-described movement is integration code between the platform UI and CLI. 4 12 14

Report an error

The Head of IT

Zap workflows, Zap history and account data can be exported, export before account deletion is promised in the terms, and the only documented definition portability is for developer integrations moving between the vendor's own Platform UI and CLI. I found no public information on a self-hosted or on-premise edition, the engine's licence, a named hosting region, or an export in BPMN 2.0 or documented JSON — in other words, no documented exit to another tool, which is the part I care about most. 4 12 13 14

Report an error

The Data Protection Officer

Export of Zap workflows, Zap history and account data is documented, the terms even describe exporting content before termination in order to switch providers, and developer-platform integrations convert between the visual editor and the CLI. We found no public information on a self-hosted or on-premise edition, a selectable cloud region, the engine's licence, or an export format such as documented JSON or BPMN, so portability rests entirely on the vendor's own export. 4 12 13 14

Report an error

The Skeptic

Everything captured describes a cloud-only service, and we found no public information on a hosting region, a self-hosted or on-premise edition, or the engine's licence. Portability is half-real: Zap workflows, Zap history and account data are exportable, and the terms commit to letting you export your content before account termination to switch providers — but we found no public information on the format those exports produce, so whether another tool can read them cannot be verified from the pages. Checking connector code into source control on the developer platform protects integrations, not your workflows. 1 4 12

Report an error

The Process Owner

Zapier, Inc. of San Francisco, a Delaware corporation, is the vendor of record here, and the captured pages state neither where workflows and their payload copies execute and are stored, nor any subprocessor list — including the model providers behind the AI steps the terms of service themselves define, with building via Claude or ChatGPT offered in the editor. With invoice and personnel data, that is a stop sign, not a footnote. 3 4 5

Report an error

The Integration Engineer

The vendor is Zapier, Inc. of San Francisco, a Delaware corporation, with no EU contracting entity in the captured pages, and the terms define customer input to AI features without any statement of model provider or location. We found no public information on where workflows and their execution logs are stored, and no subprocessor list — Bring Your Own Model is a control, but with the whole chain's locations unstated there is nothing here for a European procurement file. 1 3 4

Report an error

The Operations Analyst

The vendor behind every captured page is a US company with a US privacy contact, and the pages state no execution region, no log-storage location and no subprocessor list — including the model providers behind the AI features the terms expressly cover. Jurisdiction, ownership, data residency and subprocessor exposure all came back unknown, so there is nothing here for a European buyer to hang a data-protection assessment on. 3 4

Report an error

The Head of IT

The contracting entity is Zapier, Inc. of San Francisco — a US Delaware corporation — with the execution and log-storage location unstated and no published subprocessor list; AI steps exist in the platform with no statement of where their model providers run. A non-EU vendor, an unstated execution location and unnamed subprocessors sit at the bottom of this scale by definition. 3 4

Report an error

The Data Protection Officer

The provenance places the vendor in San Francisco, USA, and we found no public information on the contracting entity's jurisdiction as stated by the vendor, on where workflows execute or where execution logs with their payload copies are stored, or on a single subprocessor — including the AI model providers behind the AI steps. A 'Bring Your Own Model' control is listed, and we found no public information on where the default models run, on a data-processing agreement covering execution payloads, or on any EU hosting safeguard. 1 3 4

Report an error

The Skeptic

The contracting entity is Zapier, Inc. of San Francisco, and we found no public information on where workflows execute or where execution logs with their payload copies are stored. We found no public information on subprocessors either — including which model providers sit behind the AI steps the platform sells — and Bring Your Own Model is a control label, not a disclosure. Non-EU entity, unstated execution location, unnamed subprocessors: the worst case holds on every element. 1 3 4

Report an error

The Process Owner

What counts as a task is unusually well defined: triggers and polling are free, a published list of step types never counts, one MCP tool call uses two tasks, everything draws from one shared pool, and Zaps pause at the limit unless pay-per-task billing is on. But the captured pages give no tier prices, monthly task allowances or overage rates, so I still cannot compute the monthly cost of our purchase approvals. 2

Report an error

The Integration Engineer

The task unit is defined better than most: triggers and polling never count, the non-task steps are enumerated one by one, one MCP tool call costs two tasks, and every product draws from a single shared pool with Zaps pausing or pay-per-task at the limit. But the captured pricing page carries no tier prices, no monthly task allowances and no per-task overage rate, so a buyer still cannot compute their own monthly cost from it. 2

Report an error

The Operations Analyst

The task is defined better than most: only successfully completed actions count, triggers and a long list of utility steps including Looping never count, one MCP tool call uses two tasks, and a single shared pool serves workflows, AI, code, MCP and SDK — yet no tier price, monthly allowance or overage rate appears on the captured pricing page, so I still cannot compute what a month of my processes costs. With pay-per-task billing turned off, Zaps simply pause at the limit, which is exactly how a month-end run dies. 2

Report an error

The Head of IT

The billing unit is defined better than most: a task is charged only when an action completes, triggers and polling are free, ten step types are listed as non-billing, and one MCP tool call uses two tasks from the shared account pool. But the captured pricing pages contain no price figures, no per-plan task allowances and no overage prices, so a buyer still cannot compute a monthly invoice from public information alone. 2

Report an error

The Data Protection Officer

The billing unit is defined better than most: a task is one successfully completed action, polling and triggers are free, named step types never count, one MCP tool call uses two tasks, and all products draw from one shared pool. We found no public information on tier prices, monthly allowances, overage rates, the per-task price of the pay-per-task option, premium connectors or self-hosting, so a buyer cannot compute their own monthly cost from the captured pages. 2

Report an error

The Skeptic

The billing unit is defined with unusual honesty: a task is a successfully completed action, triggers and a named list of built-in steps cost nothing, one MCP tool call consumes two tasks, every product draws from one shared pool, and workflows pause at the plan limit unless pay-per-task billing is switched on. But we found no public information on the tier prices, the task allowance per plan, or the per-task rate that pay-per-task billing charges — so the monthly cost of a buyer's own process is still not computable from what was captured. Plan mechanics like prorated upgrades, downgrades at cycle end and cancel-anytime are stated; the numbers are not. 1 2

Report an error