Merging companies that each run Salesforce must consolidate their customer data into a single organization while both source systems remain in use. This requires reconciling different schemas and picklists, resolving duplicate customers across and within organizations, preserving relationships between records, and keeping the target current until cutover. This article proposes a reference framework for an autonomous extract-transform-load pipeline for this task. It combines partitioned bulk extraction, declarative mapping templates, rule-based and statistical quality gates, master data management with deterministic and blocked fuzzy matching, constrained loading with per-record error capture, and change data capture guarded by a data-health circuit breaker. Each stage is mapped to Jitterbit Integration Studio constructs. The framework was implemented as an open reference prototype and evaluated on synthetic two-organization scenarios with known ground truth at three scales, from 32,040 to 383,973 source records, over five random seeds. At a preset threshold, hybrid matching reached pairwise F1 scores of 0.918 for accounts and 0.885 for contacts; calibrating the threshold per object would raise these to 0.938 and 0.963. The quality gates prevented all load failures and all silent loss of unmapped picklist values without wrongly flagging any clean record, whereas removing them produced about 1,000 load failures per run. Over five simulated days of hourly incremental synchronization, replayed events were ignored, an injected upstream fault was contained in the batch in which it occurred, and the target agreed with a full rebuild on more than 99.3 percent of field values. Validation on a production deployment remains future work.
Figures & tables
Figure 1: Reference architecture. Numbered stages run in the orchestration layer (Jitterbit operations in a production deployment; the Python reference prototype in this study). Rejected and held records go to quarantine with audit entries; the crosswalk records lineage from source to golden identifiers.
Stage
Purpose
Main output
Controls
1 Extraction
Capture a baseline snapshot of each source object
Compressed staged shards partitioned by creation year
Partition keys; parallel workers; shard manifest
1b CDC intake
Capture creates, updates and deletes after the baseline
Ordered micro-batches of change events
Event identifiers; idempotent skip of replays
2 Transformation
Map each org’s schema, picklists and formats to the canonical model
Canonical records with normalized match keys
Versioned templates; unmapped values flagged, never defaulted
3 Quality gates
Stop records that would break target rules; flag statistical outliers
Accepted records; quarantine with audit entries
Rule catalog; outlier fence; hold of children whose parent is quarantined
Table 4: Pairwise matching quality at τ = 0.85 (mean ± standard deviation over 5 seeds)
Figure 2: Precision, recall and F1 of the hybrid matcher as the fuzzy threshold τ varies (mean of 5 seeds). The dashed line marks the pre-set value used elsewhere in the evaluation.
Defect type
Records with defect
Flagged
Detection rate
Invalid e-mail address
1,390
1,390
100%
Reference to non-existent account
1,280
1,280
100%
Missing required name
966
961
99.5%
Negative opportunity amount
615
615
100%
Unparseable date
412
412
100%
Unmapped picklist value
366
366
100%
Table 5: Detection of injected defects by the quality gates (5 seeds pooled; 319,606 source records)
Figure 3: Wall-clock time by pipeline stage at three data volumes (median of three runs on two CPU cores; local computation only, excluding network and API latency).
Measure
32k records
128k records
384k records
Source records
32,040
128,037
383,973
Total time (median of 3)
2.0 s
9.7 s
39.1 s
Throughput
16,183 rec/s
13,178 rec/s
9,827 rec/s
Account pairs compared
125,984
2,001,702
18,910,752
Golden accounts / contacts
4,963 / 13,319
19,847 / 53,157
59,571 / 158,894
Records unaccounted for
0
0
0
Table 6: Batch pipeline results by scale
Figure 4: Share of contact updates with a blank e-mail address in each CDC batch. The first 24 batches form the baseline profile; the injected upstream fault in batch 83 was detected and held.
Comparison
Records compared
Agreement
Opportunities: identical set of records
46,078
Yes
Opportunities: amount and stage values
46,078
100%
Contacts: golden field values per source record
57,392
99.94%
Accounts: golden field values per source record
23,750
99.36%
Contact clusters: pairwise precision against rebuild
57,392
0.994
Contact clusters: pairwise recall against rebuild
57,392
0.999
Table 7: Agreement between the incrementally synchronized target and a full rebuild from the final source state
We built and evaluated a self-serve entity resolution (ER) system on six benchmarks spanning 864 to 5M records, and three lessons emerged that are absent from existing ER literature. (1) No single matching algorithm wins everywhere - a self-serve pipeline cannot predict its next dataset, so we recommend training several algorithm families per dataset and letting an automatic bake-off pick the winner. (2) Precision and recall need separate fixes, not a shared threshold - precision needs hard rule-based vetoes, recall needs more diverse candidate retrieval. (3) One false-positive link can silently merge unrelated entities - assuming "A matches B" and "B matches C" implies "A matches C" lets a single bad link chain hundreds of records together, so every cross-group merge must be actively re-verified. We hope these lessons save practitioners the months of dead-end experiments that led us to them.
Data integration is the process of combining data from multiple, heterogeneous sources into a consistent, unified representation. Data integration involves a sequence of interdependent tasks including schema matching, value normalization, blocking, entity matching, and data fusion. Existing table-based benchmarks either evaluate these steps in isolation or cover only incomplete versions of the data integration pipeline, omitting specific steps. The lack of public end-to-end data integration benchmarks hinders research on data integration methods that address the integration process as a whole and account for the interdependencies among the different tasks. This paper fills this gap by introducing the Mannheim Data Integration Benchmark (MaDI-Bench), the first benchmark for the end-to-end integration of relational tables covering all steps of the integration process. MaDI-Bench contributes (i) a set of end-to-end data integration tasks spanning several application domains, each requiring the full schema matching, value normalization, entity matching, and data fusion pipeline, and (ii) a generic method for deriving task variants that mitigates rapid benchmark saturation as data integration systems advance. We validate the benchmark using human-engineered pipelines, a best-of-breed pipeline, an LLM workflow, and a pipeline written by a coding agent. The validation demonstrates the utility of the benchmark for measuring the step-wise as well as the end-to-end performance of data integration pipelines. All benchmark artifacts are available for public download.
Aaron Steiner, Ralph Peeters, Christian Bizer
Data and Web Science Group University of Mannheim Mannheim, Germany
The goal of schema integration is, given a set of input schemata or tables, to derive a global, unified schema that is able to represent the concepts, attributes, and relationships of all input tables in a coherent fashion. This paper presents SINT-Flow, a schema integration framework composed of five LLM-based operators that can be combined into workflows to perform fully automated, end-to-end schema integration. In contrast to existing approaches, SINT-Flow can process denormalized source tables that contain attributes describing multiple entity types. During the schema integration process, these tables are decomposed into separate entity-specific relations. To evaluate SINT-Flow, we introduce SINT-Bench, a schema integration benchmark comprising 10 schema integration tasks consisting of altogether 93 relational tables, including tables that describe multiple types of entities. We evaluate SINT-Flow using GPT-5.2 as well as the open-weight model Qwen-3.6-27B as alternative backbone models. Using these models, SINT-Flow achieves a Completeness rate of at least 97% in entity type detection, 81% for attribute detection, and an F1-score of 84% for schema mapping. Furthermore, we perform an ablation study to prove the utility of the applied self-consistency strategy as well as the inclusion of a review loop into the Schema Matching Operator.