FlowFields

A FlowField shows a value that is calculated from related records instead of being stored on the record itself. FlowFields are the right tool whenever you need to display a sum, a count, or a value that lives in another table.

What a FlowField Is

A FlowField has no stored data. Every time the record is shown, Business Central calculates the value from a related table using the FlowField's formula. That means:

The value is always current — it follows the source data.
Nothing is written to the database for the field.
The value cannot be used the way stored data can (see Limitations).

SOD supports the standard calculation types:

Calculation type	What it produces	Typical use
Sum	The total of a numeric field across related records	Total quantity across order lines
Count	The number of related records	Number of archived quotes on a customer
Lookup	A single value from one related record	Vendor name on a G/L Entry
Average / Min / Max / Exist	Other aggregates over related records	Reporting and validation scenarios

The Most Important Rule: Where to Create the FlowField

Create the FlowField on the table where you want to see the value — not on the table that holds the data.

This is the single most common mistake. If you want the summed gross weight of a sales order:

Create the FlowField on table 36 Sales Header (where the value is consumed)
Point it at table 37 Sales Line (where the data lives)

Adding the FlowField to the Sales Line — because that is where Gross Weight exists — is incorrect.

Creating a FlowField

Go to Tasks > Create new fields
Add a new field to the table where the value should appear
Set the field type to FlowField
On the Field Settings page, configure:
- Calculation Type (Sum, Count, Lookup, …)
- Related Table — the table holding the source records
- Related Field — the field being summed or looked up
- Filters — which related records are included
Publish

A video walkthrough of creating a FlowField that sums line values onto a document header is available at https://www.youtube.com/watch?v=GugNPeSrE8s.

Understanding Filters

The Filters setting works exactly like setting a filter anywhere else in Business Central: you restrict which related records are aggregated.

Two forms are used:

field(...) links a field on the source table to the value of the current record's field. This is what ties the related rows to the record being displayed.
const(...) restricts the source rows to a fixed constant value. Const is used mainly for Boolean and Option/Enum fields.

Filters apply to fields on the source table. A field can therefore be used in a filter even though it does not exist on the table where the FlowField is defined — this is why, for example, Type is available as a filter when summing Sales Lines onto the Sales Header even though the Sales Header has no Type field.

Microsoft's reference documentation on FlowFields and FlowFilters is available at https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-creating-flowfields-and-flowfilters.

Worked Examples

Summing line values onto a document header

Goal: Show the total gross weight of all item lines on the Sales Header.

Setting	Value
FlowField location	Table 36 Sales Header
Calculation Type	Sum
Related Table / Field	Table 37 Sales Line, `Gross Weight`
Filter	`Document Type = field(Document Type)`
Filter	`Document No. = field(No.)`
Filter	`Type = const(Item)`

The same pattern applies to summing quantities, amounts, or any other numeric line field, on sales and purchase documents alike.

Missing totals on a header table

Some header tables do not store summary values at all. The Purchase Order Archive Header, for example, has no stored Total Excl. Tax / Total Tax / Total Incl. Tax. Adding those fields to the page with "add existing fields" shows empty values, because the underlying field holds no data.

The fix is to create Sum FlowFields on the header table that aggregate the corresponding line fields. Use page inspection to confirm whether a field actually carries a value before assuming the placement is at fault.

Goal: Count the Contacts registered to a Customer.

Do not count the Contact table directly. Contacts are linked to customers through the Contact Business Relation table:

Setting	Value
Calculation Type	Count
Related Table	Contact Business Relation (5054)
Filter	Field 4 (customer number) = the customer's No.

Goal: Count archived sales quotes.

Use a Count over the Archive Sales Quote Header table. This returns a count across all archived quote records, not just the most recent one.

If a Count FlowField always returns 1 (or another suspiciously low number) regardless of your filters, the aggregation is pointed at the wrong table or the relationship is not what you assumed. Browse the underlying table data and confirm how the records are actually linked before adjusting the formula.

When information stored in one table must appear on a page based on a different but related table, add a FlowField of calculation type Lookup to the table behind the target page. This is preferred over trying to physically copy the value.

Examples:

Show a Vendor Name on G/L Entry (table 17) by looking it up through the related vendor record.
Show Vendor Order No. from Purch. Rcpt. Header (table 120) on the Posted Purchase Receipt Lines page (528) by adding a Lookup FlowField to the lines table.

The two tables must be relatable — a shared key such as a document or receipt number must exist for the lookup to resolve.

Displaying a user name instead of a GUID

Fields such as Created by and Modified by store a user GUID (Security ID), not a readable name. A Lookup FlowField resolves that GUID into the user's name so it can be placed on a page such as a ledger entries list.

A video walkthrough of this scenario is available at https://www.youtube.com/watch?v=gnq2PUSozDU.

Pulling a specific line value onto the header

A Lookup FlowField can show a line field on the header when the line can be identified by a fixed filter:

Setting	Value
Calculation Type	Lookup
Related Table / Field	Sales Line, `Description`
Filter	`Document Type = field(Document Type)`
Filter	`Document No. = field(No.)`
Filter	`Line No. = 10000`

Line No. 10000 is normally the first line — unless a line has been inserted above it, in which case a lower line number exists. That caveat is the weakness of this approach; see Limitations.

Recreating a standard FlowField in another table

Some standard fields cannot be used as lookup sources because they are themselves FlowFields. Customer field 58 Balance and field 67 Balance Due (LCY) are examples. A field with FieldClass = FlowField and Editable = false is the signal.

Such a field can be recreated in another table, provided that table contains the filter fields the formula needs. The formulas reference their filter fields through FIELD(...):

