Features¶
A feature is a single capability key in your catalog. Features are the atoms of packaging. Each has a kind that never changes after create.
Kinds¶
| Kind | Meaning | Check result |
|---|---|---|
flag |
On/off capability (sso, csv_export) |
allowed: true \| false |
limit |
Numeric entitlement (seats, storage_gb) |
limit: N \| null (null = unlimited) |
Properties¶
| Field | Description |
|---|---|
key |
Stable identifier your code uses. Immutable after create. |
kind |
flag or limit. Immutable after create. |
name |
Human label for admin UI |
description |
Optional detail |
created_at / updated_at |
Timestamps |
key is unique within your organization.
Design rules¶
- One feature = one gate. Don’t overload a key to mean three product behaviors.
- Keys are an API contract with your app — rename means a code change.
- Prefer a limit feature when the product question is “how many,” not “yes/no.”
- e10s does not track usage against limits — only the entitled value.
Who manages them¶
Vendor admins create and update features. Runtime checks only read keys; they never define them.