Skip to main content
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.
If all you want is “email me only when something changed”, write it as a notification preference instead. See Notification Preference. Reach for a decision step when the condition has to gate more than one thing.

​
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.
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.
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.