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

From Reports → Processors, the Add Report button leaves the list and opens the report editor at /platform/processors/report with a new, empty report.

Report editor opened by Add Report, with FPL code skeleton and the Processor Info panel showing Name, Type, and Description fields

What the author lands on: the Code Editor, Output, and Report tabs, with the report name (New Report) and its run status in the toolbar. The Code Editor tab holds an FPL skeleton (function main()) plus Trace Log and Error Log panes, which read No traces available and No errors available for a new report. A Processor Info panel opens on the right with a Details form — a Name field prefilled with New Report, a Type dropdown set to Report, and a Description field — and Save Report at the bottom of the panel.

Cloning an Existing Report

Clone — the only entry in a processor card's ... menu — opens the editor preloaded with the source processor's FPL. It is the fastest path to a first report; the clone opens with the source's name prefilled and an empty description.

Report editor opened by Clone, showing the source processor's FPL code and the Processor Info panel with the name prefilled

Importing a Definition

Import Report on the Processors page opens the Import FPL Report as Processor dialog, which loads report definitions from a .json file and lets you select which to import.

Import FPL Report as Processor dialog with file upload area, empty selection table, and Import and Cancel buttons

The dialog has an upload area labeled Click here to upload a file (or drop the file on it), a selection table with a checkbox column and Name and Description columns that reads No data available until a file is loaded, and Import and Cancel buttons — Import stays disabled until a file is loaded and a row is selected. 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 rendered view of the result: the widgets as a reader will see them.

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.

Processor Info Panel

The Details form on the right — Name, Type (set to Report), and Description — plus Save Report. The description is what appears on the processor card and in the Scheduler table.

Worked Examples

Point at the existing report scripts rather than duplicating them: complete, working report processors already 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.