> ## Documentation Index
> Fetch the complete documentation index at: https://orwel-22af1265.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Journeys and features setup

> Design what to measure in the dashboard, then hand your developer or coding agent the exact code to send.

The **Development** section of the dashboard has two configurators:

* **Journeys setup** (`/developers/journeys`): milestones that lead to a conversion, for example "Trial to paid". The Journeys report shows how many people reach each step and where they drop off.
* **Features setup** (`/developers/features`): the events that count as using a part of your product, for example "Projects". The Features report shows adoption among active users.

Both work the same way: you pick event codes from the catalog, Orwel generates the code to send them, and a status panel tells you which codes are already arriving.

## The event catalog

Every `track()` code has to exist in your workspace catalog, otherwise the ingest rejects it with `Event not found`. The catalog has two parts:

* **Orwel catalog:** a few hundred standard codes grouped by domain and vertical (sign up, checkout, project created, invite sent...). They are available to every workspace.
* **Custom codes:** your own codes. In the picker, choose **Custom event**, type the code (lowercase letters, numbers and `_`, up to 50 characters) and **Register and add**. When you save the journey or feature, the code is registered for your workspace only and the ingest accepts it from then on.

<Note>
  A custom code is released when nothing in the workspace uses it any more and it has not received events for 7 days. Conversions are not gated by the catalog: any `conversion()` code is accepted.
</Note>

## Configure a journey

<Steps>
  <Step title="Start from a blueprint or from scratch">
    The sidebar has ready made blueprints by category (Acquisition, Activation, Onboarding, Revenue, Retention). Pick one and adapt it, or create a new journey.
  </Step>

  <Step title="Name and question">
    Give it a name and the question it answers ("How many trials turn into paying accounts").
  </Step>

  <Step title="Milestones">
    Add steps from the catalog. Each step should mean real progress (`project_created`, `teammate_invited`), not navigation noise like page views or clicks.
  </Step>

  <Step title="Final conversion">
    Pick the conversion that closes the journey.
  </Step>

  <Step title="Filters (optional)">
    Filters match flat event properties (for example `plan: "pro"`). Use them sparingly, they make reports slower.
  </Step>
</Steps>

Steps count **in any order within the period**: a visitor who reaches step 3 before step 2 still counts for both. That is why milestones should be things that can only happen as real progress.

## Configure a feature

<Steps>
  <Step title="Name, icon and color">
    For example "Projects", with the icon you want in the Features report.
  </Step>

  <Step title="Events that count as usage">
    Add the codes from the catalog. Any of them counts as using the feature.
  </Step>

  <Step title="Active users window">
    The number of days used to count someone as an active user of the feature.
  </Step>
</Steps>

Each code has a **tier**, so coverage is deliberate:

| Tier | Meaning |
| - | - |
| 0, Reach | First contact with the product |
| 1, Activation | The first moment of value |
| 2, Core loop | What people come back to do |
| 3, Outcome | Business results |
| 4, Health | Errors and friction (growth is bad) |

## Implement

The **Implement** tab gives you the code for one journey or feature, or for all of them, in four formats:

| Format | Use it for |
| - | - |
| Agent prompt | Paste it into Claude Code, Cursor or any coding agent inside your repo. It lists every code, when to fire it and how to verify it. |
| Snippet | Copy and paste calls with example properties. Move each call to where the action is confirmed. |
| TypeScript | A typed module with one function per code, so typos and missing properties fail at compile time. |
| JSON | The exact configuration saved in Orwel, portable between workspaces. |

Fire each event right after the action succeeds (after the API call resolves), from your service or data layer rather than from buttons, and send it once per action.

## Status

The **Status** tab shows, per code:

| Status | Meaning |
| - | - |
| Receiving | Events with this code arrive from production. |
| Tested | It arrived with the [development key](/guides/dev-mode). It will count once it is sent from production. |
| No data yet | Registered, but nothing has arrived. Implement it and test it with the development key. |
| Not registered | The ingest will reject it. Register it as a custom event or pick a catalog code. |
| Rejected | The last development key request with this code was rejected. Open Dev mode to see why. |

A journey or feature is fully measured when every one of its codes is **Receiving**.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.