Features / Inspect
Inspect a user
Inspect answers "why is this person seeing that?" — "Search a user by email to see exactly which features they get in the active env — and the rule that decided each one." It's read-only: it verifies your targeting, it doesn't change it.
How to use it
- Search a user by email and select them from the results.
- Read the effective features table — one row per feature, with the status they'd resolve to right now and the reason behind it.
- Optionally set or clear the user's plan inline (the pencil) to see how their access would change.
Inspect always reflects the active environment — switch the Test / Live toggle to inspect that world. It shows the deployed value, and where a change is staged it reads deployed → staged with an ·after deploy hint, so you can preview the effect of work you haven't deployed yet.
The reason column
The reason tells you which layer won — exactly the resolution order from Targeting:
| Reason | What decided it |
|---|---|
static | The feature's static status (active / hidden / new …) — no per-user resolution needed. |
user_override | A user rule matched this user (directly or via a pack) — the User tier. |
plan | A plan rule matched the user's plan — the Plan tier. |
paywall_no_plan | The paywall is on and nothing grants this feature — locked for everyone. |
paywall_off | The paywall is off, so plan gating is inert — the feature resolves to enabled. |
suspended | The user is banned — plan-gated features are hidden. |
default | No rule matched — the fallback applied. |
Changing what you find
Inspect doesn't edit access. To change what a user gets, add or reorder a rule in Targeting, adjust the plan matrix in Plans, then Deploy — and come back here to confirm.