Workflows

A Workflow takes an analysis you have already validated and re-runs it on a schedule, producing a fresh deliverable each time. Where a notebook is the record of one analysis, a Workflow is a saved recipe: the data source queries, the notebook code, any metric references, and the instructions for formatting the output. Every run re-queries your data and regenerates the result. The recipe being fixed is the point. A Workflow re-runs the notebook you already checked rather than working the analysis out from scratch each time, so the same queries and the same transformations produce this week’s numbers. You are not asking a question twice and hoping the answers are comparable. What Orion writes fresh is the narrative around the numbers, and you can constrain that too: a report can follow a template for its layout and a Knowledge Base page for its style. Use a Workflow when someone needs the same answer on a repeating cadence: a Monday morning revenue report, a daily pipeline dashboard, a monthly board deck.

​

Notebook vs Workflow

A Workflow always starts from a notebook, so get the analysis right in chat first. See Running Analyses.

​

Creating a Workflow

Two ways in: click Create Workflow in the notebook panel, or ask Orion in chat. Both call the same thing underneath, so pick whichever is faster in the moment. Asking is quickest when you already know what you want. In the chat where the analysis ran: “save this as a workflow that runs every Monday at 8am and outputs a dashboard.” It also handles schedules the dialog cannot express. The dialog is the guided version. Once an analysis is correct, open the notebook panel in Chat. At the top you will find Save as a Workflow. Click Create Workflow. The dialog asks for three things: Submitting the dialog writes exactly that kind of request and sends it to Orion, which is why the two routes behave the same. Orion builds the Workflow from there. Only cells that ran cleanly make it in, so anything that errored is left behind, and Orion does a full dry run before saving. If that dry run fails nothing is saved and Orion tells you what broke.

​

The Evergreen Check

A Workflow that hardcodes last quarter’s dates would keep reporting last quarter forever, so Orion reviews the analysis for that before saving. You do not have to ask. The check looks for hardcoded dates and date ranges, filter values and IDs that came from your specific session, and hardcoded file paths, and it rewrites them to relative equivalents: a fixed 2026-01-01 cutoff becomes a rolling window. Writing the analysis this way from the start is still cheaper than having it corrected. See Use Relative Dates.

​

Output Formats

The dialog picks the format a Workflow starts with, not the only thing it can ever produce. A Workflow can carry several outputs at once, including an audio briefing, and it can carry data exports such as a CSV alongside them. Each one is a separate step on the graph, with its own format you can change later.

​

Templates

Format decides what kind of artifact a run produces. A template decides what it looks like. Attach one to a slide deck or a dashboard and every run comes back in that layout and theming, which is the difference between a weekly deck that looks like the same deck and one that gets redesigned behind your back. Templates are optional. With none set, Orion lays each run out from scratch, which is fine until the same deck starts going to the same meeting every week and people navigate it from memory. You can attach one later or clear it again without touching the analysis underneath. Open an output step and set Artifact Template in its Report Configuration. Templates are saved per project, and you get them two ways: upload an HTML file, or generate a deck or dashboard you like in chat and use Save as template to keep it. Only slide decks and dashboards take a template, so the option does not appear on markdown reports or audio briefings.

​

Finding Your Workflows

Workflows live in the Workflows section of the project page, below Shared Metrics and Published Content. The Shared and Yours toggle at the top of the page switches between Workflows the project shares with you and your own. View all opens the full list. They are also indexed in Search under the Workflows filter. Each entry shows its name, who created it, its schedule, the outcome of the last run, and when that run happened. A Workflow that has never run says so. A Workflow starts out private to you. Use Move to Shared Board on the entry to hand it to the rest of the project, or Make Private to pull it back. Click a Workflow to open it. The view lays the Workflow out as a graph: the trigger that starts it, the analysis it runs, each output and export it produces, and who gets notified. The header carries the status of the last run and a Run Now button. Click any step to open its configuration. This is where a Workflow is edited: the trigger holds the schedule, each output step holds a format and its latest result, and the notification step holds the message and its recipients. You can also add steps, so a Workflow that only writes a report today can gain a CSV export or a second notification later. The analysis step in the middle is the recipe. It shows the notebook name, how many cells run, and a badge for each kind of data source the cells query, which is the fastest way to see what a run touches without opening the code.

