If “the system” is a house, metadata is the wiring behind the walls. You can ignore it… right up until you’re troubleshooting a lookup, building a flow, or trying to explain to a client why “Status Reason” is not the same thing as “Status.” 😄
This category is for when you need to:
- Look up the truth (logical names, types, relationships, option values)
- Generate documentation (for UAT, support, audits, handoffs)
- Build a data dictionary that doesn’t rely on tribal knowledge and vibes
Pick your weapon (quick decision guide)
-
Need: Look up table/column details fast (logical name, type, relationships, choice values) without playing hide-and-seek in Solution Explorer
Tool: Metadata Browser
Why: Quick truth-checks for flows, scripts, integrations, and debugging -
Need: Export a data-dictionary-style document for UAT/support/handoffs/audits (especially including choice/option details)
Tool: Metadata Document Generator
Why: Shareable artifact that saves time, reduces confusion, and keeps environments aligned
Pre-flight checklist (do this before you go spelunking)
Metadata tools are “read-heavy,” so the risk isn’t “accidentally nuking Production” — it’s misreading what you’re looking at.
- Know what environment you’re connected to (Dev vs UAT vs Prod).
Future You does not enjoy explaining why a logical name “doesn’t exist” when you were just in the wrong org. - Decide your goal upfront:
- “I need the schema name for a flow”
- “I’m documenting the solution for UAT”
- “I’m auditing choice values before a deployment”
- Get consistent about naming:
- Table display name ≠ logical name
- Column display name ≠ schema name
The UI is friendly. Dataverse is literal.
Consultant law #7: if you don’t write down logical names, you will end up screenshotting them like they’re rare Pokémon.
Tool 1: Metadata Browser (the “tell me what this field REALLY is” tool)
What it’s for
Metadata Browser is your fastest path to the truth about tables and columns: types, logical names, relationships, and “what is this field actually called when I’m building a flow / script / integration?”
When to use it
Use it when you need to:
- Find logical names for tables/columns (especially when building Power Automate expressions or JS)
- Confirm a column’s data type (choice vs string vs lookup vs two options)
- Check relationships (is it N:1, 1:N, N:N, and what’s the schema name?)
- Look up choice values so you stop guessing which integer maps to “Approved”
Step-by-step (no drama version)
- Connect to the right environment.
- Search the table (by display name or logical name).
- Find the column you care about.
- Capture what you need:
- Logical/schema name
- Data type
- If it’s a choice: option values
- If it’s a lookup: relationship details
- Paste it into your work item / dev notes immediately (don’t trust your memory).
Common gotchas (aka “ask me how I know”)
- Two columns can look identical in the UI but behave differently (text vs choice vs lookup).
- Choices: labels lie, values don’t. If you document only labels, your future integration will betray you politely.
- Lookups: “Account” in the UI might be referencing a table you didn’t expect (especially in multi-solution orgs).
Validation checklist (prove you got the right thing)
- Use the logical name in your flow/script and confirm it resolves (no “property not found” errors).
- If it’s a choice field, confirm the value you documented matches a real record in the environment (spot check 1–2 records).
Real scenario (consultant-realistic)
You’re building a Power Automate condition:
“If Status Reason = Submitted…”
Metadata Browser helps you confirm whether that’s:
- a status reason (integer)
- a custom choice (also integer)
- or a field with a similar display name that’s actually something else entirely
…and it gives you the values so your condition doesn’t silently fail for a week.
Tool 2: Metadata Document Generator (turn your org into a data dictionary)
What it’s for
Metadata Document Generator is how you create a shareable artifact: a documentation export that lists your tables/columns and their details—great for UAT packets, support handoffs, and audits.
Think of it as: “I am done answering ‘what field is that?’ on repeat.”
When to use it
Use it when you need:
- A solution handoff document (what’s in scope, what fields exist, what they mean)
- A UAT support pack (“here’s the schema and expected fields”)
- A data dictionary (especially useful for reporting teams and integration work)
- An audit of choices/options so environments stay aligned
Step-by-step (make it client-friendly)
- Pick your scope:
- Entire org (big)
- Specific solution tables (recommended)
- Specific tables only (most practical)
- Generate the document:
- Include key details that matter in real life:
- display name + logical name
- type
- required/optional
- relationships/lookups
- choices/options (the values!)
- Include key details that matter in real life:
- Polish the output:
- Add a short intro section:
- environment name
- date generated
- scope (which solutions/tables)
- Add a short intro section:
- Publish it alongside your release notes:
- Same place your team actually looks (wiki/SharePoint/project folder)
Common gotchas
- Document scope creep: exporting “the whole org” creates a 200-page novel nobody reads.
Start with solution scope or UAT scope. - Choice fields drift between environments if nobody owns governance.
The doc is your early warning system. - People confuse documentation with requirements.
Add one line at the top: “This is system metadata, not business rules.”
Validation checklist (before you ship the doc)
- Confirm the document includes:
- all tables in your UAT scope
- key columns testers will touch
- option values for key choice fields (status reasons, categories, etc.)
- Spot check 2–3 fields in-app to confirm the doc matches reality.
Real scenario
You’re handing off to a UAT team and the first question is:
“Which fields should we validate, and what are the allowed values?”
You generate documentation scoped to the solution and hand them:
- a clean list of fields
- which ones are required
- what “Approved/Denied/Pending” maps to under the hood
Result: fewer Slack pings, fewer screenshots, fewer “wait which field?” meetings.