Requesting a new report

How new report types get built - deliberately code, deliberately fast.

Requesting a new report

New report types are small code packages, not self-serve templates. This is deliberate: every report binds to the metric contract, gets tests, and gets fixture-verified against the Looker original where one exists. A typical new report ships in about a day, often faster.

What to provide

The more of this you hand over, the faster the turnaround:

The Looker original, if one exists: the Look/dashboard URL, or a CSV export of its output. A captured output file becomes the parity fixture the new report is tested against (this is how the Ladro Transfers IIF reached byte-for-byte parity).
Exact columns and headers if the recipient’s downstream system cares (QuickBooks imports, MarketMan, spreadsheets with formulas pointing at columns).
Recipients and cadence: who gets it, what time (store close? 6am? 1st of month?), and whether the “day” means store-local or UTC.
Population rules: completed orders only? Include refunds? One store or the whole company?
Format: inline email, CSV, XLSX, PDF of a dashboard, or webhook.

What happens then

The report is scoped against the data dictionary. If the data plane already carries the data (most cases), it goes straight to build. If there is an ingestion gap (for example category-grain item data), you will hear that immediately with the plan for closing it.
A renderer is built and registered, with tests, and where a Looker fixture exists, a diff against it.
A trial send goes to you (never straight to merchants).
During the migration period, the report runs in dual-send soak: the platform version and the Looker version deliver side by side until the outputs are verified equivalent, then the Looker plan is paused.

Where to file

Linear project “Looker Sunset - BI Replacement”, or ping David/the data channel. Include the list above in the issue.