​

Running and Scheduling

The Scheduled Run step at the top of the graph is the trigger. It shows the cadence, the time, and the timezone the Workflow runs in, along with the date of the next run. Open it to change any of them. The schedule offers None, Hourly, Daily, Weekly, Monthly, and At times. A few details worth knowing:

• Daily lets you restrict which days actually run, so weekdays-only is a daily schedule with the weekend deselected.
• Hourly runs on an interval, from every hour up to every 12 hours, on a minute you pick.
• At times runs at several specific times in the same day rather than on an interval.
• None disables the schedule without deleting the Workflow or its history. Run Now still works.
• Times display in your local timezone and are stored converted, so a schedule set in New York does not drift for a teammate in London.
• Schedule changes are not saved until you confirm them.

Run Now in the header triggers an immediate run without touching the schedule. Use it to confirm a change worked, or to refresh a number ahead of a meeting. Runs happen in the background, so the result appears once it completes rather than instantly. The status in the header opens the run history. Each entry shows the outcome, Succeeded, Failed, Partial, or Running, and whether it was scheduled or a manual run, so you can tell an automated result from one someone triggered by hand.

​

Checking a Run

Open a run from the history to see its steps. Each step reports whether it completed and how long it took, and steps that produced something carry a View link straight to that artifact. When a run fails, the failure surfaces on the Workflow entry on the project page. Open the failed step to see the error that stopped it. Common causes are a data source that went unreachable, a schema change, or credentials that expired. See Troubleshooting. Partial means some steps finished and others did not, so it is always worth opening to see which.

​

Notifications

When a run finishes, a Workflow can email the result out. Open the Notification step on the graph to control what gets sent and who gets it:

• Message: the body of the email that goes out, which you write yourself.
• Artifacts: which of the Workflow’s outputs and exports get attached. Each report and export is a checkbox, so a Workflow that produces three things can send all three or just one.
• Recipients: who receives it, chosen as Users, Groups, or Emails. Users covers people already on the project, searchable by name or email, and Groups covers the project’s groups. Emails takes any address you type, which is how you reach someone outside the project.

​

Notification Preference

Recipients control who gets email. A notification preference controls when. Write it in plain language when you create the Workflow and Orion turns it into a condition that gets evaluated on each run:

• “Only notify me when there is a significant change”
• “Only if churn goes above 5% or a new anomaly shows up”
• “Always notify me”

A Workflow with no condition set notifies on every run.

​

Shaping and Publishing the Result

Opening an output step gives you its Report Configuration, which is where you control how the result is written and where it lands.

• Report Style: formatting, structure, length, tone, and emphasis, in plain language. This is the main lever for what the output reads like. “Executive summary, one page max” and “five slides for a board meeting” both belong here.
• Publish URL: the address the result is published at, /share/ plus a slug you choose. Set it to something recognizable like weekly-revenue.
• Report Visibility: who inside the project can view the result.
• Context Sources: the notebooks behind the report, plus any Knowledge Base pages you attach as ground truth and the template covered above.

Because the Publish URL is stable and every run republishes to it, one link stays current forever. That is what makes a Workflow worth handing to someone who will never open Orion. A run’s output is also reachable from the graph itself: each output step carries a thumbnail of its most recent result, and View latest result opens it. Published outputs appear in the Published Content section of the project page too.

​

Editing a Workflow in Chat

Some changes are easier to describe than to click. Open in Chat, at the bottom right of the graph, drops you into the project chat with the Workflow already referenced and a prompt started for you. You can do the same from scratch in any project chat by typing @ and picking the Workflow, the same way you reference a metric or a Knowledge Base page.

​

Working With Workflows Elsewhere

The MCP server exposes Workflows to AI assistants like Claude Code and Cursor. You can list them, read their configuration, trigger runs, and pull execution results. See MCP Tools.

​

Deleting a Workflow

Delete removes the Workflow and its entire run history, and cannot be undone. If your goal is only to stop the emails and the scheduled runs, set the schedule to None and clear the notification’s recipients instead. That keeps the recipe and its history intact so you can start it again later.

​

Next Steps