Standard Logic Reuse: Find Method vs. Join in Dynamics 365 Finance & Operations
Question 35 — When to reuse the standard find method and when a join performs better.
Interview Question
find
method to read a record, and when is a join the better choice? Why is selecting records
individually inside a loop discouraged?
Model Answer (Short)
Reusing the standard find method is appropriate for compatibility
when you need to read a single record from a standard table by its primary key — it's clean,
consistent and benefits from caching. However, when you need data from multiple tables at the same
time, a join is far more efficient because it retrieves everything in a single query
rather than issuing separate reads. Selecting records individually inside a loop (a nested
find or select per row) is discouraged because it multiplies the number of
AOS↔DB round trips and degrades performance — combine and fetch the data together instead.
Detailed Explanation
When to use the find method
- Reading a single record by primary key from a standard table.
- When compatibility and consistency with standard behaviour matter.
- When the table benefits from record caching on a full-key read.
When to use a join instead
- When you need data from multiple tables together.
- A join fetches everything in one query, avoiding repeated single reads.
- Consider the performance requirements of the feature when choosing.
Prerequisites (Rule 5)
- Visual Studio with the Dynamics 365 developer tools.
- A custom model / package for your objects.
- Indexes supporting the join / where fields.
Code Example — Reusing the standard find method
// GOOD: single record by primary key -> reuse the standard find
CustTable custTable = CustTable::find('C0001');
if (custTable)
{
info(custTable.AccountNum);
}Avoid: individual selects inside a loop
// BAD: a find/select per row -> one round trip per iteration
SalesLine salesLine;
while select salesLine
{
// Nested single read for every line -> performance hit
CustTable custTable = CustTable::find(
SalesTable::find(salesLine.SalesId).CustAccount);
info(custTable.AccountNum);
}Prefer: one join fetching all needed data
// GOOD: join retrieves everything in a single query
SalesLine salesLine;
SalesTable salesTable;
CustTable custTable;
while select SalesId, LineAmount from salesLine
join SalesId, CustAccount from salesTable
where salesTable.SalesId == salesLine.SalesId
join AccountNum, Name from custTable
where custTable.AccountNum == salesTable.CustAccount
{
info(strFmt("%1 - %2 - %3",
salesLine.SalesId, custTable.Name, salesLine.LineAmount));
}Find Method vs. Join
| Aspect | Standard find() | Join |
|---|---|---|
| Best for | Single record by primary key | Data from multiple tables |
| Round trips | One per call | One combined query |
| In a loop | Multiplies round trips (avoid) | Single set retrieval |
| Consistency | Reuses standard logic | Custom query |
Points the interviewer wants to hear
- Reuse
find()for a single record by primary key. - Use a join when you need data from multiple tables together.
- Avoid individual selects/finds inside a loop — they multiply round trips.
- Choose based on performance requirements of the feature.
- Reusing
find()also aids compatibility and caching.
Likely Follow-up Questions
- Why is a nested
find()inside a loop bad for performance? - When does reusing the standard find method help with caching?
- How do you decide between a join and multiple find calls?
- What role do indexes play in making the join efficient?
Key Takeaway
Reuse the standard find method for a single primary-key read
(compatibility + caching), but switch to a join when you need data from multiple
tables. Never issue individual reads inside a loop — combine them into one query for
performance.