How can developers use Query objects and FlowFields appropriately when building high-performance Business Central solutions?

Performance in Dynamics 365 Business Central often depends on how developers access and calculate data.

Two important concepts are Query objects and FlowFields, but they solve different problems.

A Query object defines a set of data to retrieve from one or more tables and can include joins, filters and aggregation. Microsoft specifically documents Query objects as a mechanism for retrieving data efficiently and provides guidance on query design and performance.

A FlowField, on the other hand, is a virtual calculated field. It does not store its calculated value as a normal physical field in the database. Its result is derived from a calculation formula.

Think of the difference as:

Query Object
     |
     v
"What set of records/data do I need?"

FlowField
     |
     v
"What calculated value should this record expose?"

Query objects

Suppose a reporting process needs:

Customer
   |
   +---- Customer Ledger Entry
   |
   +---- Sales Data

A Query object can define the required joins and fields rather than repeatedly retrieving complete records and manually joining them in AL.

Microsoft's performance guidance notes that Query objects can support set-based reading, join multiple tables and, with suitable covering indexes, provide efficient read performance for tables with many fields.

Example:

query 50100 "Customer Sales Summary"
{
    QueryType = Normal;

    elements
    {
        dataitem(Customer; Customer)
        {
            column(CustomerNo; "No.")
            {
            }

            column(CustomerName; Name)
            {
            }

            dataitem(CustLedgerEntry; "Cust. Ledger Entry")
            {
                DataItemLink =
                    "Customer No." = Customer."No.";

                column(SalesAmount; "Sales (LCY)")
                {
                    Method = Sum;
                }
            }
        }
    }
}

The exact query design should depend on the reporting requirement, table keys, filters and data volume.

FlowFields

Consider a Customer page showing:

Balance
Balance Due
Sales
Payments

These can be represented using FlowFields.

FlowFields are calculated dynamically according to their CalcFormula. Microsoft documents calculation types including Sum, Average, Minimum, Maximum, Count and Lookup.

For example:

field(50000; "Outstanding Balance"; Decimal)
{
    FieldClass = FlowField;
    CalcFormula = Sum(
        "Cust. Ledger Entry"."Remaining Amt. (LCY)"
        WHERE("Customer No." = FIELD("No."))
    );
}

The key point is that the value is calculated, not stored as a normal field.

CalcFields matters

When FlowFields are used in AL methods, developers need to understand when calculation is triggered.

Microsoft documents Record.CalcFields() for explicitly calculating FlowFields.

For example:

Customer.Get(CustomerNo);

Customer.CalcFields(
    Balance,
    "Balance Due"
);

Message(
    'Balance: %1',
    Customer.Balance
);

A common performance mistake is calculating FlowFields repeatedly inside a large loop.

Instead of:

100,000 records
      |
      +-- Calculate FlowField
      +-- Calculate FlowField
      +-- Calculate FlowField
      +-- ...

investigate whether the requirement can be expressed using set-based operations or a Query object.

Microsoft's developer performance guidance specifically recommends set-based methods such as FindSet, CalcFields, CalcSums and SetAutoCalcFields, and recommends minimising unnecessary work inside OnAfterGetRecord.

Query versus FlowField

There is no rule saying Query objects are always faster or FlowFields are always slower.

Performance depends on:

• Data volume.
• Filters.
• Keys.
• SIFT structures.
• Query shape.
• Number of calculations.
• Number of records processed.
• Whether the operation is set-based.
• Whether calculations happen repeatedly.

Business Central's current performance guidance also discusses SIFT and its role in optimising FlowFields and query results.

Enterprise rule

The right question is not:

"Should I use Query or FlowField?"

It is:

"What data operation am I performing, and what is the most efficient supported way to execute that operation at the expected data volume?"

That mindset is much more valuable for enterprise Business Central development.