Loading

Queries on a Record Screen

A query pane shows the results of a saved report on a record's own screen, filtered to that record: a supplier's open orders on the supplier, a tenant's repairs on the tenancy. Panes are set up as rows in a datastore and appear automatically on every record screen of the chosen datastore.

Where to find it

Architect Panel → Data:

  • Datastores — the Query Panes datastore, one row per pane
  • Report Builder — where the report behind a pane is built

Before you start: what a pane needs

Two things are required of the saved report, and the second cannot yet be done in the Report Builder:

  1. It must list records (Show set to Records). A pane showing totals is refused: "A pane can only show a query that lists records."
  2. It must ask for the record: it needs a record parameter, used in a condition, so the pane can fill in the current record. The Report Builder cannot add parameters, and re-saving a report there removes any that were added. Adding one means editing the report's Specification on its BI Saved Queries record, which is a job for a developer or someone comfortable editing that kind of definition.

Without the parameter the pane shows "The saved query behind this pane does not have a 'recordid' parameter for the record to fill in." Plan for that step before promising a pane.

Setting up a pane

  1. Make sure your security group has permissions on the Query Panes datastore; it ships with none, so even an architect is refused until it is granted.
  2. Add a row to Query Panes:
    • Saved Query: the report.
    • Record Screen: the datastore whose record screens show the pane (shown by its system name).
    • Title: blank uses the report's name.
    • Parameter To Bind: the report's record parameter (recordID unless changed).
    • Visible To: security group numbers, comma-separated, to limit who sees it.
    • Pane Order (50 by default) and Rows Per Page (10 by default).
    • Enabled: on.
  3. Open a record of that datastore and check the pane.

There is no separate layout step: an enabled pane appears on every record screen of its datastore for the people it is visible to.

What viewers see

The report's rows for this record, a page at a time, run with the viewer's own permissions. Two people opening the same record may see different rows.

What goes wrong and how to tell

  • "A pane can only show a query that lists records.": switch the report to Records.
  • The 'recordid' parameter message: the report has no record parameter, or it was removed by re-saving in the Report Builder.
  • The Query Panes datastore refuses you: grant your group permissions on it.
  • The pane is missing: Enabled is off, the Record Screen is a different datastore, or Visible To excludes you.

Worked example

A purchasing team wants each supplier's open orders on the supplier screen. An analyst builds "Open orders" as a Records report on Orders, and a developer adds a record parameter matched to the order's Supplier field. The architect adds a Query Panes row with that report, Record Screen set to the suppliers datastore, Title "Open orders", Rows Per Page 10, and Enabled on. Every supplier record now shows its own open orders. The team agrees not to re-save the report in the Report Builder, because that would remove the parameter.

Recommendations

  • Keep pane reports short: a few columns and a sensible sort.
  • Label pane reports clearly so nobody re-saves them in the Report Builder.
  • Use Visible To for panes only some roles need.
  • Grant Query Panes permissions only to architects.