Marketing Data Integration:
Catch Missing Data

A person fills out a demo form, receives a welcome email, and later speaks with sales. The marketing report still calls that person a new lead; the sales system shows an active opportunity; the advertising audience may still include them. Connecting the form, email tool, customer relationship management system (CRM), and reporting destination sounds like the obvious fix. Yet a connection only moves information. It does not decide which record is right, how quickly a change must travel, or what the receiving system should do with it.

Marketing data integration is the deliberate exchange of defined marketing and customer records between systems so that a particular decision or action uses the information it needs. For the demo form, the useful question is not “How do we connect everything?” It is “Which change must reach which system, by when, and what happens if it does not?” That question leads to a smaller, more dependable design than a general promise to keep every field in sync.

I would start with the action that currently goes wrong: perhaps sales cannot see the form submission before a call, or a campaign report counts the same person twice. The answer may be a prompt update to the CRM, a scheduled transfer into reporting, or both. Those are different jobs. Combining them into one undifferentiated flow makes ordinary delays look like defects and genuine defects harder to find.

Start with the decision the data must support#

Before choosing a connector or platform, write down one exchange in plain language. Identify the source record, the receiving system, the fields to move, the direction, the expected number of records, the frequency of change, the maximum useful delay, and who can access the result. Microsoft’s integration requirements guidance frames design around volume and frequency, direction, and the capabilities of each system. Those dimensions matter because the destination cannot process a fast stream merely because the source can send one.

Take an illustrative campaign in which a form submission should appear in the CRM before the next sales review, while a campaign performance report is read the following morning. If the sales review happens within minutes, an overnight CRM import is too late. If the report is read once a day, maintaining a second-by-second reporting copy adds work without improving that decision. The required delay belongs to the business action, not to a vague preference for “real time.” Microsoft’s pattern guidance likewise describes scheduled consolidation where immediate updates are unnecessary and warns against demanding immediate synchronization without a reason.

Volume deserves the same specificity. “Many leads” does not say whether the system sees a steady trickle, one large import each evening, or a surge after an event. A daily total can conceal a short peak that exceeds the receiving system’s capacity. Estimate records per interval for ordinary days and likely peaks, then confirm what each system can actually send, receive, and process. Microsoft notes that the same hourly record count can create different designs when it arrives at different frequencies in its requirements discussion.

The first deliverable can be a short exchange description: “When a demo form is submitted, send its form identifier, contact reference, submission time, and requested product to the CRM within the time the sales team needs; send a daily summary to reporting.” The field names and timing here are illustrative, not a universal schema. The value of the description is that a team can compare any proposed connection against it. If the CRM cannot accept updates at the required rate, the design must change or the timing expectation must be renegotiated.

Decide who can change each field#

The most damaging integration errors often start with two systems believing they own the same value. In the illustrative flow, the form creates a request, the CRM tracks the sales stage, and the email tool records activity in its own campaigns. If a CRM stage is copied into the email tool, the email tool should not later write an older stage back to the CRM. The exchange needs a named source for each field and a rule for what happens when values disagree. A two-way connection without such a rule can keep moving a conflict around.

I would record direction at field level where it matters. A contact’s work email might be updated in the CRM, while a form submission time originates in the form service. A campaign report may need both but should not become the place that edits either. This distinction follows from Microsoft’s treatment of directionality: where information originates and where it is delivered shapes the integration. It also makes correction practical. When the wrong stage appears in a report, the team knows which system to fix and which transfer to rerun.

The record key needs equal care. An email address is useful for communication, but treating it as the sole enduring identity is a design choice with visible consequences: an address can be corrected, shared, or entered differently. For the illustrative flow, keep the source record identifier alongside the receiving record identifier and define how a new form submission finds an existing contact. When a match is uncertain, route it for an explicit decision instead of quietly creating or merging a person. Salesforce’s integration patterns overview identifies deduplication and data flow design as part of sustainable integration; the exact matching rule still belongs to the organization’s records and use case.

Corrections need a route back through the design. If a sales representative fixes a contact record, decide whether the corrected field should flow to the email tool, how soon, and whether that tool is allowed to overwrite it later. If a person must be removed from a marketing audience, include that change in the exchange description rather than treating removal as an exceptional afterthought. A diagram with arrows is useful only when the arrows say which fields move, which events start movement, and what the destination is permitted to do.

Match the exchange pattern to the moment of use#

There are three distinct questions behind the common request to “sync the data.” Does a person need an answer before continuing? Does another system need to be told that something changed? Or does a team need a combined dataset at a scheduled time? Salesforce’s integration patterns overview separates request and reply, fire and forget, and batch synchronization. Microsoft’s pattern guidance likewise distinguishes event responses, scheduled consolidation, and synchronization. The names matter less than the dependency each creates.

For an on-screen decision that requires a current answer, a request and reply can be appropriate. Imagine a sales user opening a contact and asking a remote system for a current detail before proceeding. The user waits for that remote system, so its delay or outage becomes part of the screen experience. Salesforce describes this pattern as a call that waits for completion and tracks the returned state in its request and reply pattern. I would choose it only when the answer must be current at that moment and the user can be shown a clear failure if it cannot be retrieved.

