When Dropdowns Lie: Why Data Format Doesn’t Determine Authority

I’ve been thinking about why data classification has gotten more confusing over my career, not clearer.

Early on, working with SAP, there was some structure. “System provided values” versus values you configured during implementation. Country codes came from SAP. Sales areas came from you.

But we never articulated why that distinction mattered.

Fast forward to today, and I sit in meetings where experienced data professionals argue for 30 minutes before someone finally asks: “Wait, are we even talking about the same type of data here?”

The confusion is real. And expensive.

After publishing the Authority Rule framework last week – the idea that master versus reference data is fundamentally about authority, not attributes – several people pointed out the exact source of confusion:

The dropdown is lying to you.

Two Identical Containers, Opposite Authority

Open your metadata catalog. Look at everything labeled “reference data.”

I’d bet a significant portion of it isn’t reference data at all.

Here’s what I mean.

Dropdown One: Country Codes

Your system has a country code dropdown:

• GRC – Greece
• DEU – Germany
• USA – United States
• JPN – Japan

You maintain this in your database. You update it when countries change. You synchronize it across systems.

But ISO owns these codes.

I’ve seen what happens when someone decides to “fix” this. A Swedish developer used “SV” for Sweden. Made perfect sense to them – their country, their natural abbreviation.

Except ISO assigned “SV” to El Salvador.

When the company started selling there, they had to give El Salvador a different code. Now there are permanent mapping tables. Every external integration needs special handling. Every new developer gets confused by why Sweden and El Salvador have non-standard codes. The more complex your system estate, the bigger the problem compounds.

The root cause to the problem: they tried to exercise authority they don’t have.

You can’t wake up tomorrow and decide Greece should be coded differently. Well, you can in your internal systems. But ISO still publishes “GRC or GR.” Every other system still expects “GRC or GR”. Every industry standard still uses “GRC or GR.”

You don’t own these definitions. That makes them reference data.

Dropdown Two: Sales Area Codes

Your system has a sales area dropdown:

• UK-Enterprise – UK Enterprise accounts
• UK-SMB – UK Small/Medium Business
• DACH-Enterprise – Germany, Austria, Switzerland Enterprise
• NORDICS-ALL – Nordic countries, all segments

You created these territories. You defined the boundaries. You chose the codes.

Tomorrow, you could:

• Merge UK-Enterprise and UK-SMB into UK-ALL
• Split DACH by industry vertical instead of company size
• Add BENELUX-Enterprise for Belgium, the Netherlands, and Luxembourg
• Rename everything to match a new organizational structure

And everyone in your organization must accept these changes. Your CRM updates. Your reporting adapts. Your sales teams realign. Your compensation plans adjust.

You own these definitions. That makes them master data.

The Format Trap

Look at those two examples again.

Same format: Dropdown list

Same structure: Code + Description

Same maintenance: Regular database updates

Same usage: Referenced across multiple systems

Completely different authority relationships.

This is why format-based classification fails.

For decades, we’ve said:

• Lookup table? → Reference data
• Dropdown values? → Reference data
• Code tables? → Reference data
• Low volume, high reuse? → Reference data

We classified by what data looks like, not by who has the power to define it.

Why I Started Questioning Format-Based Classification

I kept noticing the pattern: meetings where smart people couldn’t agree on classification because they were arguing about different things.

One person focused on format: “It’s in a dropdown, so it’s reference data.”

Another focused on source: “We maintain it, so it’s master data.”

A third focused on usage: “Multiple systems use it, so it’s reference data.”

None of these attributes provided a clear distinction.

I started looking for similarities and differences. What’s actually the same between country codes and sales areas? What’s fundamentally different?

Not the container – both dropdowns.

Not the maintenance pattern – both regularly updated.

Not the importance – both critical to business operations.

The difference is who has the authority to define what these codes mean.

ISO for country codes. You for sales areas.

