> ## Documentation Index > Fetch the complete documentation index at: https://docs.parable.work/llms.txt > Use this file to discover all available pages before exploring further. # Reports > Run a Parable's Pipelines on demand or on a schedule and read the saved results. # Reports A Report is one run of a Parable's Pipelines, the Plots whose Pipeline switch is on (see the Pipelines Power). Each run stores durable outputs that readers can choose later, even after the Parable's code changes. Reports exist so a number people rely on, such as last month's spend or this week's classified tickets, is produced once, kept with its inputs, and read the same way by everyone. A Parable Version identifies code and schema; a Report identifies produced data. They are separate choices. Running a Report captures the exact definition, the SQL and version of each Plot it runs, and the requester. Any published Parable with a Pipeline can run a Report with no setup. A run that names no Report runs every Pipeline, and Plan Refreshes adds a schedule. A Version that has never refreshed shows Power on Parable where its Pages go, and a press runs its first Refresh. The run is queued and becomes complete only after it produces real outputs. Readers choose a reading in the Report picker. Current is the newest completed Report whose output fits the selected definition, and it can come from an earlier compatible definition. A chosen Report stays pinned; if it is unavailable or incompatible, the reader sees that instead of a silent switch to Current. Ordinary SQL Plots can query completed Pipeline outputs with their own parameters, while reading a stored output directly keeps its captured inputs and refuses different ones. Schedules are written in plain words, such as every weekday at 9am starting next Monday. They support timed daily-or-longer recurrences and a single timed run, follow the chosen timezone, and coalesce missed runs into one. A manual run uses the requester's authority, checked when execution starts. A scheduled run executes as the Workspace's service principal with that Workspace's permissions, never the credentials of whoever created the schedule. A schedule is part of the Parable's Version: it is the default every Workspace that publishes the Parable runs, each Workspace on its own with its own next run, pauses, failures and history, starting at the first occurrence after it publishes. A schedule with no start counts from each Workspace's publish, so its phase can differ between Workspaces; give it a start to keep them in step. A Workspace that changes a delivered schedule in its own Changes keeps that change when new Versions arrive. Changing a schedule, the Parable's default or a Workspace's own, needs the schedule permission, which only Parable staff hold, and the Responsible seat; Pane Policies do not govern schedules. A save that changes a schedule without the permission is refused, and anyone else reads the schedule read-only. Editing a schedule does not publish the Parable, and publishing does not run a Report or reset its schedule. Reading an old Report checks its captured inputs against current Policies, so a deleted or newly hidden input makes the result unavailable rather than substituting today's values. A Report run reads each Pane's saved rows by name with no reader, This Parable's layered over the Parable's Default, and every team's through `_by_actor`, as they were when the run started, never a person's own: the run keeps that moment, so an old run reads the same rows later. When a row that a Pipeline read changes after the Refresh that made its result started, the result says "These settings changed since the last run" and offers Preview, a sampled Refresh, and Run, with its estimate. A Pipeline can read another Pipeline of the same Report: the run is a graph, so a member runs after the members it reads and reads what they wrote in that run. Members that read each other in a cycle are refused. A Pipeline can read Plots of its Parable that are not Pipelines: the run reads each as a view of its SQL from the Version it captured, so a Report combines several Plots by leaving the Plots it reads unstored. Provider filters that depend on the requester need the captured principal, and filters that use the full Parable context or the current time refuse to materialize. Iterate with Preview, not full runs. Preview runs the whole Report end to end, every Pipeline in order, with the same SQL, Jev calls and shared settings, on a fixed sample of the real rows: one in ten rows of each Provider table over 10,000 rows, the same rows every time, and smaller tables whole. It runs on the newest Version or on a set of Changes before anything is published: run the Report with preview set, and the set's proposalId to preview a set. It lists in the Refresh menu with a Preview badge, and choosing it shows every Page on its outputs. A Preview never becomes Latest, and nothing else reads it. While you iterate, put your effort into what a reader sees end to end and into the data model: the Pages, each Pane's kind, and the Pipelines that feed them. Check each change with a Preview, read the Pages on it, and fix what reads wrong. Judge shapes, joins, empty states and errors on a Preview, never totals: its numbers cover a tenth of each large table, and a join between two large tables keeps about one match in a hundred. Run a full Report once the Pages read right on a Preview and the Changes are published. A Plot's own SQL can sample too, with the standard TABLESAMPLE BERNOULLI (10 PERCENT) REPEATABLE (1); never leave one in a Pipeline that readers rely on. 1. Define what the reader receives: grain, provenance, and how they choose Current or a specific Report. Plan the pending, failed, empty, stale, unavailable, and incompatible states. 2. Ask Ponder to check that the Parable can run a Report, and confirm each Pipeline's output contract. 3. Ask Ponder to Preview the Report to prove the Pipelines end to end, then run it in full, or choose Plan Refreshes and describe the schedule in words. Review the interpreted schedule and the upcoming runs before saving. 4. Read the result through Current and through the explicit Report, and compare its provenance with the definition that consumed it. 5. Change the code and the schedule independently, and confirm neither changes the other. A good Report runs the real Pipelines, reads the same completed output through Current and the pinned Report, names both the Report and the consuming definition in its provenance, and refuses readers who lack access. State any unsupported step plainly. Never fake historical data, label live recomputation as a historical result, or mark a synthetic run complete. Related Powers: Pipelines, Plots, Policies, Publishing, Providers. Find each by its title; do not guess stored names. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.