Skip to main content

Creating a Report

A report is an FPL processor: code that queries stored data, shapes it, and emits the tables and widgets that become the report's output. This page walks through authoring one: opening the editor, writing the processor, declaring the arguments that make it reusable, running it and reading the trace and error logs, and saving it so it can be scheduled. If you would rather start from working code than from an empty editor, jump to the Report Cookbook.

Opening the Editor​

Add Report​

On the FPL reports tab of Reports, the + Add Report button opens the report editor at /v2/reports?kind=fpl&action=add with a new, empty report.

FPL report editor for a new report named New_Report, with Name, Type, and Description fields, an Idle status, the Code Editor and Output tabs, the code editor holding an empty main function, and the Trace log and Error log panels

What the author lands on: the report's name (New_Report) as the page title, with Validate, Run and Save Processor in the header. Below it, the Name (prefilled with New_Report), Type (Report, read-only), and Description fields, the run status (Idle), and the Code Editor and Output tabs. The Code Editor tab holds an FPL skeleton (function main()) above Trace log and Error log panels, which read No traces available and No errors available for a new report.

Cloning an Existing Report​

Click a report in the FPL reports table to open it in the editor with its FPL. A system report (one supplied with the platform) opens with the note System report. Save under a new name to create a local copy., and its save button reads Save as Processor: change Name and click Save as Processor to make your own copy. It is the fastest path to a first report.

FPL report editor showing the system report Event_Ingress_Metrics_Report, with the note System report. Save under a new name to create a local copy., the Validate, Run and Save as Processor buttons, and its code in the editor

Importing a Definition​

Report definitions are imported from a .json file in the v1 interface, with Import Report on Reports → Processors. This is also how reports move between accounts; the export side is in Scheduling and Delivery.

The Report Editor​

Code Editor Tab​

The FPL source. A new report opens with a function main() skeleton.

Output Tab​

The raw result of the last run: what the processor actually emitted, before rendering. This is where an author checks field names and row counts.

Report Tab​

The v2 editor has the Code Editor and Output tabs only. The rendered view of the result (the widgets as a reader will see them) is on the Report tab of the v1 editor.

Trace Log​

The processor's trace output, reading No traces available until the report has run. Trace lines emitted by the processor are the primary debugging surface.

Error Log​

Runtime errors from the last run, reading No errors available for a new report.

Report Details and Saving​

The fields above the editor: Name, Type (Report, read-only), and Description, with Validate, Run and Save Processor in the header (Save as Processor for a system report, Update Processor for one already saved). The description is what appears beneath the report's name on the FPL reports tab and in the Scheduler table.

Validate checks the code without running it, and Run works on a report that has not been saved yet, so a report can be tried before it is named. Save Processor stays greyed out until Name is filled in, and once the report is saved its Name is read-only. The notices and the run's output are described under Report Editor.

Worked Examples​

Complete, working report processors live in Appendix → Cookbooks → Reports, covering Azure AD logins, behavior summary, event ingress, an Active Directory resource-loading task, and an Office 365 user-activity investigation. The Report Cookbook page routes to each one and says what it demonstrates.

Last updated on