Defining a New Feature

When you build a new capability that you want to monetise (or gate behind a flag), register it as a feature. This article walks through doing that.

Step-by-Step

1. Open Architect Panel → Application Features and click New Feature.
2. Pick a key — lower-case, underscores, stable forever (e.g. weekly_report_pdf).
3. Friendly name — short, customer-readable (e.g. “Weekly PDF report”).
4. Group — pick or create a category (e.g. Reporting).
5. Description — explain it as you'd say to a customer (3-4 sentences).
6. Default state — usually off for new features so they don't accidentally light up for current tiers.
7. Customer-visible — tick if it should appear on the pricing page comparison table.
8. Tier mapping — tick the feature sets this feature belongs to.
9. Save.

Using the Feature in Code

Wherever the code paths diverge for tiers, check the feature: if ($AM->featureEnabled('weekly_report_pdf')) { /* generate PDF */ }.

Lifecycle

• Birth: Defined disabled-by-default; rolled out to internal testers.
• Beta: Enabled for a small set of tenants; collect feedback.
• GA: Mapped into appropriate feature sets and marketed publicly.
• Sunset: When deprecating, mark deprecated; existing tenants keep access; new tenants don't get it.

Worked Examples

• API rate limit: Feature key api_rate_limit, value field stores the per-tenant limit. Free = 100/min, Pro = 1000/min, Business = 10000/min.
• Single sign-on: Feature key sso, boolean, included only in Enterprise feature set.
• Beta dashboard: Feature key dashboard_v2, off by default, enabled per-tenant via the support team during beta.