Reports

Building a saved report, running it, sharing it, and reading the log of what was sent out on a schedule.

Where a question you ask more than once gets saved, so the answer can be asked for again rather than reconstructed.

A report runs as whoever opens it

This is the most important thing on the screen and it is stated on the screen for that reason.

Every row a report returns passes the same rules you meet everywhere else in the product — your site access, your asset scope, your permissions. Two people can open the same shared report and see different numbers, and neither is seeing anything they could not already open.

Sharing decides whose list a report appears in. It does not grant access to anything. A report cannot show a colleague something they could not open for themselves.

Building one

Build a report needs permission to create reports — managers, executives and administrators by default. Everyone else can run what exists.

1. Name it

   A code, a name, and one line saying what question it answers. A category — Work, Assets, Inventory — groups it in the list.

2. Choose what it reads

   Each source is a list of records the product already maintains. Changing the source clears the columns, because column names belong to the source they came from.

3. Pick the columns

   Click the ones you want. Choose none and the report returns all of them.

4. Say which rows

   The condition builder — groups of clauses combined with all of these or any one of these, and not where you need it. Each clause is a column, a test and a value. Leave it empty and the report returns everything you may see.

5. Set the order and the ceiling

   Sort by any column, ascending or descending, and cap how many rows come back.

6. Decide who sees it in their list

   Put it in everyone’s list makes it shared. Leave it off and it stays a draft only you see.

The filter is checked when you save, so a column that is not there is refused at the moment you save it rather than at six on a Monday morning.

Running one

Run answers the question with your own access, right now. The table is whatever the report returns — a report has no fixed shape.

If the row count reaches the report’s own ceiling, the screen says so. There may be more; raise the limit on the report if there are.

No rows means either nothing matches the filter or nothing matching it is visible to you.

Schedules

The Schedules tab lists the scheduled deliveries configured for your organisation: which report, how often, at what hour, in what format, and to whom. Recipients have to be users here, because what arrives is a link to a file they are asked to sign in for.

A scheduled report is the exception to the rule above: it runs as the report’s author. A schedule has nobody reading it at the moment it runs, so there is no reader to be. Everyone on the list gets the author’s answer, which may be wider or narrower than their own — the email says so, and so does the delivery log. Opening the report on this screen answers with yours.

Schedules are not created on this screen.

What actually went out

Below the schedules is the log of deliveries: the period each covered, whose access answered it, how many rows came back, the format, how many recipients were notified, and what became of it.

Anything refused or failed is lifted into its own Not sent section at the top, with the reason — an author who has left, a recipient who is not a user here, a render that failed. A schedule that has quietly stopped sending has no symptom of its own: the email does not arrive, and nobody reports the absence of an email. This is where that turns into a sentence.