SQL Query
Displays the result of a query on the form, rather than holding a value of its own.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
Architect Panel → ERP - Trading & Analytics:
- Analytics — the proper home for reporting
It shows, it does not store
The distinguishing characteristic. There is no value on the record — the field runs a query and displays what comes back, fresh each time the form is opened.
So it does not join, cannot be reported on, and holds nothing historical.
Where it genuinely helps
- Context while working. Showing a customer's recent orders on their record saves navigating away.
- Live summaries — outstanding balance, open items, a count that must be current.
- Related information from elsewhere, presented where somebody needs it.
The misuse to avoid
Using it as a reporting tool. It is tempting because it is flexible, and it is the wrong place: queries embedded in field definitions are invisible to anybody looking at your reports, unmaintained, and impossible to audit as a set.
Analytics exists for reporting, with measures and dimensions defined once and shared. A number that matters belongs there, not scattered across form fields.
It runs every time the form opens
The performance consideration, and it is easy to miss because it does not show up in testing with small data. A heavy query on a frequently-opened record is a slow form for everybody, all the time.
Keep queries tight, ensure what they touch is indexed, and think about how the record will feel in three years with far more data behind it.
Permissions need thinking about
The most important caution. A query can reach data the person viewing the form might not otherwise be allowed to see.
Do not assume the platform's permission layers cover what a hand-written query returns. Check what the field displays for a user with restricted access — as that user, not as an administrator — before it goes anywhere near production.
It is a maintenance liability
A query embedded in a field breaks when the underlying model changes, and it breaks at the point somebody opens a form rather than when the change was made. Whoever renames a field will not think to look here.
Keep a note of where these exist, so a model change can check them.
Prefer a proper relationship
Much of what people use this for — showing related records — is better done with an actual relationship between datastores, which is visible, permission-aware and reportable.
Worked example
A customer record shows the five most recent orders and the outstanding balance through a query field, checked as a restricted user to confirm it reveals nothing they should not see. Sales reporting is built in Analytics, not from query fields, so the figures are defined once and everybody's numbers agree.
Recommendations
- Use it for context, never for reporting.
- Check what it shows a restricted user.
- Keep queries tight — they run on every open.
- Prefer a real relationship where one would do.