
Integration Design
Marketing technology integration design
Design marketing technology integrations around data ownership, timing, failure handling and a checkable business hand-off.
Design a marketing technology integration around a specific hand-off: what must move, who owns it, when the receiving system needs it and what happens if the transfer fails. A connector listing does not answer those questions.
Start with one outcome
Choose a workflow that matters, such as passing a website enquiry to a customer system. Describe a result the receiving team can check: the enquiry reaches the right record with the agreed campaign source and the information needed to act. Include a later correction or opt-out: the first transfer is only part of the workflow.
Name the source, destination and owner of each step. Decide whether the destination needs a whole record, selected fields or an instruction to act. Send only information needed for the agreed purpose.
Agree on the hand-off
Record the decisions both system owners need to understand:
| Decision | What to specify |
|---|---|
| Record identity | How the destination finds an existing record and avoids a duplicate |
| Field meaning | Definitions, formats and allowed values |
| Direction | Which system may create or change each value |
| Timing | The trigger and latest useful arrival time |
| Failure | Where an error appears, who investigates it and how recovery works |
| Change | Who approves a new field, destination or use |
Matching field names do not establish matching meanings. A status field might describe sales progress in one system and marketing eligibility in another.
Plan the initial load separately from later updates.
Confirm operational prerequisites
Treat access and permissions as release dependencies: a workflow cannot be reliably tested or activated if its owners cannot authorise the required connection or inspect the records involved. For example, HubSpot’s Salesforce integration requires HubSpot Account Access, a Salesforce system administrator and a Salesforce edition with API access or Salesforce Professional.
For that integration, required Salesforce permissions include API Enabled, View Setup and Configuration, Modify All on each object selected to sync, Download AppExchange Packages and visibility for the Task Type field.
Modify Metadata is required to view the HubSpot Embed window on Salesforce lead or contact records and to sync deals to HubSpot. Customize Application is required to install the HubSpot Embed window and for its automatic updates.
Confirm that the intended administrators have the required access before scheduling setup and testing. Check feature-specific permissions only if those features are part of the proposed flow.
Integration Requirements from Key Sources
- HubSpot–Salesforce Integration: Required Salesforce EditionProfessional or higher with API access
- Required Salesforce PermissionsAPI Enabled, View Setup and Configuration, Modify All on selected objects, Download AppExchange Packages
- Modify Metadata Permission Needed ForView HubSpot Embed window and sync deals to HubSpot
- Customize Application Permission Needed ForInstall and auto-update HubSpot Embed window
- Power Automate Error Handling GuidanceUse ‘Run after’ settings to direct flows to notifications or logs on failure
- Australian Privacy Principle (APP) 1 RequirementImplement practices to support compliance and maintain an up-to-date privacy policy
Choose timing that fits the task
A scheduled transfer may suit a morning report. An update triggered by an event may suit an enquiry hand-off. Neither pattern guarantees immediate or complete delivery. Copies updated through events can temporarily lag behind their source.
For a planned marketing send, define when the sending system must have a current opt-out. If the proposed transfer cannot meet that point, establish a control before the send. Check the actual trigger, processing delay and destination update before calling a route real time.
Event-Triggered vs Scheduled Transfers: Pros and Cons
- Event-Triggered TransferImmediate response to actions like form submissions; ideal for real-time enquiries. May lag due to processing delays.
- Scheduled TransferConsistent batch updates (e.g., morning reports); easier to manage load. Not suitable for urgent actions.
Make failures recoverable
Consider missing identifiers, invalid values, expired access, rate limits and destination outages. Decide which failures can be retried, which need a corrected record and who receives an alert. A repeated create action can produce a duplicate unless the destination can recognise the record.
Reconcile selected records or counts at an agreed point. A successful flow run shows that the run completed; it does not prove every intended record reached the correct state.
Make recovery observable in the workflow itself. In Power Automate, for example, “Run after” settings can direct a flow to a notification or an error log when an action fails.
A run identifier and relevant error details can support investigation. Microsoft cautions that excessive custom logging and extra workflow actions can negatively affect a workflow, so avoid collecting unnecessary customer information or adding logging steps without a defined operational need.
Define release evidence
Set an acceptance condition that can be checked in both systems, such as confirming that a sample record has the expected destination state after transfer. Include evidence for the failure path as well as the successful path: Microsoft’s Power Automate guidance allows the next action to depend on whether a preceding action failed, timed out, was skipped or succeeded.
Check use and release the flow
Where personal information is involved, have the organisation's privacy owner assess the actual collection, use, disclosure and direct-marketing purpose. For an organisation that is an APP entity, the Australian Privacy Principles apply. A technically available connector does not establish permission for every transfer. Include the route for corrections and opt-outs.
Before activation, use safe sample records to check a new record, an existing match, a correction, a rejected value and a temporary failure.
Release a bounded flow with an owner, monitoring, a reconciliation point and a way to stop further transfers if the output is wrong. Keep the agreed hand-off, configuration and unresolved questions with the workflow so owners can review them when either system or business purpose changes.
Record the release decision against the agreed purpose and the checks that passed, including any limits that remain. If the receiving system cannot be checked or a failure alert has no clear owner, defer activation until those operating conditions are resolved.
Check privacy documentation as well as the flow
For an entity covered by the Australian Privacy Principles, APP 1 requires reasonable steps to implement practices, procedures and systems that support compliance and handling enquiries or complaints. It also requires an up-to-date privacy policy describing the kinds of personal information held, how it is collected and held, and the purposes for which it is used or disclosed.
The policy must also explain how an individual can access and seek correction of their information, how to complain about a privacy breach and how the entity will handle the complaint.
If the entity is likely to disclose information to overseas recipients, it must describe that likelihood and, where practicable, the countries involved. Check that the documented purpose and handling arrangements fit the proposed flow before release.
In this guide
- Mapping data flows before connecting toolsMap records, fields, triggers, corrections and failures before connecting marketing tools.
- Comparing native connectors with an integration platformCompare native connectors and integration platforms by coverage, field control, recovery, access and maintenance.
- Defining a source of truth for customer attributesAssign authority for each customer attribute and decide how corrections, conflicts and stale copies are handled.



