Third-Party and SaaS Integration Questions

Situation: In a B2B SaaS role, marketing wanted a fast direct sync from our signup form into the CRM so campaigns could launch the same day.

Task: I needed to push back because the shortcut would have sent unvalidated and potentially non-consented data into downstream systems, which created reliability and compliance risk.

Action: I explained the trade-off in plain language: the fast path would save a day or two, but we would inherit bad records, duplicate leads, and possible privacy violations. I proposed a safer design: capture events in an ingestion layer, validate required fields, normalize formats, and only publish approved records. For example, if a user entered a German address, left the marketing checkbox blank, and typed "CA" in a country field, the pipeline would store the event, mark consent as false, mask restricted fields, and block CRM and ad-sync, while still allowing product analytics.

Result: Marketing agreed to a phased rollout. We launched the core sync first, then added the edge cases after validation and consent checks were in place. The outcome was slower by a bit up front, but we avoided rework, reduced bad data in the CRM, and built trust because stakeholders saw the system was reliable and privacy-aware.

Strategy
I would define a single source of truth per data domain, not one for everything. Source of truth means the system that is allowed to make the final decision for a field. For consent and preferences, I would usually pick one authoritative consent service and make the others read-through or replica systems.

Conflict resolution rules

• Prefer the authoritative system for that field, such as the compliance tool for consent.
• Use timestamps only within the same trust tier, not across all systems blindly.
• If two updates conflict and neither clearly wins, keep the last known safe state and queue manual review.
• Store source, timestamp, and reason so every decision is auditable.

Example
If the website records email opt-out at 10:01 and the CRM sends an older preference snapshot at 10:05, I would still keep the opt-out because the website is the higher-trust source for user actions and the CRM update is likely stale.

Practical rule
For each field, I would document who can write, who can read, and how conflicts resolve. That prevents every team from claiming ownership and makes outages much easier to recover from.

Design
I would use a canonical model, which is one shared internal schema that every system maps to. A mapping layer then converts each vendor's field names into that shared shape, so downstream consumers do not need custom logic for every source.

Structure

• Source adapter: CRM, ad platform, analytics tool, or support system
• Canonical customer event: normalized fields like customer_id, email, consent_status, event_time
• Destination adapter: writes to a specific tool in that tool's preferred format
• Mapping catalog: versioned rules that describe field equivalence and transformations

Example
The CRM might send first_name and last_name, the ad platform might send full_name, and analytics may only know anon_id. All three can map into a canonical profile with given_name, family_name, and anonymous_id. A downstream consumer reads only the canonical model, not three different vendor schemas.

Why this works
This keeps vendor churn isolated to adapters, makes validation easier, and gives you one place to handle defaults, type checks, and null rules. If a vendor changes a field name later, only that adapter changes.

Approach
I would resolve identities with a layered matching strategy. Identity resolution means deciding which records refer to the same person. I would use deterministic rules first, then probabilistic rules when the evidence is weaker.

Trust and merge rules

• Treat login-linked identifiers such as verified email or account ID as high trust.
• Treat anonymous cookies as temporary and link them only after a login or strong correlation.
• Prefer source systems that own the data, for example the billing system for account status.
• Keep conflicting attributes as separate fields with lineage when the source is uncertain.

Example
A browser cookie c123 later logs in as jane@example.com and maps to account A77. I would merge those into one person profile because the login creates a strong bridge. If another record also uses jane@example.com but has a different customer since 2021, I would not auto-merge until I verify whether it is a shared inbox or a duplicate account.

Decision rule
Merge when confidence is high and the identifiers form a clear chain. Keep separate when the match could create a false positive, because over-merging is harder to undo than under-merging.

Trace the issue
I would trace the record at each hop using a correlation ID, which is a unique identifier carried through logs and events. Then I would compare counts at every boundary: source emitted, ingestion received, transform accepted, warehouse loaded, report queried.

What I would inspect

• Structured logs for dropped records or filter rules
• Traces for latency spikes or retries
• Checkpoints or offsets in the queue or stream
• Destination row counts and partition counts
• Quarantine tables for records rejected by validation

Example
If the source sent 1,000 records, ingestion received 1,000, and the warehouse loaded 998, the problem is likely in transformation or load. If the warehouse has 1,000 but the report shows 998, the issue is probably the report filter, not the pipeline.

Automated validation
I would add contract tests for payload shape, replay tests against saved real events, and synthetic canary records that must appear end to end. I would also alert on count drift, not just on API errors, because a healthy API can still lose business data silently.