Once I saw that, everything else fell into place.

What Practitioners Are Discovering

When I published the Authority Rule last week, Mark Berford – an Enterprise Data Architect with over 30 years of experience and DAMA membership – immediately recognized this pattern:

“Traditionally, a list of possible values for a ‘customer type’ master data attribute is defined as reference data rather than master data. However these are still within ‘your’ authority to define, so I’m inclined to call [them master data].”

He’s working through decades of format-based classification and seeing why authority provides the clearer distinction.

Yogesh Poddar, a Product Owner in Digital Transformation, explained where the confusion originates:

“Perhaps the confusion occurs due to the allocation of an additional internal unique identifier to instances of ref data – like Currency or Country codes. This could lead some to believe that since they have allocated their own identifier (to what is external data) that data is to be considered Master.”

The presentation layer – how we store and display data internally – obscures the authority relationship underneath.

The Authority Rule Applied to Dropdowns

Stop classifying by format, instead remember this:

Master: you can redefine it and only you need to agree.

Reference: if you redefine it, the world won’t accept it.

Apply this systematically to your “reference data” catalog:

Reference Data (External Authority):

• Country codes (ISO 3166)
• Currency codes (ISO 4217)
• Tax form codes (IRS, HMRC, etc.)
• Industry classification codes (NAICS, SIC, etc.)

You monitor external changes. You ensure compliance. You can’t redefine them.

Master Data (Your Authority):

• Sales area codes
• Customer type codes
• Department codes
• Product category codes
• Internal project codes

You create, modify, and retire these based on business needs. You can ensure compliance in your company.

The dropdown format is irrelevant. Authority determines classification.

Steps to Improve Your Understanding

Step 1: Audit Your “Reference Data”

Go through your metadata catalog.

For everything labeled “reference data,” ask: “Who has the authority to define what this means?”

External organization (ISO, government, industry body) → Actually reference data

Your organization → Actually master data, misclassified

It wouldn’t surprise me if 40-60% of what’s labeled “reference data” in most enterprises is actually master data hiding in dropdowns.

Step 2: Create Three Categories

Reference Data: External authority defines, you monitor and comply

• Examples: ISO codes, government regulations, industry standards

Master Data: Your authority defines what everyone in your company must follow

• Examples: Customer segments, territories, internal categories

Lookup Data: The presentation format (can contain either type)

• Examples: Dropdown lists, code tables, lookup tables

The Container Is Irrelevant

Dropdowns don’t lie. They present data consistently.

But we lie to ourselves when we assume format determines classification.

The dropdown is the container. Authority is what matters.

Country codes and sales areas look identical in your UI. But you control one completely and the other not at all.

Classify them differently. Govern them differently. Integrate them differently.

Because who has the power to define what something means – that’s the line that actually matters.

What’s Next

This distinction between presentation and authority becomes even more important when examining layered authority relationships:

• Tax codes (reference) vs tax rates (reference) vs tax configuration (master)
• Currency codes (reference) vs trading currencies (master)
• When your master data becomes someone else’s reference through contracts

I’ll explore these complex cases in upcoming posts.

But start with your dropdowns.

Audit what you’ve labeled “reference data.” Apply the authority test. I’d bet you’ll find master data that’s been ignored because it was hiding in a lookup table.

The Authority Rule cuts through format to reveal authority underneath.

And authority – not format – determines what data actually is.

---

This is part of a series on the Authority Rule framework for distinguishing master and reference data. The framework emerged from looking for similarities and differences across domains – the same pattern recognition approach that helped me understand art history, identity systems, and now data classification.

Next week: “Just Because You Master It Doesn’t Mean You Own It” – why maintaining reference data in your systems doesn’t transfer ownership to you.

---

What dropdowns in your organization are hiding master data behind a “reference data” label?

Share your examples – I’m documenting these patterns for a book on the Authority Rule, and your real-world cases might make it into the final manuscript.