Field	Type	CalcFormula
58 Balance	Decimal	`Sum("Detailed Cust. Ledg. Entry".Amount WHERE("Customer No." = FIELD("No."), "Initial Entry Global Dim. 1" = FIELD("Global Dimension 1 Filter"), "Initial Entry Global Dim. 2" = FIELD("Global Dimension 2 Filter"), "Currency Code" = FIELD("Currency Filter")))`
67 Balance Due (LCY)	Decimal	`Sum("Detailed Cust. Ledg. Entry"."Amount (LCY)" WHERE("Customer No." = FIELD("No."), "Initial Entry Due Date" = FIELD(UPPERLIMIT("Date Filter")), "Initial Entry Global Dim. 1" = FIELD("Global Dimension 1 Filter"), "Initial Entry Global Dim. 2" = FIELD("Global Dimension 2 Filter"), "Currency Code" = FIELD("Currency Filter")))`

Points to note:

The required filter fields — "No.", "Global Dimension 1 Filter", "Global Dimension 2 Filter", "Currency Filter" and, for Balance Due, "Date Filter" — must exist and be populated in the table where you recreate the FlowField.
"Balance Due" variants need a Date Filter because the formula uses UPPERLIMIT("Date Filter") on "Initial Entry Due Date".
Non-LCY variants (58 Balance, 66 Balance Due) sum .Amount; LCY variants (59, 67) sum ."Amount (LCY)".
By contrast, Credit Limit (LCY) (Customer field 20) is an ordinary stored field and is directly available as a lookup source.

FlowFields and APIs

FlowFields are calculated automatically on APIs generated by SOD. No manual calculation step is needed, and this includes Text-based FlowFields, which are expected to return their values through an API like any other.

The AutoCalcField property does not apply to Page (API) objects and should not be set on an API page — FlowFields already calculate without it.

If a FlowField returns blank through an API, that is not an expected limitation; treat it as a defect and contact support.

Choosing Between FlowField, Field Transfer, and Calculated Field

You want to…	Use
Display a live value from a related table	FlowField (Lookup)
Aggregate values across related records	FlowField (Sum / Count)
Store a value permanently on a transaction or posted record	Field Transfer
Copy extra fields at the moment a lookup is selected	Lookup Field Transfer
Show an expression-based value on a page only	Calculated Field

Two specific cases worth calling out:

Archiving: a FlowField is not the way to carry a Sales Header value into the Order Header Archive. Use a Field Transfer — the value must be stored on the archived record.
Summing across lines: use a FlowField, not a Calculated Field.

Limitations

FlowFields cannot be sorted

There is no built-in way to sort by the result of a FlowField, and a sorting feature is not planned — sorting on calculated values is very expensive in server resources.

Workaround: switch the list into Analysis Mode. All columns become sortable there, including FlowField columns, which lets you order by the calculated value (for example, to bring the most recent record to the top).

FlowFields cannot aggregate a Calculated Field

A calculated field is not a real stored field, so it is not available as a source for a FlowField. You cannot, for example, sum a "Outstanding blanket order quantities" calculated field defined on the Sales Lines page into a FlowField on the Item table. This is a product limitation.

FlowFields cannot select an arbitrary "Nth" record

A FlowField follows one deterministic filtered relationship. It cannot return a value from "the first line", "the last line", or "the line matching some condition" unless that line is identified by a fixed filter such as Line No. = 10000.

Likewise, a Lookup FlowField on a date returns the first registration date, not the most recent one. SOD cannot produce a "latest date" lookup. Some fields you see on screen — particularly in FactBoxes — are not FlowFields at all but fields backed by AL code that performs the lookup; that custom logic is what enables "most recent" behaviour, and it cannot be reproduced with a standard FlowField.

To reliably pull the first, last, or best-matching related record, a helper function in AL is required.

Read-only FlowFields are still clickable

When creating a FlowField you can mark it read only. Currently, a read-only FlowField still renders as a clickable blue link that drills down to the filtered source records. A planned enhancement will make read-only FlowFields render as true read-only fields — non-clickable, matching the behaviour of Page Calculated Fields. Until that ships, expect the drill-down link.

Dual-App Mode and FlowField dependencies

When switching to Dual-App Mode, dependencies are moved to the second app automatically in the large majority of cases. The exception is a dependency on another app's field that is used in a FlowField filter — that dependency cannot be relocated automatically and needs manual handling. See Dual-App Overview.

Troubleshooting

A FlowField does not appear on a report layout

Creating the FlowField is only half of the job. The field must also be added to the report using Place on Reports. A FlowField that was created but never placed will never show up in a custom layout.

A Count FlowField returns 1 (or too few records)

The filter or table relation does not match how the related records are actually linked. Open the underlying table and inspect the data before adjusting the FlowField. Counting Contacts is the classic case — the relationship runs through Contact Business Relation (5054), not directly through a Customer No. on the Contact.

"Field ... must not be blank" on a FlowField referencing an Option field

A Lookup FlowField that references an Option field in another table could produce a "must not be blank" error even when the source Option field is configured correctly and holds valid values.

This was a defect in SOD, not a configuration error, and it was fixed in a release following version 14.0.0.666. Update SOD to the latest version — see Updating SOD.

"Field MetaData Hgd doesn't exist" when publishing

Symptom: Publishing after adding a FlowField or lookup fails with a message that the field's MetaData does not exist.

Resolution:

Confirm you are running SOD from the same company every time — always use one company for SOD work.
Open the SOD Setup page and run Refresh Symbols.
Answer Yes when asked whether to clear the cache first.
Publish again.

Values look wrong or stale

Remember that a FlowField reflects current source data at all times. If you need the value frozen as of the moment of selection or posting, a FlowField is the wrong instrument — use a Field Transfer or a Lookup Field Transfer instead.