Integration Design
Part of Marketing technology integration design
Comparing native connectors with an integration platform
Compare native connectors and integration platforms by coverage, field control, recovery, access and maintenance.
Compare a native connector and an integration platform by the work each route must perform after connection: mapping, corrections, monitoring, recovery and later changes. A native route may be simpler for a supported product pair. A platform may help when a flow needs several endpoints or rules the native route cannot express. Check these abilities in the proposed setup; neither label guarantees them.
Compare the same hand-off
Describe one required result before examining products. Suppose a corrected enquiry source must reach the matching sales record before a weekly review. Define the record identifier, correction rule, deadline and response to a rejected update. Ask how each route handles a new record, an existing match and a failure.
| Question | Native connector | Integration platform |
|---|---|---|
| Coverage | Does the product pair expose the required objects, fields and triggers? | Are the required endpoints, actions and APIs available? |
| Control | Can its sync rules express the agreed field owner? | Can the configured flow transform values and prevent unintended writes? |
| Recovery | Where are errors, retries and historical loads handled? | Who monitors runs and resolves failed actions? |
| Access | Which subscriptions and permissions are needed? | Which platform licence, endpoint access and environment policy apply? |
| Maintenance | Who checks changes to the native connection? | Who maintains the flow, credentials and dependencies? |
Ask for the exact proposed editions, permissions and configuration. A product page can frame the questions but cannot show how the organisation's records will behave.
Native example: HubSpot and Salesforce
HubSpot documents synchronisation of supported contacts, companies, deals, activities and other data with Salesforce. Its mapping settings include a sync rule that prefers Salesforce unless blank, and a mapping can be set to Don't sync. This route is relevant when those two products and their supported objects cover the required exchange.
The connected Salesforce user's permissions constrain the sync. HubSpot requires a Salesforce edition with API access or Salesforce Professional, along with a system administrator user who holds the object permissions for the records you want to sync. Field mappings also depend on compatible types, object access and API exposure. Check the proposed fields, historical load and error view before calling the route complete.
Key Requirements for HubSpot & Salesforce Sync
- Required Salesforce Edition
- Salesforce Professional or higher with API access
- User Permissions
- System administrator with object-level access
- Field Mapping Constraints
- Compatible types, object access, and API exposure required
Platform example: Microsoft Power Automate
Power Automate can be considered when a team needs to build and operate a flow with explicit actions and failure handling. Microsoft's Salesforce connector documentation classifies the connector as Premium for Power Automate and requires Salesforce API access. It lists unsupported field and object cases. That documentation establishes a Salesforce endpoint, not a finished flow to another marketing tool; confirm the other endpoint and every required action separately.
Microsoft documents error-handling options, including Run after settings that determine what happens when an action fails, times out or is skipped. It also documents platform and connector limits and administrator data policies that can restrict connector use. Confirm the proposed licence, environment policy, service limits and owner of the running flow.
Microsoft Power Automate: Key Configuration Needs
- Salesforce Connector Tier
- Premium (requires licence)
- API Access Requirement
- Salesforce API access must be enabled
- Error Handling Options
- Run after settings for failure, timeout, or skip scenarios
- Service Limits & Policies
- Admin-defined policies may restrict connector use
Choose with an exception case
For each proposed route, request a normal record, a correction and a failed destination update using safe sample data. Record what was shown, what needed an administrator and what remained unverified. Include the work of operating either route, without treating public feature pages as a price quote or a product test.
Choose the route that meets the hand-off with an operating burden the organisation can manage. If neither proposed setup shows a safe conflict rule or recoverable failure, resolve that gap before connecting live customer data.
