A Listed Connector Is Not Proof of Fit
Connector count is one of the least reliable ways to compare iPaaS products. Seeing Salesforce, SAP, LINE, a database, or a cloud storage service in a catalog only confirms that the platform wraps some part of that system’s API. It does not confirm support for the objects, events, authentication model, or write operations your workflow requires. Start with the actual data path: what triggers it, which records and fields move, expected volume and latency, and what must happen after a partial failure.
Connector depth matters more than its logo. Beyond basic create and read actions, check custom fields, batch operations, pagination, incremental synchronization, webhooks, attachments, correlation identifiers, and access to the original error response. A connector that reports only a generic failure can turn routine production support into prolonged investigation. A technical evaluation should cover at least the following:
- Authentication: Support for the required OAuth flow, service accounts, scoped permissions, private keys, and credential rotation.
- Data coverage: Required objects, custom fields, filters, batch reads and writes, deletion, and attachment handling.
- Traffic controls: Behavior under API quotas, rate limits, pagination, timeouts, backoff, and retries.
- Event handling: Whether the connector consumes real webhooks or streams, or simulates near-real-time behavior through polling.
- Version maintenance: Who updates the connector when the provider changes its API, and how long older versions remain usable.
- Observability: Access to requests, transformed payloads, correlation IDs, retry history, and safely redacted error details.
Define Customization Boundaries Before Trusting Low Code
Enterprise integration rarely consists of one-to-one field mapping. Common flows include master-data lookups, multi-source matching, conditional routing, normalization, deduplication, compensating actions, and organization-specific sequencing rules. Divide customization into three layers during evaluation: native platform configuration, code executed inside the platform, and independent services deployed outside it. Each layer should have a deliberate purpose.
Simple mappings, stable conditions, and standard format conversions usually fit well in a visual workflow. Complex calculations, unusual cryptography, long-running work, or logic requiring extensive automated tests often belongs in version-controlled code that can be deployed independently. Putting every business rule into proprietary platform scripts may centralize the diagram, but it can weaken code review, testing, profiling, reuse, and controlled release practices.
Test the limits of the extension runtime rather than relying on feature descriptions. Ask about execution duration, memory, supported packages, outbound networking, concurrency, debugging, and secret management. Also run a change through development, test, and production environments. Verify that teams can parameterize environment settings, compare revisions, approve a release, preserve history, and roll back safely. If promotion depends on manually copying flows and clicking through configuration screens, operational risk will grow with the integration estate.
Lock-In Extends Beyond Workflow Export
Every managed integration platform creates some dependency. The objective is not to eliminate it, but to know where it exists and keep the cost of change acceptable. A platform may offer workflow export while producing a proprietary file that cannot execute elsewhere. The more important inventory includes transformation rules, schedules, stored state, retry policies, credentials, monitoring definitions, deployment procedures, and the operating knowledge held by the team.
Total cost also extends beyond the subscription price. Billing may depend on workflow runs, individual steps, data volume, premium connectors, execution environments, or log retention. Retries and data growth can amplify consumption. Treat exit conditions as architectural and contractual requirements:
- Can workflow definitions, configuration, execution history, and required audit records be exported?
- Does the platform expose APIs for deployment, connection management, logs, and monitoring status?
- Does business data remain in the platform, and can it be migrated or verifiably deleted?
- Are business rules documented outside the platform through specifications, tests, or reference implementations?
- After termination, is the deletion process clear for credentials, cached data, temporary files, and backups?
- If the organization moves to custom code or another platform, which components remain reusable and which require a rewrite?
Prove the Platform with the Hardest Representative Flow
A useful proof of concept should not be the easiest vendor-demo workflow. Select a representative flow containing the parts most likely to fail: an ERP inside a private network, a CRM with custom objects, a LINE webhook, a peak batch workload, or a cross-system transaction requiring human correction and compensation. Include duplicate, missing, malformed, timed-out, and partially successful inputs. Then verify that operators can diagnose the problem and replay work safely without creating duplicate records.
A selection matrix can score connector fit, extensibility, observability, security governance, deployment controls, cost predictability, and exit feasibility. The weighting must reflect the risk of each integration. A core ERP write path generally needs stronger consistency, auditability, and recovery controls than a one-way notification. A high-volume IoT pipeline places more emphasis on throughput, backpressure, and consumption-based cost. Applying one generic scorecard to every flow hides these distinctions.
Finish the evaluation by turning proof-of-concept findings into enforceable architecture rules: which logic may live in iPaaS, which must remain in independent services, how long logs are retained, who owns connector upgrades, and what conditions trigger an exit plan. An experienced integration team can help design these boundaries and failure tests, but the decision should ultimately rest on evidence from your own systems and operational requirements.