How a Self-Service Data Portal Solved Multi-Language and Domain Value Chaos in ERP Data
Summary
- Enterprises running large, multi-country ERP systems often extract data that is technically complete but practically unusable, split across duplicate language columns and encoded with undocumented numeric values.
- We built a self-service data platform on Azure so that business users, not just data engineers, could define, validate, and process ERP extracts without writing a single line of code.
- The solution resolves two of the most common ERP data problems: a single field like “Item Description” spread across nine language-specific columns, and reference fields like “Order Status” stored only as numeric codes.
- A custom web portal puts business users in control of table specifications, validation rules, and processing status, while Azure Databricks and Delta Lake quietly do the heavy lifting behind the scenes.
- Business impact: dozens of ERP tables moved from raw, multi-language, code-heavy extracts to a single, trusted, human-readable data layer, without adding headcount to the data engineering team.
Table of Contents
About the Customer
Customer Spotlight
A Leading Digital Transformation Partner — Europe
Our customer is a leading enterprise headquartered in Europe, operating across diverse manufacturing and supply chain divisions. Having already standardized their ERP data through a medallion architecture on Databricks, leadership wanted to go a step further: not only manage ERP data at scale, but also connect it seamlessly into process mining tools to uncover how core processes truly perform in practice. The focus was on gaining operational clarity into workflows such as purchase order management, invoice handling, and procurement cycles.
The Challenge
Most organizations extracting data from a large ERP system successfully get the data out. The problem isn’t extraction, it’s making that data mean something the moment it lands. Business and IT teams found themselves asking the same questions on repeat:
Two problems came up again and again, and both are far more common across ERP implementations than most leadership teams realize.
Multi-Language Columns
Because the ERP system was configured for every Order Status the business operates in, a single logical field such as “Item Description” existed as up to nine separate columns, one per language: English, French, German, Spanish, and more. Reports built directly on top of the raw extract had no reliable way of knowing which column to use for which record. In practice, this meant a plant manager in France could open a report and see item names in German, while a sales report for the Spanish market silently pulled blank fields because the Spanish-language column hadn’t been populated for that record. The data was all there; it just wasn’t usable without someone manually deciding, table by table, which language column to trust.
Undocumented Domain Values
Reference fields like Country, Currency, and Order Status were stored as raw numeric codes rather than readable labels, for example Order Status: 1 = Completed , 2 = In Progress, 3 = Shipped. These mappings lived inside ERP configuration screens, not in the extracted data itself. That meant every downstream report, dashboard, or spreadsheet needed its own copy of the same lookup table, manually kept in sync. When a code changed or a new Order Status was added in the ERP, there was no guarantee every report using it would be updated at the same time, which meant leadership could be looking at the performance chart that was quietly wrong.
The Solution
Rather than writing custom transformation logic for every table (a solution that ages badly the moment a new table or region gets added), we designed a configuration-driven pipeline built on Azure Databricks, fronted by a self-service web application that puts control directly in the hands of business and functional users.
Self-Service Web Portal
Business users upload table specifications, review validation results, and queue tables for processing, entirely through a browser.
Medallion Architecture
Azure Databricks and Delta Lake refine raw extracts through Bronze, Silver, and Gold layers, without table-specific code.
Automated Language Resolution
Multi-language columns are detected and normalized automatically based on the specification, not hardcoded per table.
Centralized Domain Mapping
Numeric and coded reference values are resolved against a single, maintained lookup layer instead of scattered spreadsheets.
Self-Service Data Onboarding: No Databricks Knowledge Required
The centerpiece of the solution is a custom web application that lets a business or functional analyst, not a Databricks engineer, onboard a new ERP table from start to finish. Here’s what that looks like in practice:
- A business user uploads an Excel-based table specification defining the expected columns, data types, which fields are multi-language, and which fields are domain-coded and how to decode them.
- The portal validates the specification instantly, flagging missing mandatory columns or mismatches before any data is processed, so problems are caught at the source rather than three reports downstream.
- Once validation passes, the same user queues the table for processing with a single click. No notebook to open, no cluster to configure, no code to write or review.
- Behind the scenes, that specification feeds a generic, reusable Databricks framework that already knows how to apply the correct language resolution and domain-value decoding rules, so engineering effort doesn’t scale linearly with the number of tables.
In effect, the portal turns “add a new ERP table to the analytics environment” from a data engineering request into a form a finance or operations analyst can complete in minutes, while still enforcing the same rigor and consistency a hand-built pipeline would require.
Medallion Architecture on Databricks
Once a table is queued through the portal, Azure Databricks takes over:
- Bronze: Raw ERP extracts are landed as-is, preserving a full audit trail back to the original file.
- Silver: Data is cleansed and standardized, multi-language columns are normalized based on the specification, and domain codes are resolved into readable labels.
- Gold: Business-ready, fully modeled Delta tables are published for reporting, analytics, or downstream tools.
Because the framework is driven by configuration rather than table-specific code, the same pipeline can just as easily onboard data from other sources, additional ERP modules, SFTP feeds, or other cloud storage, without a rebuild.
Business Impact
| Before | After |
|---|---|
| Multi-language fields required manual, table-by-table interpretation | Language columns automatically normalized based on a business-defined specification |
| Domain codes decoded from scattered, out-of-sync spreadsheets | Centralized, auditable domain-value resolution maintained in one place |
| New ERP tables required a data engineering ticket and development cycle | Business users onboard new tables themselves through a self-service portal |
| No visibility into validation issues until reports broke downstream | Validation happens at upload, before any bad data enters the pipeline |
| Custom code required per table | One reusable, configuration-driven Databricks framework for all tables |
Frequently Asked Questions
1) Do business users need any technical or Databricks knowledge to use this?
No. The entire onboarding and validation experience happens through the web portal. Databricks runs entirely behind the scenes.
2) Can this approach work with ERP systems other than the one in this example?
Yes. The framework is configuration-driven rather than hardcoded to a specific ERP, so it can be adapted to other ERP platforms, file formats, or source systems.
3) How is data quality enforced if non-technical users are onboarding tables?
Every specification is validated against mandatory fields, data types, and formatting rules before a table can be queued for processing, so quality checks happen before data enters the pipeline, not after.
4) Can the same framework support additional languages or new domain codes later?
Yes. Because language and domain-code handling are driven by the specification rather than hardcoded logic, new languages or reference values can be added without changing the underlying pipeline.
Conclusion
Multi-language fields and undocumented domain codes are two of the most underestimated barriers to trustworthy ERP reporting. By pairing a configuration-driven medallion architecture on Azure Databricks with a self-service web portal, this organization turned ERP data onboarding from a recurring engineering project into a business-user task, without sacrificing data quality or auditability along the way.
Turn Your ERP Data into Actionable Insights
Looking to make multi-language, multi-format ERP data usable for reporting and analytics, without a heavy engineering lift for every new table? Our team helps organizations build self-service data pipelines on Azure that turn raw ERP extracts into trusted, business-ready datasets.
Connect with Us