Package built-in capabilities with your product
Wildo supplies named feature definitions for built-in capabilities such as single sign-on, audit access and directory provisioning. Your products can grant those identifiers alongside application-specific features.
This keeps commercial packaging connected to the controls that consume it. A grant enables eligible use; the corresponding engine capability, provider configuration and access rules still establish how it works.
Example — Include enterprise sign-in in a plan
A team plan grants single sign-on. An eligible customer administrator can then configure the organisation’s identity-provider connection once the application’s SSO resources and runtime are available.
For engineers
CoreFeature names entitlements. EngineCapability controls engine availability; it is not automatically converted into a sellable feature. Applications add their own definitions through customFeatureDefinitions on a shared module and use product grants to package both sets.
These two actual engine definitions show independent commercial identifiers:
{
identifier: CoreFeature.SINGLE_SIGN_ON,
valueType: FeatureValueType.BOOLEAN,
applicableScopes: [ResourcePrimaryScope.ORGANIZATIONS],
dependencies: [],
defaultValue: false,
},
{
identifier: CoreFeature.AUDIT_LOGS,
valueType: FeatureValueType.BOOLEAN,
applicableScopes: [ResourcePrimaryScope.ORGANIZATIONS],
dependencies: [],
defaultValue: false,
},
The excerpt is from core-feature-definitions.shared.ts. Both are organisation-scoped booleans with a false default. Enabling one does not imply the other. Read the feature’s actual consumer before presenting it as an automatic complete product: a definition with no attached check does not enforce anything by its existence.
Combine built-in and application features deliberately
A product can package the same advanced-reporting feature from the definition-to-operation example alongside the built-in sign-on entitlement. This complete typed grant list is an illustrative extension of an existing organization offer, not the current Wonder Todos Enterprise package:
import { CoreFeature, type ProductDefinition } from '@wildo-ai/saas-models';
import { ApplicationFeature } from '@wonder-todos/shared-lib';
export const organizationOfferFeatures: NonNullable<ProductDefinition['grantedFeatures']> = [
ApplicationFeature.ADVANCED_REPORTS,
CoreFeature.SINGLE_SIGN_ON,
];
Assign the list to that offer’s grantedFeatures, retaining its targetScopes, prices and lifecycle settings. Keep the application definition registered; do not redeclare CoreFeature.SINGLE_SIGN_ON, which already has an engine definition. A published product grant still needs the subscription/ledger synchronization path before it affects a customer.
The two features have different consumers. Reports require the authored operation variant and FeatureGate shown in the linked guides. The built-in SSO settings destination declares entitlementFeatureId: CoreFeature.SINGLE_SIGN_ON, organizational management roles and runtime availability, then opens the registered SSO resources. That is a concrete settings consumer; it does not prove every SSO backend path is commercially gated. Enterprise settings gates and customer integration configuration explain those separate responsibilities.
Keep deployment, purchase and setup distinct
| Layer | Authoring surface | What it establishes |
|---|---|---|
| Runtime availability | Application engine/provider configuration | The service and resources exist |
| Commercial entitlement | Product grantedFeatures or an authorised override | This owner is eligible to use the feature |
| Customer setup | Scoped configuration resource | Its provider, connection or delivery destination is ready |
| Access control | Roles, membership and operation policy | This caller can configure or use it |
Settings destinations combine runtime availability, roles and entitlement IDs. The underlying services retain their own required setup. A customer does not get a working identity-provider connection simply because a plan contains SINGLE_SIGN_ON.
Verify the particular feature you sell
Core numeric definitions such as member/API-key allowances describe counting resources but are not automatically installed as create checks by core registration. An application that sells an enforced cap must wire its operation check. This differs from custom defineLimitFeature declarations using countResource.
Keep a specification beside custom definitions so application tooling can explain their meaning. Use the actual registered identifiers in products and consumers; translating a package enum or a display label into a new feature name breaks that connection.