Data
When a customer record is a document, stop forcing a table
Offers, device profiles, and journey states are documents. They grow fields. They nest. A rigid table model can still hold them, but the cost shows up in every campaign change: another migration, another null column, another argument about whose schema is source. MongoDB is useful here only if the rest of the estate still recognises the customer.
Innova Core Technologies runs MongoDB work as part of Data, Integration, and Customer Experience programmes, not as a side cluster for a proof of concept that never joined billing. From Riyadh we see the same pattern. Digital wants flexibility. CRM and revenue and billing need a person they can name. If the document invents its own party id, care will spend the next year merging duplicates, and campaign will target both.
Keep the foreign keys boring
The document can be rich. The identifiers must be dull. Account, party, MSISDN, and product keys should match Sugar CRM and RBM even when the payload around them changes every quarter. When they do not, you get two customers and a care call that cannot close. “We will reconcile later” is how later becomes a programme of its own.
Indexes should serve the queries operations actually run: a care lookup, a campaign eligibility check, a nightly extract with an agreed filter. Designing indexes for a demo filter that nobody will use in production is how clusters look fast in week four and expensive in month four. Write down the queries in the same workshop as the collection design. If the query cannot be named, it should not drive a shard key.
Retention is a product decision
Event-shaped history fills disks and complicates subject-access requests. Agree what expires, who may export it, and which index supports the query operations run on a Thursday. That belongs next to collection design, not in a capacity ticket after go-live. Data security is not a different meeting. Who may read a profile, who may dump a collection, what restore is allowed to contain — those are MongoDB questions with security names.
Lower environments matter. A refresh from live that carries production profiles into a test campaign platform is a control failure with a friendly calendar invite. If you must refresh, say what is masked, who approved it, and how long it lives. Copies are still the customer.
Plan the upgrade with CX
A cluster move is not a DBA-only weekend if campaign and loyalty read from it. Freeze windows, rollback, and a test cell of real journeys have to travel together. Software upgrades that skip the CX freeze will be rolled back with customers mid-journey. Testing that only inserts a sample document has not proved the programme. Prove a profile that CRM already knows, a campaign read, a loyalty earn that needs a field from the document, and a restore.
Operating notes are the handover. Which collection is live profile, which is history, who owns a schema change, what to do at two in the morning when a replica is unhappy. If that knowledge leaves with the project team, you did not finish. Certified, repeatable delivery is a cluster operations can explain to a steering committee without opening the vendor kickoff deck.
What we tell programme leads
Use MongoDB where the honest model is a document. Do not use it as a junk drawer for everything that did not fit the warehouse. Keep keys aligned with CRM and billing. Put security and retention in the same design. Sequence upgrades with the journeys that depend on the data. That is the whole argument.
It is also the argument we take into work with operators and integrators we have already sat with, including Systems Arabia, STC, Zain KSA, Mobily, Airtel, Maalim Al Khabra, and Smart Solutions. Flexibility without a shared customer is just a faster way to fragment. If you are about to put CX documents into MongoDB, or the keys have already drifted, request a callback from Riyadh or use Info@innovacore-tech.com.