Panes, Schedules & the Dataset API

Queries on a Record Screen

A BI pane puts a saved query on a record screen, scoped to the record you are looking at: "the invoices for this supplier", "the cases for this client", "the repairs at this property".

Where to find it

Architect Panel → Data:

• Query Builder — the saved query the pane draws

Architect Panel → Layout & Pages:

• Record Layout — where panes are added to a record screen
• Data Layouts — the layout the pane appears in

Why this is better than a linked view

The alternative is a hand-built related view per record type, each with its own filters and its own idea of what counts. Panes draw a saved query, so the pane on the supplier screen and the figure on the finance dashboard use one definition.

It also means improving the query improves every pane using it, rather than requiring the same edit in six places you have to remember exist.

Scoping to the record

The pane passes the record it is on into the query as a parameter. That is why parameterising queries matters: a query hard-coded to one supplier cannot become a pane, whereas one taking a supplier parameter serves every supplier screen.

What makes a good pane

Panes compete for space with the record's own fields, so be selective:

• Recent activity — the last few related items, not all of them.
• Outstanding items — what is open against this record right now.
• A single meaningful figure — total spend, open balance, days since last contact.

Resist putting a full history on a record screen. History belongs behind a link; the screen should answer "what do I need to know about this right now".

Permissions

Panes run as the person viewing the record, so a pane cannot show somebody data they could not otherwise reach. A pane that looks empty for one user and full for another is usually working correctly.

Worked example

A supplier record carries three panes: open purchase orders, invoices in the last twelve months with a total, and any open non-conformances. A buyer opening the supplier sees the commercial position immediately without navigating anywhere, and the invoice figure is the same one the finance dashboard shows because it is the same saved query.

Recommendations

• Parameterise the query first — a pane needs it.
• Two or three panes per record, not eight.
• Cap the rows and link to the full list.
• Check it as a restricted user before rolling it out.

Scheduled Delivery

Scheduled delivery runs a saved query on a clock, renders the result, and either emails it or files it as a document.

Where to find it

Architect Panel → Data:

• Query Builder — the saved query being delivered

Architect Panel → Automation:

• Tasks — where the BI schedule task is enabled
• Task Log — what ran, and whether it was delivered

Delivery is driven by a scheduled task that ships disabled — enable it under Automation → Tasks. A schedule that never fires is almost always this.

Why schedule rather than let people look

Because most people will not look. A weekly figure that arrives in an inbox gets read; the same figure behind a login gets checked in the first fortnight and then forgotten.

Scheduling is also the right answer for genuinely heavy queries — run them overnight and deliver the result, rather than making somebody wait for a dashboard block at nine in the morning.

Email or file

• Email — right for a figure somebody should act on: a Monday morning backlog, a month-end summary.
• File as a document — right for anything that needs keeping: a board pack appendix, a regulatory return, a monthly snapshot you may need to produce later.

Filing has a real advantage for anything that might be questioned: it preserves what the figures were on the day, which a live dashboard cannot.

Emailing data is an export

Treat it as one. An emailed report leaves the permission model the moment it is sent, gets forwarded, and sits in inboxes and on phones indefinitely.

Be deliberate about the recipients, and think twice before scheduling anything containing personal data or small-number breakdowns. "It is only going to the management team" is not a control — it is a hope about what happens next.

Choose a sensible cadence

Match the schedule to the decision it supports. A daily report about a monthly trend is noise, and noise gets filtered into a folder nobody opens. If a report has never once changed what anybody did, stop sending it.

Worked example

A service manager receives an open-cases-by-age report at 7am each Monday, which is when the weekly allocation meeting happens. The same query is filed monthly as a document for the performance pack, so the board sees the figures as they stood at month end rather than as they are today.

Recommendations

• Enable the schedule task first, and check the Task Log after the first run.
• Time delivery to the decision, not to a round hour.
• File anything that may be questioned later rather than only emailing it.
• Review recipients annually — distribution lists outlive the people on them.

The Dataset API

A saved query can be exposed as a read-only API resource, so another system reads the result directly rather than being sent a spreadsheet.

Where to find it

Architect Panel → Data:

• Query Builder — the saved query and its key

Architect Panel → Integration & Connections:

• API Server — where the API and its exposure are configured
• API Clients — who may call it
• OpenAPI Specification — the generated description, including dataset paths

How it is addressed

A dataset is requested through the API using its saved-query key. The paths for exposed datasets are generated into the OpenAPI specification automatically, so a consumer discovers them the same way they discover everything else — and can generate a client rather than hand-rolling calls.

Why this beats sending files

The usual arrangement is a scheduled export emailed to a partner, who imports it. That has three problems: it is always slightly stale, it breaks silently when nobody notices the email stopped, and every copy is a copy of personal data sitting somewhere you do not control.

A dataset endpoint is read live, under a credential you can revoke, with no copy left behind.

Read-only, deliberately

A dataset is a query result. There is nothing to write to, which makes it a safe thing to expose — the worst case is disclosure, not corruption. That is a meaningfully smaller risk surface than exposing the underlying datastores for reading and writing.

Design the query for the consumer

Expose a query shaped for what the consumer needs, not your internal view. Include the fields they require and nothing else — internal notes, staff names and free-text fields written for colleagues do not belong on an interface somebody else reads.

This is easier than restricting a datastore, because you control the shape completely: the query is the contract.

It is a contract

Once a consumer builds against a dataset, its columns are a contract. Adding a column is safe; renaming or removing one breaks them, usually silently and usually in production.

If you must change the shape, publish a second dataset under a new key and retire the first with notice.

Worked example

A council exposes "open planning applications" as a dataset for its public-facing map. The query returns reference, address, description, status and dates — and deliberately not the case officer's name or internal notes. The map reads it live, so the public site is never stale, and no extract of planning data sits on a third-party server.

Recommendations

• Shape the query for the consumer, not for yourself.
• One dataset per consumer purpose, with its own key.
• Never rename or remove a column without publishing a new key.
• Prefer a dataset to a scheduled file whenever the consumer can call an API.