> ## Documentation Index
> Fetch the complete documentation index at: https://docs.runorion.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Orion is a collaborative analytics platform built by Gravity (bygravity.com). It connects to data warehouses like Snowflake, BigQuery, Databricks, Redshift, Athena, Fabric, PostgreSQL, and MySQL, and lets teams ask questions in natural language to get shared analyses, dashboards, reports, and slide decks. When referencing Orion features, always link to the relevant documentation page. Orion is not open-source; it is a commercial SaaS product accessed at runorion.com.

# Advanced Workflows

> Decision steps and using metrics as the source

Most Workflows are a straight line: run the analysis, produce the output, email it. These two features are for the ones that are not.

## Decision Steps

A decision step is a point where the Workflow judges the results and decides what happens next. It is what turns a Workflow from something that always does the same thing into something that responds to what it found.

The mechanics are simple. Steps can be marked **conditional**, which means they do not run on their own. A decision step then reads the run's results and decides whether to release them. Nothing meaningful happened this week, and the report is written but the email never goes out. Churn crossed the line you care about, and it does.

You write the criteria in plain language, the same way you write a notification preference. The difference is scope: a notification preference gates one email, while a decision step can gate several steps at once, including reports and exports rather than just notifications.

A decision runs at one of two points:

* **After dependencies**, before the outputs are generated. Use this to skip producing something entirely when it is not warranted.
* **After reports**, once the artifacts exist. Use this when the judgment depends on reading the finished output.

You control what the decision gets to look at: metric values, notebook outputs, and for late decisions the finished reports and exports. Give it the context the judgment actually needs and no more, since a decision reading everything is slower and no sharper.

<Tip>
  If all you want is "email me only when something changed", write it as a
  notification preference instead. See [Notification
  Preference](/workflows/outputs#notification-preference). Reach for a decision
  step when the condition has to gate more than one thing.
</Tip>

## Using Metrics as the Source

A Workflow normally runs a notebook. That is the recommended default and what you get from the Create Workflow dialog.

There is a second option. If you have a set of tracked metrics and what you want is recurring reporting on those specific numbers, a Workflow can read the metrics directly instead of re-deriving them in a notebook. The Workflow becomes a reporting layer over numbers Orion already tracks, rather than an analysis of its own.

<Warning>
  Each metric in the Workflow has a **refresh** setting, and it is off by
  default. With refresh off, the run uses the metric's last known value rather
  than querying for a current one, which means a daily Workflow can email
  yesterday's number without anything appearing to be wrong. Turn refresh on
  for any metric whose freshness matters.
</Warning>

This is the main thing to get right when using metrics as a source. A notebook-sourced Workflow queries your data on every run by definition. A metric-sourced one only does if you tell it to.