Features

An application feature is a single capability that can be turned on or off — typically gated by subscription tier, security group, or per-tenant configuration. Features are the building blocks of feature sets and the granular currency in which permissions are sold.

What Makes a Feature

A feature has:

• A key — used in code (audit_log).
• A friendly name — used in tier-comparison pages (Audit Log).
• A group — for visual organisation (Security & Compliance, Integrations, etc.).
• A description — what the feature does in customer-friendly language.
• A default state — on or off when no other configuration applies.

How Features Are Checked

Application code asks: $AM->featureEnabled('audit_log'). The lookup checks: per-tenant override → feature set membership → security group permission → default. The first match wins.

Examples of Features

• Functional: Audit log, advanced search, custom dashboards, API access.
• Limits: Max users, max records, max storage — implemented as features whose “value” is the limit.
• UI: White-label branding, custom logo, hidden navigation items.
• Integrations: Stripe, SendGrid, Slack — each can be a feature gate.
• Beta flags: New experimental capabilities surfaced to a subset of tenants first.

Worked Examples

• SaaS pricing page: The features list drives the tier comparison table on the marketing site — single source of truth.
• Beta programme: A “new_dashboard” feature gate, enabled per-tenant. Beta testers see it; everyone else doesn't.
• Custom enterprise: An “Enterprise” tier where individual features are toggled per-tenant for bespoke contracts.

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.