Your data warehouse holds what your systems know. Who holds the rest?
Most companies have put a lot of work into their data warehouse. Orders from the ERP, invoices from the finance system and tickets from the support tool arrive every night in a format everyone knows, and anyone with access can query them.
But the warehouse only has what the systems record, and most reports need something on top of that.
Data that doesn't come from any system
Take revenue by region. The orders are in the warehouse, but the regions aren't. Somebody has decided that SE, Sverige and Sweden are the same country and that the country belongs to the Nordics, and that decision isn't stored in any source system.
Most companies have a lot of this kind of data: which line in the group report each account belongs on, which region and segment each salesperson covers, which category a supplier falls under, and what each division's budget is for next year. It all comes from people who know the business, and it changes when the business changes.
Where it usually ends up
Since no system owns it, it ends up wherever it was easiest to put at the time: a CASE statement in the pipeline, a lookup sheet on a shared drive, a calculated column in Power BI, or an email someone forwarded two years ago.
That works fine until something new comes along. The web shop starts writing Sverige instead of SE, a newly acquired company brings its own chart of accounts, or two salespeople start and nobody updates the territory file. The report keeps running, but part of the revenue no longer has a region, and someone in controlling ends up spending the days before month-end tracking down why.
Where is the rule, and who can change it?
When we talk to controllers and BI teams about this, the same two questions come up every time.
The first is where the rule actually lives. It might be in the SQL, in a spreadsheet or in the report itself, and quite often it's in more than one of them and they don't agree.
The second is who is allowed to change it. The person who knows the right answer usually works in finance or sales, while the person with access to the code works in BI or IT. So a small fix turns into a ticket, and the ticket waits in a backlog for a few days.
Neither question is difficult on its own. The cost comes from answering both of them again for every gap, every month.
What this data needs
The warehouse is a good home for system data. The data people maintain needs a home of its own, and in our experience that home needs a few things to work:
- It should be in one place, so nobody has to go looking for the rule.
- The people who know the answers should be able to change it themselves, without filing a ticket.
- Changes should be controlled, with access per table and row-level security, so a sales manager can update their own team without touching anyone else's.
- Every change should be recorded: who made it, when, and what the old value was.
- The warehouse and the reports should be able to read it like any other table.
- New values that nobody has mapped yet should be flagged when they appear, rather than quietly becoming NULL in a report.
How gridmap handles it
This is the problem gridmap was built for. Your data warehouse holds what your systems know, and gridmap holds what your people know.
Mappings live in gridmaps. A gridmap reads the distinct values from a column in your warehouse, and the business decides what each value means, with AI suggesting the obvious ones. Shared lists such as sales territories or budgets live in registries, where row-level security controls who can see and change which rows. Your reports read both through a join or the API, so the SQL doesn't have to change when the business does.
Gridmap doesn't replace your data warehouse. It sits next to it and looks after the data the warehouse was never meant to hold.
If you'd like to see how it works, our interactive walkthrough takes a couple of minutes. You pick the example closest to your own work, see how it's handled today, and then fix it in gridmap.