Skip to main content
The Metrics Catalog is a workspace-wide list of metric definitions that any project can use. A project metric belongs to the project that created it. A catalog metric is defined once and placed wherever it is needed, so revenue means the same thing on every board that reports it. Use the catalog when more than one team tracks the same number. Instead of four projects each carrying their own revenue metric, one definition sits in the catalog and each project draws from it.

Finding the catalog

Open Metrics Catalog in the Context section of the left sidebar. It is available to admins, analysts, Group Admins, and Group Analysts.

Metric status

A catalog metric can store a definition before it can run. Each entry carries a status:
  • Live: has run successfully, or is scheduled to run
  • Not run yet: has not run successfully yet
  • Paused: the schedule is paused
  • Error: the last run failed
  • Cannot run: there is no definition Orion can execute
Cannot run means Orion cannot execute the metric yet. Add a metric created from SQL to a project to make it runnable. For an imported metric, try importing it again.

Adding a metric to the catalog

Most catalog metrics start in a project. Create a project metric, then promote it so other projects can use the same definition and results. Tenant admins can also create a catalog metric from SQL. Import / export opens four choices:
  • Import from a project: promote metrics that already exist in a project
  • Import from dbt: import governed metrics, which dbt keeps and runs
  • Import an Apache Ossie document: upload a document, review what it contains, and pick where the metrics land
  • Export to Apache Ossie: export catalog metrics as an Ossie document
Admins, and analysts who are also Group Admins, see Manage connections, which opens the dbt integration settings. To promote one metric on its own, open it from the project’s Metrics page and use Add to catalog in its detail sheet.

Creating a metric from SQL

Tenant admins also see New, which creates a table metric from a SQL query:
  1. Click New
  2. Enter a Name, choose a Data source with your query’s tables, and write the SQL query
  3. Click Create metric
The query must be a single SELECT. Creating the metric does not run it, so check the SQL before you save. Add it to a project before running or scheduling it. Until its first placement, only admins can manage it.

The inventory

Open a metric from Inventory to place it in a project or change its definition. Use the Cannot run card to find entries that need attention.
The catalog loads up to 5,000 metrics. Past that, the page says how many loaded, and search and filters cover only the loaded ones.

Projects and Sources

Use Projects to find where catalog metrics are used, then Manage metrics to open a project. Use Sources to check where a definition is managed before you change it.

Placing a metric in a project

A catalog metric reaches a project as one of two kinds, shown under Project Usage on the metric page:
  • Shared: the project reads the catalog definition. Every shared project updates together
  • Project copy: the project gets its own copy, which runs on its own and keeps its own results
Shared is the default. Use it when projects should read the same result from the same run. Choose Project copy for separate schedules, data sources, and run histories. Catalog definition changes still apply to every project copy, which keeps its own data-source choices. Some metrics support only Shared value. If Orion says a metric runs on an external integration, choose Shared value. A metric already placed in a project cannot be switched from one kind to the other. To place a metric:
  1. Open the catalog metric and click Add to project under Project Usage
  2. Choose a project and select Shared value or Project copy
  3. If data-source choices appear, point each query at a data source in the selected project
  4. If Test appears, run it and check the result
  5. Click Add after any required test passes
Adding another placement requires permission to change the metric in every project that already uses it, plus membership in the target project. Removing a project copy from Project Usage keeps it as an independent project metric. Choose Also delete this project’s copy to delete it instead.

The metric page

What Orion Understands draws the metric’s neighborhood from your written Context pages. A solid line means a page states the relationship. A dashed line means Orion concluded it. Click a line to read the sentence it came from and open the page that carries it. Generate draws the picture the first time, and Refresh redraws it. Both require permission to change the metric. You can read an existing diagram without that permission. A Changes since last refresh badge appears when a cited page has changed. Metric Owners records who owns the metric. Where this Metric is used lists the reports and workflows that read it, and counts anything sitting in a project you cannot open. Source and Definition holds the query and the transformation. A metric that Orion can run will not save until a test run passes. Each save goes into the edit history, with an optional change summary. For writing and visualizing a metric, see Managing Metrics. If the metric feeds published reports, Orion names them and asks once before saving, because the next build of each one uses the new numbers. The … actions menu carries Run now, Schedule runs, a lock switch, and Delete. Locking blocks edits to a metric’s name and definition until somebody unlocks it.
Delete removes the catalog entry permanently. Project copies remain as independent metrics unless you select Also delete each project’s copy, which permanently deletes them too.

Restricting a metric to a group

Catalog metrics are visible across the workspace by default. To narrow one:
  1. Open the group in Configuration
  2. Choose its Metrics Catalog tab
  3. Use Add metric to name the metrics or folders that group may see
A restriction is an allow list, and it outranks placement. Once a metric is restricted, only members of that group see it, even in projects they share with everybody else. Admins and analysts are not affected.
Restricting a metric removes it from viewers who could previously see it through a project, and they are not told. Check who relies on a metric before you restrict it.

Permissions

  • Viewers: see a catalog metric placed in a project they can reach, restricted to their group, or created by them. They open the metric page and read its value, owners, usage, definition, and project copies
  • Group Analysts and Group Admins: also open the catalog from the sidebar, which lists the metrics they can read. Group Admins also manage which catalog metrics their group can see
  • Analysts: see every catalog metric, and can promote and import. Changes to an existing metric require membership in every project that uses it
  • Admins: do all of that for every metric, create metrics from SQL, restrict metrics to groups, and manage metrics that are in no project
A viewer with no group seat has no Metrics Catalog row in the sidebar, and reaches a metric through the project that uses it.