Deciding your system of record

A system of record is the one system that is allowed to change a given field. Everywhere else that field is a copy. This sounds like a technical detail and is in fact the single decision that determines whether your integrations are boring or permanently on fire.

The symptom

You will recognise this before you recognise the cause. Somebody in the product team writes a proper description for article 4711-A: 600 words, application notes, the comparison that helps a buyer choose. Two days later it is back to FITTING 3/4 V4A 10BAR, the 40-character line the ERP uses on an invoice.

Nobody deleted it. The nightly ERP feed overwrote it, because the feed carries a description column and the import was configured to write every column it finds. The product team writes it again. It disappears again. After the third time they stop, and the catalog quietly reverts to what the ERP thinks a description is.

The same fight happens over units of measure, over tax classes, over customer addresses. In every case the cause is identical: two systems believe they own the same field, and the last writer wins.

The rule

For every field, exactly one system may write it. Everything else reads it.

Two consequences follow, and both are uncomfortable in practice:

• A read-only copy must be visibly read-only. If a field is owned by the ERP, people must not be able to edit it in the Cockpit. Otherwise they will, their work will vanish overnight, and they will lose trust in the platform rather than in the process.
• Ownership is per field, not per entity. "The ERP owns products" is too coarse and is where most projects go wrong. The ERP owns the SKU, the weight, the tax class and the purchase price of a product. It does not own the marketing description, the accessory relationships or the images.

The field-ownership table

This is the artefact worth producing. Do it on one page, with names on it, before you build anything. A realistic starting point for a B2B wholesaler running an ERP, with the Revenue Cloud as shop and PIM:

Copy this into your own project and change it. The value lies in the argument your ERP team and your product team have while filling it in, which is much cheaper now than after go-live.

Handover: the order case

Orders are the one entity where ownership deliberately moves.

While a buyer is filling a cart and before transmission, the Revenue Cloud owns the order. Nothing in the ERP knows about it yet. At transmission, ownership passes: from that moment the ERP owns the order (its status, its deliveries, its invoices) and the Cloud shows a copy.

Get this wrong in either direction and it hurts. If both sides keep editing, you get a shop order that says "shipped" and an ERP order that says "in clarification". If neither side owns the post-transmission status, buyers phone to ask where their delivery is, which was one of the things the shop was supposed to stop. See The order lifecycle.

When the ERP is not actually the answer

"The ERP is führend" is the reflex in the German Mittelstand, and for transactional data it is right. But it is worth checking two cases:

You already run a PIM. Akeneo, Contentserv, inRiver. Then the PIM owns product information, the ERP owns commercial fields, and the Revenue Cloud is a consumer of both. The mistake here is enriching in two places; see How product information management works.

The ERP field exists but is not maintained. Plenty of ERPs have a Langtext field that is empty on 80% of articles, or a Warengruppe that was last thought about in 2009. A field that formally exists but is not maintained is not a system of record. Somebody has to be responsible for keeping it current, or ownership belongs elsewhere.

Making the decision stick

A table on a wiki page does not stop a nightly job from writing a column. Make it real:

• Map only the fields the source owns. The strongest enforcement is mechanical: if description is not in the mapping, no import can overwrite it. See Field mapping.
• Prefer "create only" over "always update" for fields you are unsure about. Let the ERP seed a name on a new article, and never touch it again.
• Write the owner into the attribute description. The person editing needs to see "maintained in the ERP; changes here are overwritten" at the moment they are about to type.
• Review after the first month. The fields people keep re-editing are the fields you assigned to the wrong owner.

Next

• Field mapping: where the decision becomes configuration.
• Data quality in practice: catching wrong values as well as missing ones.