Querying, troubleshooting & analysis

This is the “show me the receipts” category.

When someone says:

• “The record doesn’t exist” (it does),
• “The view didn’t work” (it almost did),
• “The filter is right” (it’s emotionally right),
• or the classic: “It worked yesterday”…

…these tools help you find the truth fast—without clicking around the UI like it owes you money.

Copy/paste troubleshooting checklist (stick this at the top of the article)

The “Don’t Waste 45 Minutes Guessing” Checklist™
Use this every time a view/query/record situation feels cursed.

1) Confirm reality first

• ☐ Right environment (Dev/UAT/Prod)
• ☐ Right user context (admin ≠ end user)
• ☐ You have one known record that should match (ID or unique value)

2) Reduce the problem to one record

• ☐ Start with a query that returns exactly that record
• ☐ If you can’t return the record with a minimal filter, stop—your assumptions are off

3) Add complexity one piece at a time

• ☐ Add one condition → run
• ☐ Add one condition → run
• ☐ Add one link-entity → run
• ☐ If it breaks, the last thing you added is the suspect (interrogate it)

4) Joins: assume the related record is missing

• ☐ Ask: “If the related record doesn’t exist, should the parent still appear?”
• ☐ If yes, your join/filter setup is probably excluding parents unintentionally

5) Don’t trust display names

• ☐ Use Schema Browser to confirm:
  • logical/schema name
  • data type (choice vs text vs lookup)
  • relationship path (A → B direct? or A → C → B?)

6) When results are wrong, pick the likely culprit

• ☐ Too few results → a condition is too strict OR a link-entity is filtering out rows
• ☐ Too many results → missing filter OR relationship logic multiplying rows
• ☐ Inconsistent results → security, multiple forms/views, caching, or environment mismatch

7) Prove it with a before/after comparison

• ☐ Record appears in “minimal query” ✅
• ☐ Record disappears when condition X is added ❌
• ☐ Conclusion: condition X is wrong (operator, entity, value, null behavior)

Tiny reminder: if you can’t explain the result in one sentence, you’re not done yet.

Pick your weapon (quick decision guide)

• Need: Build/debug FetchXML (views, joins via link-entity, portal-style queries) with fast iteration: tweak → run → verify
  Tool: FetchXML Tester
  Why: Tight feedback loop to isolate what’s breaking

• Need: Figure out what you should query (tables, columns, relationships, link paths)
  Tool: Schema Browser
  Why: Schema archaeology so you stop guessing and start joining correctly

Pre-flight checklist (before you start investigating)

Troubleshooting gets messy when your starting assumptions are wrong. Do these first:

• Confirm the environment (Dev/UAT/Prod).
  Half of “bugs” are just… the wrong environment.
• Confirm security context (your admin view ≠ end-user reality).
  If a user can’t see a record, don’t “prove” it exists only from your admin perspective.
• Write the hypothesis in one sentence:
  “Record exists but view filter excludes it.”
  “Join logic filters out rows when the related record is missing.”
• Start tiny: filter to one known record ID or one known scenario before scaling.

Consultant law #9: if you can’t reproduce it with a query, you don’t understand it yet.

Tool 1: FetchXML Tester

(when your world is views, link-entities, and “why is this empty?”)

What it’s for

FetchXML Tester is for quickly testing FetchXML queries. It’s perfect for:

• Debugging system views
• Validating link-entity joins
• Isolating why a filter “should work” but returns nothing
• Confirming that your query returns exactly what you expect

When to use it

Use it when:

• You’re working with views and need to validate the exact FetchXML
• You’re debugging joins and filters in a Dataverse-native format
• You need a repeatable query you can share with another consultant

Avoid it when:

• You’re still figuring out how the tables are related (use Schema Browser first)

Step-by-step (fast iteration loop)

1. Start from a known source:
   • Copy FetchXML from a view (ideal), or start from a known snippet.
2. Run with a narrow filter:
   • Use one record you can verify exists.
3. Add complexity gradually:
   • Add one condition → run
   • Add one link-entity → run
   • Add one more condition → run
4. When results go empty:
   • Congrats, you found the breaking change. Undo the last step and isolate it.

Common gotchas (ask me how I know)

• Link-entity accidentally filters out your records
  If you join to a related table and a parent record doesn’t have that related record, you can eliminate the parent from results depending on how the query is structured.
• Filtering on the wrong entity
  You meant to filter the parent entity but the condition is on the linked entity (or vice versa).
• Date/time filters
  “On/after” + time zones + midnight boundaries = classic trap. Test with a record you can inspect.

Validation checklist (prove your conclusion)

• Filter by a known record ID → confirm it returns
• Apply the view filters one by one → identify which condition removes it
• If joins exist: verify whether missing related data should still return the parent (that’s often the core issue)

Real scenario

“This view doesn’t show submitted applications.”

FetchXML Tester reveals:

• the filter is on the wrong status column, or
• the link-entity is filtering out rows where the related record isn’t populated yet, or
• a condition is using the wrong operator/value

You fix it and immediately prove it with the same test case.

Tool 2: Schema Browser

(the “what even is this relationship?” archaeology kit)

What it’s for

Schema Browser is for traversing schema details and entity links—tables, columns, relationships.

Use it when your first problem is:
“What should I query… and how are these tables connected?”

It helps you confidently answer:

• “Which lookup connects these tables?”
• “Is this 1:N or N:1?”
• “What’s the schema/logical name?”
• “Why do we have two fields with the same display name?”

When to use it

Use it when:

• You need the relationship path before building a link-entity in FetchXML
• You need schema/logical names quickly
• You’re in an org with years of customizations and “mystery fields”

Step-by-step (how to use it like a consultant)

1. Find the primary table in the scenario.
2. Identify the columns involved:
   • lookup vs choice vs text (don’t assume)
3. Trace relationships:
   • parent → child (1:N)
   • child → parent (N:1)
4. Confirm the exact lookup column that creates the relationship.
5. Then build your FetchXML with confidence.

Common gotchas

• Same display name, different field
  Common in older orgs where fields were recreated or re-labeled.
• Wrong relationship direction
  You assumed parent/child backwards, so your join logic never matches.
• Querying before understanding schema
  That’s how you get 800 rows and zero answers.

Validation checklist

• Can you describe the relationship in plain English?
• Can you identify the exact lookup column that links the tables?
• Can you explain what happens if that lookup is null?

Real scenario

“Why does my FetchXML link-entity return nothing?”

Schema Browser shows:

• the relationship isn’t direct (A → C → B), or
• you’re linking on the wrong lookup field

Now your query works and you didn’t have to guess.

Investigation recipes (repeatable “debug patterns”)

Recipe 1: “View is missing records”

1. Pick one record that should appear.
2. FetchXML Tester: filter to that record.
3. Apply conditions one-by-one until it disappears.
4. Last change = culprit.

Recipe 2: “Join filters out parents”

1. Confirm the relationship path in Schema Browser.
2. In FetchXML Tester, run the parent-only query.
3. Add the link-entity and watch what drops.
4. If parents disappear, your join logic + missing related data is the issue.

Recipe 3: “Which field is the real field?”

1. Schema Browser: confirm logical names and types.
2. FetchXML Tester: query for non-null values to validate you’re using the right one.
3. Update your view/flow/query to reference the correct column.

Great guide angles (how to expand this article)

• Translating business questions into filters (without “filter drift”)
• Validating joins (relationship direction + missing related data behavior)
• Performance-friendly querying in FetchXML (filter early, return fewer columns)
• Repeatable investigation recipes (turn tribal knowledge into checklists)