Queries and Reports

One reporting layer over all your connected systems, with saved queries, scheduled branded PDF reports and safe staging copies.

One place to ask questions of all your data

Once your systems feed the hub, reporting stops being a per-system exercise. A saved query in STRAX runs over the consolidated hub data, so a single question can span billing, support, sales and network inventory at once. Demo ISP can list every customer with an overdue Splynx invoice and an open Zendesk ticket in one query, because both systems already land in the same place.

Queries are named, described and kept in the console, so the organisation builds a library of agreed definitions rather than a folder of one-off spreadsheets. When two people ask for monthly revenue, they run the same query and get the same answer.

The query library: named, described queries with their staging and production status side by side.

Parameters make one query serve many cases

A query can declare parameters such as a month, a region or a customer, each with a label, a data type and a default. One revenue query then serves every branch and every period, instead of a near-identical copy per case. Results appear in a grid in the browser, and a full result set can be downloaded as a CSV file. A long-running query can be sent to the background, so the console stays usable while it completes.

A query can also carry a chart definition, choosing a bar, line, area or pie presentation with its labels and values. The same chart then appears everywhere the query is used, in reports and on portal pages alike.

Reports that present themselves

A report definition: titled sections backed by queries, each rendered as a table or chart in the finished PDF.

The report designer turns queries into finished, branded PDF documents. A report is a cover page plus a series of sections, each backed by a query and rendered as a table, a chart or both. Layout and branding are configured once: page size and orientation, company name, colours, typography, page numbers and a confidential marking where needed. Demo ISP's monthly board pack carries its own logo and colours, and every departmental report matches it.

Reports run on demand, on a schedule or from a workflow. A scheduled report generates itself and emails the result, so the Monday operations summary arrives before anyone asks for it. Every run is retained with its parameters, page count and the PDF as generated, which preserves what was actually sent even after the underlying data has moved on.

Replacing per-system exports

The practical outcome is one reporting layer instead of five export routines. Nobody downloads a CSV from Splynx, another from HubSpot and a third from NetBox to assemble a picture in a spreadsheet. The joining has already happened in the hub, and the report reflects it. When a new system is connected, existing queries can reach its data as soon as it is mapped, with no change to the reporting tooling.

Change safely with staging copies

Queries and reports both participate in STRAX's staging and production model. A production query that a live portal or a scheduled report depends on is not edited in place. You create a staging copy, make and test the change there while the production version continues to serve, and push the result when it is right. Version history means a push that turns out to be wrong can be restored.

Where this fits

Queries also power the data modules on portals and can be called from workflows, so one definition serves screens, documents and automation. For the wider picture, see What is STRAX? and the use cases, or request a quote to see your own data in a report.