Connecting Business Tools: Integration That Works

The average B2B company uses 12 SaaS tools. Most share zero data between them, creating duplicate entry, inconsistent records, and the Friday afternoon ritual of reconciling spreadsheets. Here is how to connect them properly.

The Integration Landscape: Four Approaches

Integration is not one thing. There are four distinct approaches, each suited to different types of connections.

Native integrations Most SaaS tools offer built-in integrations with other popular tools. HubSpot connects to Gmail and Outlook. Xero integrates with Stripe. Slack connects to project management tools. These are typically one-click to enable and cost nothing beyond your existing subscriptions.

What they do well: simple, reliable connections between popular tools. What they do poorly: limited customisation, they only implement the most common data flows, and they may not match exactly how your business works. Native integrations are the right first stop. If one exists that does what you need, use it before building anything custom.

iPaaS (Integration Platform as a Service) Tools like Zapier, Make, n8n, and similar platforms sit in the middle of your stack and orchestrate data flows between tools. They are more flexible than native integrations and more accessible than custom code. You build visual workflows: when this happens in tool A, do this in tool B.

What they do well: flexible, handles connections between tools that do not have native integrations, allows transformation and routing logic. What they do poorly: vendor lock-in to the platform itself, cost scales with volume, execution time limits for complex workflows. See our n8n vs Make comparison for details.

Custom API integrations Direct API-to-API connections built as code. Your systems communicate directly without a middleware platform. Maximum control, maximum flexibility, maximum maintenance responsibility.

What they do well: handles any integration requirement, no third-party dependency, optimal performance for high-volume data exchange. What they do poorly: requires development resources to build and maintain, breaks when either system’s API changes.

Unified platforms All-in-one platforms that aim to replace multiple point solutions. HubSpot’s full suite. Salesforce with all modules. Monday.com for project and CRM.

What they do well: eliminates integration requirements within the platform’s scope. What they do poorly: compromise on every function compared to best-in-class point solutions, high switching cost, vendor dependency.

Choosing the Right Approach for Each Connection

Not every connection in your stack needs the same approach. Apply this decision matrix:

Connection criteria	Recommended approach
Both tools have a native integration	Native first
High frequency, complex logic	Custom code or n8n
Moderate frequency, standard patterns	iPaaS (Make, Zapier)
Critical business logic	Custom code
Low frequency, standard data	Native or simple iPaaS

The key insight: assess each integration requirement independently. Using Make for your marketing stack connections and custom code for your critical financial data flow is not inconsistency. It is the right tool for each job.

Common Integration Patterns

One-way sync. Data flows in one direction only. A form submission creates a CRM contact, but CRM changes do not flow back to the form platform. Simple, low risk of conflict.

Two-way sync. Changes in either system propagate to the other. A contact update in HubSpot updates the corresponding record in Xero. Requires conflict resolution logic: if both systems updated the same field with different values simultaneously, which wins?

Event-triggered. An action in one system triggers a workflow in another. Deal closed in CRM triggers onboarding task creation in project management tool. Clean, clear causality.

Batch processing. Data is collected and transferred on a schedule rather than in real-time. Nightly sync of sales data to a reporting tool. Appropriate for data that does not need real-time currency.

Most integration requirements are event-triggered or batch. Genuine two-way sync is harder to implement reliably than it sounds and should be used only when genuinely needed.

Data Consistency: The Real Challenge

The technical connection is often the easier part. Data consistency is where integrations fail.

Source of truth decisions. When the same data field exists in multiple systems, which system is authoritative? Client contact details: CRM or accounting system? Employee data: HR system or project management tool? Define the source of truth for every data type before building integrations. All other systems should read from or write to that source.

Conflict resolution. When data diverges between systems, you need a defined rule for which wins. Options: most recent update wins, source of truth wins regardless of timestamp, flag conflicts for human resolution. Each has trade-offs. Choose explicitly rather than discovering the behaviour when something goes wrong.

Schema differences. Systems use different field structures, value formats, and taxonomies for the same data. A “Company Size” field might use “11-50 employees” in one system and “Small” in another. Your integration layer needs to map between these, which requires explicit translation rules.

Change detection. How does an integration know something has changed? Some systems offer webhooks that notify on change. Others require polling (regularly checking for updates). Webhooks are faster and cheaper to run. Know which approach each system supports before assuming real-time capability.

Building an Integration Map

An integration map documents your full connectivity: every system, every connection between systems, the direction of data flow, who owns the connection, and what happens if it fails.

For a business with 8-15 tools, this fits on a single diagram. What it gives you:

Visibility into which tools depend on data from which other tools
Clarity on who is responsible for each connection when it breaks
Identification of critical path dependencies (what happens to system C if connection A-B fails?)
A starting point for any new integration discussion (where does this new tool fit in the current map?)

Building this map before integrating is ideal. Building it now for your existing stack is still valuable. Starting from scratch with no documentation is the state most businesses are in, and it makes everything harder.

Our advisory service includes integration mapping as part of any systems assessment. We identify what you have, what is connected, what should be connected, and in which order to build.

Need a coherent integration strategy for your tool stack? Get in touch and we will map your current state as the starting point.