Appearance
Reports: from a screen to something you can send
A query answers a question. A report is what you do when the answer needs to leave the screen — printed, filed, or in somebody's inbox.
Fusion covers a wider range than the word "report" usually suggests, from a grid you saved because you look at it every week, up to a properly laid-out document with a letterhead. It is worth knowing which you want.
The quick kind: save what you already built
If you have run a query, chosen your columns, filtered it and grouped it, you have already done the work. Save as Report keeps it.
It remembers the query, the parameter values, the columns, the filter, and whichever tab you were on — so a report saved from the Pivot tab comes back as a pivot, and one saved from the Visual tab comes back as a chart.
Next time, run the report and it is exactly as you left it.
When you want to adjust it, Edit Definition reopens the query results screen with everything restored. Change what you need and save again — over the top, or as a new report if you would rather keep the original. That last option is the safe way to experiment with something colleagues rely on.
More in Reports built from a query.
The considered kind: design the page
Some things have to look right on paper. A pay claim per teacher. An SLA letter per school. Anything going to somebody outside your team.
For those, the Report Designer builds the page properly. You work in bands — a page header that repeats, a body, group headers and footers — and place each piece of content where you want it.
A few things it can do that are worth knowing about:
Group, and group inside groups. Teacher, then contract within teacher, then the individual sessions. Each level can carry its own heading and its own subtotal, and headings repeat automatically when a group runs over a page break.
Calculate. Summary fields total whichever band they sit in — the same Sum gives a report total in the body and a per-teacher total in a group footer. Formula fields work something out per row, like turning minutes into hours. Local fields work something out once for the whole run, like a title or the date it was produced.
Embed another report. A sub-report runs a second report once for every row of the first — each audition's items listed beneath it, growing to however many rows it needs.
Getting it out
Running a designed report opens the Report Viewer, which has two tabs: the finished document, and the data behind it.
The data tab is not just for checking. The filter you apply there decides what the printed report contains, and what any export or email includes. Trim the rows and the document follows.
From there: Export to Excel, Export Section to PDF, or Print — with real pagination, so what comes out of the printer is what you saw.
One report, one section each
Here is where it gets genuinely useful. A report can be sectioned by record — one section per teacher, per school, per whoever.
The viewer then lists the sections down the side so you can jump straight to one. And Email All Sections sends each person only their own section, as a PDF, looked up from a column in the report itself.
Forty teachers, forty personalised documents, one action.
Then stop doing it at all
If you produce something on a rhythm — every Monday, the first of the month — schedule it.
Choose daily or a particular weekday, choose a time, and add recipients. Each recipient can have it either as an in-app notification with a link, or as an email with the PDF attached — which means people who do not use Xperios can still receive it.
Send Now fires it immediately, which is how you test it without waiting until Monday. And when it is no longer needed, Delete stops it.
The shift worth making
Most reporting effort goes on producing the same thing repeatedly rather than on deciding what is worth producing.
If there is a document you rebuild every month, it is worth an hour once to make it a scheduled report — and then it simply arrives, for you and for everybody else who needs it.