> ## Documentation Index
> Fetch the complete documentation index at: https://www.orwel.io/docs/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.

## Configure a journey

**1. 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.

**2. Name and question**

Give it a name and the question it answers ("How many trials turn into paying accounts").

**3. Milestones**

Add steps from the catalog. Each step should mean real progress (`project_created`, `teammate_invited`), not navigation noise like page views or clicks.

**4. Final conversion**

Pick the conversion that closes the journey.

**5. Filters (optional)**

Filters match flat event properties (for example `plan: "pro"`). Use them sparingly, they make reports slower.

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

**1. Name, icon and color**

For example "Projects", with the icon you want in the Features report.

**2. Events that count as usage**

Add the codes from the catalog. Any of them counts as using the feature.

**3. Active users window**

The number of days used to count someone as an active user of the feature.

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](https://www.orwel.io/docs/guides/dev-mode.md). 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.