Every SaaS sales deck has the same slide: a circle of logos showing all the “native integrations.” What the slide doesn't say is that those integrations vary from genuinely useful to “we sync a contact record once a day if you remember to enable it.” Buying integrations like they're fungible is how companies end up with seven tools each holding a slightly different version of the same customer.
A better posture: treat your integration layer as a deliberate piece of architecture, not as a series of toggle switches you flip during procurement. Here is the decision framework we use, and the three questions that decide everything.
Question 1: What's your system of record?
For every entity that lives in more than one tool — customers, contacts, deals, projects, products, invoices — one system has to be the source of truth. Other systems either read from it or get told about changes; they don't edit it independently.
If you can't answer this for each major entity, integrations will keep biting you no matter how many you build. Two systems editing the same record without a clear hierarchy guarantees data conflicts, and integrations can't arbitrate values they don't own.
Common defaults that work for most mid-size businesses:
- Customers/contacts — CRM (Salesforce, HubSpot) is system of record.
- Financials — ERP or accounting tool is system of record (Xero, NetSuite, etc.).
- Projects/work — PM tool (Asana, Jira) for active work; archived state may live in BI or a data warehouse.
- People/employees — HRIS (BambooHR, Rippling) is system of record for everything from onboarding triggers to permission groups.
Write this down. Make it the first slide of any integration project kickoff. Half the integration disputes you'll have come from people who quietly disagree with this list.
Question 2: Native, iPaaS, or custom?
Three options, three cost curves.
Native integrations
The integration ships inside one of the apps. Pros: it's usually free, maintained by the vendor, fast to enable. Cons: the feature set is whatever the vendor decided to build, and you've handed control over the integration logic to a roadmap you can't influence.
Good when: the integration does exactly what you need today, and you're fine if the vendor never improves it.
iPaaS (Zapier, Make, n8n, Workato)
A middle-layer platform that connects systems via prebuilt connectors. Pros: fast to build, visual to maintain, broad coverage. Cons: per-run pricing scales with volume, debugging cross-system failures can be tricky, and you become dependent on whichever vendor you choose.
Good when: you have a handful of low-to-medium-volume workflows, each one well-defined, and the time-to-value of a 2-day build beats a 2-month custom integration.
Custom integrations
Code that talks directly to the APIs of each system. Pros: full control, no per-run cost, can encode exactly the business logic you need. Cons: someone has to build and maintain it; debugging production failures requires engineering time.
Good when: the integration is core to your business, the volume is high, the logic is non-trivial, or you have requirements (security, latency, data residency) that the iPaaS layer can't meet.
The rule of thumb
Start native if it covers 80% of the requirement. Move to iPaaS for glue between systems that don't have a good native option. Build custom only for integrations where the iPaaS layer becomes the bottleneck — usually around volume, latency, or business logic complexity.
Question 3: Events or polling?
Integrations move data in one of two patterns. Knowing which one you're using — and which you should be using — matters more than which platform you pick.
Event-driven (webhooks)
System A pushes a message to system B the moment something changes. Near-real-time, efficient, but failure-prone if your infrastructure isn't set up to handle retries and dropped events.
Polling
System B asks system A “anything new?” on a schedule. Slower, but easier to reason about and recover from. Most iPaaS platforms default to polling because it's safer.
A useful rule: if the user expects to see the data within seconds, you need events. If the user expects to see it within minutes or hours, polling is fine and easier to operate.
The four things every integration needs (that people skip)
- Idempotency. The same event arriving twice should not produce two records. This is the #1 cause of duplicated customers, double-charged invoices, and confused users.
- Retry logic. Networks fail. APIs rate-limit. Your integration should retry with exponential backoff, not give up and silently lose the event.
- Failure visibility. When something does fail for good, a human gets told. A dead letter queue, an alert in Slack, an email — anything that surfaces the problem within the same business day.
- A reconciliation pass.Once a day (or week), something checks that the two systems agree. The first time you run this, you'll find drift you didn't know existed. That's the point.
The honest case for “no integration”
Sometimes the right answer is to not integrate. A few patterns where a deliberate manual handoff beats automation:
- Low volume + high stakes. If something happens twice a month and a wrong record causes real damage, a human should be in the loop.
- Process still being figured out. Integrate stable flows. For anything still changing weekly, build the muscle by hand first.
- The two tools are both wrong.If you're gluing together two systems you're planning to replace, the integration is throwaway work. Wait.
Where this lands you
A good integration architecture answers four questions cleanly: what the system of record is for every entity, which integration approach owns each connection, whether each connection is event- or poll-driven, and how failures get surfaced. Get those four right and the integrations themselves become small, replaceable, and boring — which is exactly what you want them to be.