Features / Targeting

Targeting

Targeting decides visibility per user and per plan for features set to targeted in the Registry. Rules live in two tiers: User rules (checked first) above Plan rules (the fallback). Within a tier, order decides ties.

When targeting applies

Only features whose status is targeted consult per-user rules. A feature set to active (or new / beta / coming_soon / greyed) ignores user rules — but it is still plan-gated when the paywall is on (see Plan access); only hidden bypasses everything. So for user-level rules, step one is always: set the feature to targeted.

Targeting is available on paid Onelo plans — switching a feature to targeted or adding a rule returns 402 on Free.

How a user's status is resolved

For each targeted feature, the resolver walks this order and stops at the first match:

Suspended user

A banned user gets hidden for every plan-gated feature — nothing else is checked.

User rules (first match by position)

The lowest-position rule that matches this user wins — whether it names the user directly or targets a pack the user is covered by. This tier beats everything below it.

Plan rules (first match by position)

If no user rule matched, the lowest-position plan rule matching the user's plan wins.

Fallback

If nothing matched, the feature's fallback visibility applies (hidden by default, or upsell / greyed).

Position rules everything. Two rules can apply to the same user + feature — only the lower position takes effect; the other sits dormant until you reorder. A per-user rule placed above a pack rule is how you make one person an exception to a whole bundle.

Adding a rule

Click + Add rule and the wizard walks you through it:

Target

Pick a Feature or a Pack, then the specific item. Only targeted features are listed.

Condition

User (by email) or Plan. Multi-select is supported — pick several and the wizard creates one rule per selection in a single batch.

Visibility

The status matched users / plans see — enabled, upsell, greyed, hidden (and so on).

Upgrade (Upsell / Locked only)

When you picked upsell or greyed, a fourth step configures the upgrade prompt (the CTA and the plan it points to). Save, then Deploy.

Reorder, edit, delete

Reorder within a target with the ↑ / ↓ controls — the order is deploy-gated, so the SDK only sees it after you deploy.
Click a rule to edit it in the pre-filled wizard.
Click × on a rule to delete it; on a multi-rule target you'll confirm removing the whole batch.
Deletions of already-deployed rules are soft — hidden from the dashboard and SDK immediately, hard-removed on the next deploy. Re-add before deploying to recover.

Targeting changes don't reach your app until you Deploy (and Promote to Live for production). The pending counter tells you there's undeployed work.

Per-user overrides

A user rule is a per-user override keyed to a user's id. Because the User tier is checked before Plan rules, it's the precise tool for early access ("turn this on for these two testers") or exceptions ("this one QA account gets everything") without changing what any plan grants. Identify the user from your app first — see SDK integration.

Inspect a user→

See which rule actually decided a user's status.

Deploy & Promote→