Software integration is the configured exchange of data or actions between applications. The practical decision is not which label sounds most modern. Choose the simplest supported pattern that meets your needs for direction, timing, data, and control, then define field ownership and failure handling before allowing it to write records.
For example, when a billing platform changes a subscription to active, a validated update may pass to a CRM. Billing can own subscription status, while the CRM owns account ownership and sales notes. Connecting the systems does not decide which value wins when they disagree.
Integration moves or exposes information between systems. Automation applies rules or actions, often using integrated data. Software integration focuses on applications and their information, while broader system integration can also include infrastructure, networks, databases, and hardware.
What software integration means in practice
A working integration has a source, an event or schedule, a mapping, processing rules, a destination, and an outcome when processing cannot complete. A rejected update should be visible to someone who can correct it or safely replay it, rather than disappearing into a connector log.
In the billing-to-CRM example, billing sends a status change, the integration checks the customer identifier and allowed status values, and the CRM receives the mapped update. A CRM or integration owner reviews rejected records. Ownership is a decision about each field, not a property automatically settled by connecting applications.
A reliable integration defines what moves, who owns each field, and what happens when a write fails.
Choose an integration pattern by behavior, not by label
Native connector, iPaaS, API, webhook, and file exchange are overlapping implementation concepts, not a universal taxonomy. A connector or integration platform may use APIs and events internally, while a file describes a transfer pattern. Begin with documented coverage, then check direction, trigger timing, objects, fields, permissions, and recovery behavior.
- Native connector: Use one when its supported objects, fields, directions, permissions, and conflict rules fit the process. Availability does not mean every record or field synchronizes automatically.
- iPaaS: Use one when a workflow crosses supported SaaS applications and its connectors, plan limits, transformations, and failure controls fit the job. Verify the specific trigger and action.
- Custom API: Use one when you need control over relationships, security, transformation, validation, or error handling that a connector does not provide. Confirm the current endpoint, version, scopes, and limits.
- Webhook, polling, or file exchange: Use a webhook for event notification when the source supports it and the receiver can handle repeated delivery. Use polling when events are unavailable and scheduled delay is acceptable. Use files for batch, legacy, or offline workflows.
Two-way synchronization requires field-level ownership, conflict rules, change detection, and loop prevention. Two separately configured workflows in opposite directions do not create a safe sync automatically. Behavior also depends on the specific connector, app versions, plan, objects, mappings, permissions, and trigger settings. Verify current vendor documentation before launch.
If the documented connector cannot express the required field ownership, validation, or recovery path, do not compensate with a second uncoordinated workflow. Move to an iPaaS or custom API design that can enforce those controls.
Define the data contract before connecting systems
Inventory the objects and fields that will move, their data types, identifiers, sensitivity, and update frequency. Record one source of truth per field. For example, billing may own subscription status, while the CRM owns account ownership. Specify permitted direction and conflict behavior for every mapped field, including what happens when an older source update arrives.
A field map should record the source field, owner, destination property, direction, transformation, required status, and conflict rule. These CRM systems support considerations help teams make matching rules and exception ownership explicit before records start changing.
Normalize values before writing. Check that identifiers are present, types match, required fields exist, values belong to allowed sets, and the integration identity can write the destination property. Do not silently convert an unknown status or make a partial update when a required field is missing. Route the record to an exception queue with its source identifier and a reason for rejection.
Use deterministic rules for exact identifiers, permissions, required fields, routing thresholds, and compliance gates. AI can help classify ambiguous text, but its output should be constrained and reviewable. For example, an AI step might suggest a support category and quote evidence from a message. A fixed allowed-value check decides whether to route it, while a person reviews uncertain or consequential cases. A confidence score alone is not authorization to update a high-impact CRM field.
Four integration patterns in operational use
The examples below distinguish documented vendor behavior from proposed implementation designs. The input and output fields are illustrative contracts, not vendor-published schemas.
| Pattern and trigger | Processing and validation | Destination action | Fallback |
|---|---|---|---|
| HubSpot and Salesforce Configured record creation, update, import, or activity trigger |
Check eligible subscriptions, connected-user permissions, object and field mappings, matching rules, and field ownership | Synchronize supported records and mapped properties according to configuration | CRM or integration owner reviews permission, mapping, API-limit, and duplicate exceptions |
| Google Sheets to HubSpot User selects rows or a range and starts an import |
Check extension permissions, headers, required properties, identifiers, and manual or AI-assisted mappings | Import contacts into HubSpot and access CRM records through the Sheets side panel | Correct ambiguous mappings or incomplete rows before import; do not assume reverse sync |
| Zapier trigger to action Supported new or updated event, polling or instant depending on the app |
Check source ID, required fields, filters, historical-record behavior, and destination duplicate controls | Run one or more configured actions, such as creating a CRM task | Review failed runs, correct the cause, and replay only with duplicate protection |
| Make custom webhook Sender posts JSON, form-data, or query-string input |
Protect the endpoint and explicitly check authentication, structure, required fields, and event identity | Pass validated data to a CRM, task queue, or review path | Reject malformed input and retain repeated downstream failures for review |
HubSpot and Salesforce: HubSpot documents an ongoing, configurable two-way integration for supported records. Installation alone does not synchronize every record. Imports, configured triggers, mappings, subscription eligibility, and the connected Salesforce user’s permissions affect behavior. HubSpot documents synchronization checks approximately every 15 minutes in addition to event-based triggers. Test each object and field rule separately, and assess duplicate risk before using Smart Transfer and the Salesforce integration together. See HubSpot’s Salesforce integration setup guidance and its record import and synchronization guidance.
Google Sheets and HubSpot: HubSpot documents importing contacts from Sheets and accessing CRM records in a Sheets side panel. A user selects rows or a range, maps columns to properties, and imports. The extension includes an AI-assisted mapping option, but a person should review ambiguous or consequential suggestions. The documentation does not establish a general continuous two-way database sync. See the HubSpot for Google Sheets instructions.
Zapier: A proposed workflow could receive a new support request, check for a source record ID, classify ambiguous message text into a fixed category, and create a CRM task only when the category is allowed. The AI output should contain a proposed category and evidence text, not decide identity or permissions. Zapier documents a trigger and action model. Trigger timing and historical-record behavior depend on the selected app and trigger, while bidirectional behavior requires separate flows and loop controls. Teams needing Zapier automation support should define these conditions and the failed-run owner before publishing.
Make webhook: A proposed sender can post an event containing an event ID, customer ID, and message text. The receiver should protect the URL, check the payload shape and required values, persist the event ID, and only then pass validated data to a CRM or human-review queue. Make documents JSON, form-data, and query-string inputs, and distinguishes webhook setup methods that validate against a defined data structure from methods that do not. The webhook alone does not establish authentication, deduplication, retry policy, or approval. See Make’s custom webhook documentation.
Prevent duplicate writes and make retries safe
Identify the grain of each record before choosing a key. An event record represents one event, not one calendar day or workflow run. A useful event identity combines source system, source event ID, and, where needed, event type. Keep event state separate from later daily summaries or other aggregates.
{
"source_system": "billing",
"source_event_id": "evt-9137",
"event_type": "subscription_updated",
"external_customer_id": "cus-712",
"processing_status": "pending"
}The sample is an illustrative event-level record. Persist its identity and processing status so a repeated delivery can return the recorded outcome or resume safely. For a CRM write, retain the destination record ID, attempt time, and categorized error. HubSpot documents import matching identifiers and custom unique-value properties for supported records, but API-created records do not necessarily follow the same automatic deduplication behavior as imports or UI-created records. Check the relevant record deduplication guidance and import identifier guidance.
A lookup followed by a create is not race-safe. Two workers can both find no record and then both create one. Where concurrency matters, prefer a destination-supported unique property, transactional upsert, or database-enforced unique constraint. Treat a duplicate-key conflict as a possible already-processed event only after verifying the existing record. Store the source ID on the destination record and separate processing status from business data.
For a proposed inbound order workflow, the unique key should identify the source event before the CRM write completes. A replay should resume or return the prior result, not create another order record. A daily summary needs a different key containing its aggregation date, entity, search set, engine or model variant, and aggregation definition. A citation-level record likewise needs a citation identity plus its observation or run ID when multiple citations can come from one source.
Validate, monitor, and own exceptions
Classify failures by the action an operator should take:
- Retry: transient network failure or rate limit. Use bounded exponential backoff with jitter and respect a supplied Retry-After value.
- Correct and replay: fixable mapping or source-data issue. Preserve the original event and record the correction before replaying.
- Manual review: ambiguous business value, conflicting ownership, or repeated failure that needs a decision rather than another automated attempt.
Before an API write, verify the current supported version, endpoint, scopes, field types, required fields, field allowlist, stable identifier, and permissions. HubSpot uses date-based API versions, and its 2026-09 API version applies documented CRM write-validation rules to certain administrator-configured requirements. Treat a validation rejection as an expected outcome, capture enough detail to identify the failed field, and correct the contract or record before replay. See the HubSpot API reference and its CRM API write-validation announcement.
For webhooks, record receipt separately from successful downstream processing. Acknowledge promptly when the sender requires it, then process asynchronously when appropriate. Retain delivery and processing status and provide a dead-letter or manual-review path for repeated failures. Monitor failed writes, duplicate conflicts, synchronization lag, retry volume, and unresolved exceptions. Assign a named operational owner.
- A stable source record or event identifier is stored at the correct row grain.
- Every mapped field has an owner, permitted direction, transformation, and conflict rule.
- Required fields, types, permissions, allowed values, and sensitive-data rules are checked before writes.
- A unique constraint, transactional upsert, or vendor-supported unique property prevents concurrent duplicate creation.
- Credentials use least privilege, tokens are protected, and logs do not expose sensitive payloads.
- A named owner can correct, replay, pause, or manually review exceptions.
Estimate effort without false precision
Effort depends on scope, API quality, data condition, object relationships, permissions, security review, testing, monitoring, and ongoing support. Separate connector or platform subscription costs from discovery, build, migration, testing, incident response, and future API maintenance. No universal price or timeline applies across connectors and custom integrations.
Estimate against deliverables: an agreed field map, tested authentication, a representative data run, verified failure handling, production monitoring, and an operational handover. Reassess if discovery exposes poor data quality, unsupported fields, permission constraints, or API behavior that changes the design.
A practical rollout sequence
Use a limited pilot to confirm that the data contract and exception process work before expanding scope. A small discovery run can test the actual handoff and expose constraints before the team commits to a broader implementation. Systems and operations consulting can help teams map that process before selecting automation.
Use those operational measures to decide whether the integration is performing as intended. The goal is not merely to move data, but to make the handoff understandable, recoverable, and owned.