Daily catalog sync between the lab system and Magnolia, without duplicating the master data

When a catalog that already exists in a management system has to be published on a website, IT always raises the same objection, and it is a fair one: nobody wants a second place where the catalog gets edited.

The risk is not technical but governance: if the CMS allows editing a field the system also owns, the next import will overwrite editorial work or the data will drift out of date.

At GDA the catalog is around a thousand tests per brand, owned by the laboratory's internal system.

• Two sources of truth: the same test editable in two different systems ends up holding two different values.
• Destructive reimports: any naive sync overwrites whatever the content team wrote on top.
• Incompatible language: the technical test name works for running a lab, not for a patient to read.

Without solving that, the catalog project never starts: IT stops it before it begins, and rightly so.

We designed the content model so the laboratory system stays the only source of truth, and Magnolia adds the editorial layer on top without touching it.

The mechanism is an automatic daily sync, with manual refresh when needed, and a strict separation between what gets imported and what gets written.

Daily sync, manual when needed

• An automated process pulls tests from the internal laboratory system every day.
• Manual refresh is available for changes that cannot wait for the daily cycle.

System fields arrive read only

• Data owned by IT reaches Magnolia as read only: visible, publishable, not editable there.
• The source of truth stays in the internal system, and no reimport can overwrite editorial work because there is no editorial work on those fields.

Seeding, which is what solves the language problem

• Editorial fields are born seeded with the system value rather than empty.
• The title, for instance, starts as the technical test name and marketing rewrites it in patient language.
• That rewrite does not touch IT's system and does not get lost on the next sync.

Architecture and technology

• Magnolia CMS with imported fields and editorial fields modeled separately.
• Scheduled daily sync against the internal laboratory system, with manual trigger.
• Read only source fields and seeded initial values on editable ones.

Learn more about catalogs and commerce on Magnolia.

Learn more about software development.

IT's objection was settled by design rather than by agreement: the catalog publishes without a second place to edit it.

Starting point

• Catalog owned by the internal system, with no publishing path to the website.
• Risk of duplicating the source of truth as soon as content moved into the CMS.

Results

• Automated daily sync in operation, with manual refresh available.
• Source fields read only: zero editing surface over system data.
• Editorial fields seeded with the source value, rewritable with no effect on IT.

Strategic impact

• IT keeps governance of the catalog and marketing gains a layer of its own on top.
• The model is reusable for any master data already living in a management system.