Fabric Reference Table & Data Mapping Service

Thanks for sharing this, and for putting a working implementation behind it. Treating lookup tables as data products is the point I’d underline for anyone starting a Fabric build. (Disclosure: I work at Quantexa, which builds Quantexa Unify, a native Microsoft Fabric workload, so pattern 4 is close to home.)

Pattern 4 is where we see teams spend the most effort over time. A crosswalk between crm_customer_id and erp_customer_id starts small and manageable. Once you add a third or fourth system, a couple of acquisitions and records with no shared key at all, someone ends up maintaining matching logic by hand, and the table slowly becomes the junk drawer you warn about in pattern 2.

Unify takes that crosswalk off the to-do list. It runs inside your Fabric tenant on your own capacity, reads source tables from OneLake and resolves the records that refer to the same real-world business or person, even when they share no identifier. The output lands back in OneLake as Delta tables, with one table of canonical entities and one that links every source system and source key to its entity ID. That second table is the pattern 4 crosswalk, generated rather than hand-maintained, and each run refreshes it as new records arrive.

It also lightens pattern 2 for identity data. Unify standardizes names, addresses, phone numbers and emails as part of matching, so you don’t need a normalization table for every spelling of a company name. Country codes, status values and similar domain values still belong in your code-to-code tables.

Patterns 1, 3 and 5 stay exactly where you have them. One small change makes them more useful. Keying customer-level rules and hierarchy assignments on the canonical entity ID means each one applies once per real customer, rather than once per system record.

Your governance fields also suit the one place a person should still have the final say. A steward-owned override table, carrying the provenance and review_status columns you describe, can capture match and non-match decisions and feed them back into resolution. That keeps the who, what, when and why answerable for identity decisions too.

Good to see the Extensibility Toolkit getting this kind of practical use.