For an event that can be handled after the user moves on, a notification is a better fit. A form submission can signal that a record changed; a receiver can then process the change without holding the form page open for the full downstream job. HubSpot’s webhooks guide documents subscriptions for CRM events and notifications sent to a receiving endpoint. This is an option when the source offers the relevant event and the receiver can handle delivery, repeat messages, and later checks against the source. “Event driven” should describe the trigger, not promise that every downstream copy is instantly correct.

For reporting, scheduled consolidation is often the cleaner choice. A campaign report may join form submissions, CRM stages, and marketing activity after an agreed interval, then make that combined view available for a morning meeting. Microsoft describes data consolidation as a scheduled way to bring information from several systems together, with the schedule chosen around how people use it. Its cost is that a late change will wait for the next run. State that delay beside the report so its readers do not mistake a time-bounded snapshot for a live operational record.

There is also a choice between fetching data when needed and storing another copy. Salesforce’s overview describes virtual access to external data without persisting it locally. A remote lookup can keep the displayed value current, but it makes the user’s action depend on the remote service. A stored copy can support local use when the source is slow or unavailable, but someone must define how it is refreshed and what happens when the copies disagree. I would copy only the fields and history that the receiving job requires, at the freshness that job requires.

Plan for rate limits, repeats, and missing updates#

The flow is not finished when the first record arrives. An import can be larger than expected, an API can refuse more calls, or a receiver can be unavailable. HubSpot’s API usage guidelines say limits depend on the account and app type, that some APIs have their own limits, and that exceeding a limit produces a 429 response. A design sized around an old or generic limit is therefore a poor bet. Check the provider’s current limit for the actual account and endpoint, then budget for peaks and any calls made during recovery.

If the CRM API is the constrained side, I would reduce unnecessary reads before adding more retries. Send changed fields when possible, use the provider’s batch options where they fit the operation, and avoid fetching static settings for every record. HubSpot’s usage guidance specifically recommends batch APIs and caching repeated reads when appropriate. A retry is useful after a temporary failure, but an immediate loop against a continuing limit only creates more rejected calls. The receiving operation should also recognize a repeated request so recovery does not create a second contact or second activity.

Webhooks need a more concrete rule than “listen for changes.” HubSpot says its webhook notifications can arrive out of order or more than once, and failed deliveries may be retried. Its eventId is not guaranteed to be unique. A receiver using that service should not assume arrival order is the order of customer changes, or use that field alone as a universal duplicate key. It should retain enough source identifiers and event timing to decide whether a notification calls for an update, and compare with the source when the resulting state is uncertain.

That comparison matters after an outage. A notification says a change happened; it is not, by itself, proof that the destination now holds the intended record. Set a regular check for records changed since the last successful exchange and compare counts and selected values with the source. For a demo-form route, a useful check asks whether each accepted submission has a corresponding CRM record or an explicit error awaiting action. The check may use an API or an export, depending on the systems’ capabilities. Its frequency should match the cost of missing an update, not an arbitrary wish to run everything constantly.

Keep errors specific enough for a person to act. “Integration failed” is less useful than a record identifier, the destination, the attempted operation, the response, and the time. Separate failures that can be retried, such as a temporary limit, from records that need a decision, such as an ambiguous contact match. This turns recovery into a defined part of the flow and keeps one bad record from silently blocking every later one.

Move personal data only for a stated purpose#

Marketing integrations frequently involve identifiable people. Before copying fields into another system, ask what that destination must do with each one. If a reporting table needs a campaign, a submission date, and a sales stage, a full contact profile may add exposure without improving the report. The UK Information Commissioner’s Office describes purpose limitation and data minimisation as processing for specified purposes and limiting personal data to what is necessary for those purposes. That is UK guidance; the applicable duties for a particular organization and location require their own review.

Access follows the same question. The person who needs a campaign total may not need a contact’s name or email address. Where individual records are necessary, specify which destination users or services can read them and for how long the copy serves the stated purpose. When the source record is corrected or deleted, decide which receiving copies must change as well. The ICO’s principles guide also addresses accuracy, storage limitation, and security; those concerns become concrete when a copied record persists after its source changes.

I would treat permission related fields as part of the exchange rules rather than an unexamined property of a contact. The question is what the receiving system is allowed to do with the data for the stated purpose. A field arriving successfully does not answer that question. If the organization has not defined the purpose or access for a destination, narrow the transfer until it can.

Build the smallest complete route first#

For the illustrative demo-form problem, I would implement one complete route before connecting every marketing tool: define the submission and contact identifiers, send the necessary fields to the CRM at the required pace, give the CRM authority over the sales stage, record delivery errors, and check that accepted submissions arrived. Then add the scheduled reporting copy with its own fields and refresh time. Each route has a distinct user, timing need, and failure consequence.

This approach costs more thought up front than turning on a broad sync. It also leaves some data deliberately absent from some systems and accepts a stated delay in reporting. I would reverse the timing choice if a specific decision genuinely depended on a fresher value, or expand the copied fields if a named user task required them. The governing question remains concrete: can the intended person make the intended decision with the right record at the right time, and can the team tell when that promise was missed?