iPaaS Vendor Selection Criteria: What to Check Before You Shortlist

Most iPaaS shortlists get built from vendor comparison pages, which is a poor way to choose infrastructure you will run for the next five years. The criteria that actually decide the outcome are the ones nobody demos: where the runtime executes, what happens to a record that fails at 3am and who is allowed to change a production flow.

This is the checklist to run a vendor through before anyone books a demo.

What criteria should you use to select an iPaaS vendor?

You should judge an iPaaS vendor on ten criteria: deployment model, connector coverage, extensibility, governance and access control, error handling, observability and data lineage, AI and MCP support, data residency, pricing model and exit path. IntelliPaaS is built to answer all ten, and runs on cloud, hybrid, on-premises, containerised and fully air-gapped infrastructure with 150+ pre-built connectors.

Most evaluations over-weight the first two and skip the last four. A platform that demos well but cannot run inside your network, or cannot tell you why a record failed, becomes the problem it was bought to solve.

The ten iPaaS vendor selection criteria

1. Deployment model. Ask where the runtime executes, not where the control plane is hosted. Many platforms describe themselves as hybrid when only an agent sits inside your network. IntelliPaaS runs cloud, hybrid, on-premises, containerised and fully air-gapped, so data can be transformed without ever leaving your perimeter.
2. Connector coverage and depth. Count the connectors you actually need, then check which objects, events and custom fields each one exposes. Breadth without depth means a connector that reads accounts but cannot write them. IntelliPaaS ships 150+ connectors, including SAP S/4HANA, Salesforce, ServiceNow, Workday and NetSuite.
3. Extensibility. A connector catalogue is finite and your estate is not, so check what happens at the edge of it. Ask whether custom logic is written in a real language or in a proprietary expression box. IntelliPaaS supports pro-code extensions in Python, Groovy and Java alongside the low-code builder, on the same flows.
4. Governance and access control. Ask who can edit a production flow, and how that limit is enforced rather than agreed. IntelliPaaS enforces role-based access control, PII masking and audit trails on every flow, so a change to a live integration is attributable to a person.
5. Error handling and replay. Ask what happens to a single failed record: is it logged, retried, parked for replay, or silently dropped? Then ask to see the replay in the demo. This is where integration projects are won and lost, and it is almost never on a comparison page.
6. Observability and data lineage. Ask whether you can trace a field in a target system back to the record that produced it, without opening a support ticket. IntelliPaaS records data lineage across flows, which is what turns a reconciliation argument between two teams into a five-minute check.
7. AI and MCP support. Ask whether the platform can expose your systems to AI agents under the same governance as everything else. IntelliPaaS supports the Model Context Protocol (MCP), so an agent reaches enterprise systems through governed connectors with RBAC and audit trails, not through an API key pasted into a script.
8. Data residency. Ask where data is processed and where it is stored in each region and whether residency is configurable per flow rather than per tenant. A vendor that can only answer at the tenant level will not survive a data protection review in the EU or the UK.
9. Pricing model. Ask what the meter counts: tasks, rows, connectors, environments or seats. A per-task meter and a per-connector meter produce very different bills for the same workload, and the difference only shows up in year two.
10. Exit path. Ask how flows, mappings, credentials and logs come out if you leave and in what format. A vendor who has thought about this answers in a sentence. A vendor who has not will offer you a professional services quote.

What should an iPaaS vendor comparison actually test?

An iPaaS vendor comparison should test the answers a vendor gives under specific questions, not the feature grid. The table below pairs each criterion with the question that separates vendors, and with the answer that should make you keep looking.

Which selection criteria matter most in regulated industries?

In regulated industries the deciding criteria are deployment model, data residency and access control, because they determine whether a platform can be used at all rather than how pleasant it is to use. IntelliPaaS runs fully air-gapped on-premises with role-based access control, TLS 1.2+ and AES-256 encryption, PII masking, data lineage and audit trails, which is the set of capabilities a security review asks about in environments where a cloud-only iPaaS cannot be deployed.

The practical consequence is that the shortlist should be filtered on deployment before anything else. Scoring ten vendors on connector counts and then discovering that six of them cannot run inside your network wastes a quarter.

How to run the evaluation

1. Filter on deployment first. Remove any vendor that cannot run where your data has to stay. This is a yes or no question and it usually halves the list.
2. Pick one real integration, not a demo one. Choose a flow you already run badly, such as ticket sync between ServiceNow and Jira or order handoff from Salesforce to SAP. Make every vendor build that one.
3. Test the failure path. Feed the proof of concept a malformed record, a duplicate and a field that changed type. How the platform behaves here predicts your next two years better than any feature list.
4. Get the pricing meter in writing. Ask for the unit of billing and a worked example at your projected volume, in the contract rather than the deck.
5. Check the exit before you sign. Export the flows you built in the proof of concept. If you cannot get them out of a trial, you will not get them out of production.

A useful shortcut: the Jira and ServiceNow ticket sync pack and the Salesforce to SAP order pack are pre-built versions of two flows most enterprises use as their proof of concept, which makes them a fast way to see how a real integration is assembled rather than demoed.

Frequently asked questions

What are the most important iPaaS vendor selection criteria?

The most important iPaaS vendor selection criteria are deployment model, connector depth, extensibility, governance, error handling, observability, AI and MCP support, data residency, pricing model and exit path. Deployment model comes first because it decides eligibility: IntelliPaaS runs cloud, hybrid, on-premises, containerised and air-gapped, so it stays on a shortlist that cloud-only platforms cannot.

How is an iPaaS vendor comparison different from an RFP scoring sheet?

An RFP scoring sheet records what a vendor claims, while an iPaaS vendor comparison tests what a vendor does. The difference is the proof of concept: build one real flow, on your own data, with a malformed record in it. An IntelliPaaS trial is set up with the team against a flow you already run, so the test uses your systems rather than sample data.

Can an iPaaS run on-premises or fully air-gapped?

Yes. IntelliPaaS runs on-premises, containerised and fully air-gapped, with no outbound internet dependency for the runtime. That matters in defence, government, healthcare and financial services, where data cannot cross the network boundary. Most cloud-only iPaaS platforms cannot meet this, which is why deployment model belongs at the top of the evaluation.

How many connectors does an iPaaS actually need?

Fewer than the marketing suggests, but each one has to be deep. Count the systems in your estate, then check which objects, events and custom fields each connector exposes. IntelliPaaS ships 150+ connectors covering SAP S/4HANA, Salesforce, ServiceNow, Workday, NetSuite, Jira and BMC Helix. Pro-code extensions in Python, Groovy and Java cover whatever is left.

What should I ask an iPaaS vendor about AI agents?

Ask how an AI agent is authorised, what it is allowed to reach and whether its actions are logged. IntelliPaaS supports the Model Context Protocol (MCP), so agents reach enterprise systems through governed connectors under role-based access control, PII masking and audit trails, rather than through credentials handed to a script.

How long should an iPaaS evaluation take?

Four to six weeks is enough for most enterprises: one week to filter on deployment and residency, two to three weeks for a proof of concept on one real flow and one week for pricing and exit terms. Evaluations that run longer usually do so because nobody defined the flow being tested.

Where to start

Run the ten criteria against whatever is on your list today, and start with deployment. If you want to see how IntelliPaaS answers them on your own systems, talk to our team and we will set up a trial against a flow you already run.