An implementation example from operational SaaS work. Company and customer details are omitted.
The situation
An application imported reference records that were also used in project-specific settings. The source data needed to refresh names, codes, and active state. Project administrators also needed to make local decisions about which records applied to their work.
Those responsibilities can conflict. Treat every import as a complete replacement and existing references may be disrupted. Treat an imported default as an instruction to recreate every project mapping and a deliberate local removal may be silently undone.
The decision
I separated the identity of a reference record from its imported values and its project-level use. Matching needed to happen within the correct organization using the relevant business code. Updating a matched record needed to preserve its internal identity and existing relationships.
At the project level, a deliberate inactive setting needed to remain meaningful. An import could supply missing defaults without automatically reversing an administrator’s explicit choice.
The work
The import path used organization-scoped matching to update reference records in place. Source identifiers remained distinct from the application’s internal identifiers.
The project mapping logic checked for an existing inactive setting before applying defaults. Missing mappings could be created, and current defaults could still be applied where appropriate. A deliberate opt-out remained an instruction to preserve the local choice.
The same ownership rule needed to hold across the paths that applied those defaults, including imported mappings and project-setting updates. That kept behavior consistent when the same business relationship was touched from different entry points.
The implemented behavior
Repeated imports could refresh reference data without replacing a matched record’s identity. Project defaults could propagate while explicit local removals remained inactive.
The result was a defined answer to a common integration question: what belongs to the source, and what belongs to the application using it? The record, its imported description, and its local eligibility are related facts with different owners.
If systems are overwriting each other’s decisions or records drift between imported and local state, Integration Architecture can help define the matching, ownership, and reconciliation rules before more exceptions accumulate.