Offer enterprise controls independently
Single sign-on, directory provisioning and security-event delivery answer different customer needs. Their separate feature gates let you include them together or offer them independently.
The standard settings structure also checks whether the runtime is available and whether the person has the right role. Granting the feature opens an eligible configuration path; the customer still supplies its integration settings.
Example — Use sign-in before adding directory provisioning
A customer first configures its identity provider for sign-in. Later it adds directory provisioning without changing what single sign-on means or treating the two as one flag.
For engineers
A sellable feature answers whether a customer is entitled to a capability. It does not turn on the runtime, assign an administrator role or establish a connection. Keep those decisions connected without treating them as one flag:
| Decision | Where it is expressed | What it establishes |
|---|---|---|
| Runtime availability | Enabled engine surface and registered resources | The application can host the integration |
| Customer eligibility | Product grants or the owner’s entitlement overrides | This customer may use the feature |
| Administrator access | Settings destination roles and backend operation policies | This person may configure the selected customer |
| Integration readiness | Customer-owned configuration, credentials and verification | The integration has the inputs its runtime consumer needs |
The standard settings destinations connect these layers. SSO uses CoreFeature.SINGLE_SIGN_ON and opens its configuration and connection resources. Provisioning uses DIRECTORY_PROVISIONING and opens its configuration and token resources. Audit streaming uses SECURITY_EVENT_EXPORT and opens its export configuration and failed deliveries. Each destination checks runtime availability and organization-management roles before presenting its entitlement-gated body.
See what a backend consumer actually requires
Selected engine example: the directory-management helper checks the exact organisation’s feature and then looks for an active (not revoked) provisioning token. These are the complete decision statements from scim-provisioning-gate.backend.utils.ts; function parameters and source comments are omitted:
const featureEnabled = await featureResolution.isFeatureEnabledAtScope(
CoreFeature.DIRECTORY_PROVISIONING,
ResourcePrimaryScope.ORGANIZATIONS,
organizationId,
);
if (!featureEnabled) return false;
const activeToken = await systemAccessService.readAsSystem<{ _id: string }>(
CoreResourceType.ORGANIZATION_SCIM_TOKENS,
{ organizationId, isActive: true },
serviceOptions,
);
return activeToken != null;
Here organizationId is the already-established owner supplied by the calling engine workflow. readAsSystem is the engine helper’s trusted read, not an invitation to elevate a customer’s request. The result answers whether this organisation is actively directory-managed: an entitlement without an active token returns false. This management predicate deliberately does not check token expiry: an expired but unrevoked token still keeps the organisation classified as directory-managed. Token authentication and remote synchronization are separate checks; this result does not prove that the directory is reachable or that its next synchronization will succeed.
Different consumers have different contracts. Audit dispatch uses the selected organisation’s enabled SIEM configuration; it does not perform a fresh subscription lookup for every event. Do not infer an instantaneous delivery change from a plan change or from a settings tab disappearing. Follow the integration’s actual configuration and cache lifecycle.
Granting is not configuring
SSO needs a valid connection and provider configuration. Directory provisioning needs its enabled runtime and scoped provisioning credentials. Outgoing security-event delivery needs a destination. These are operational prerequisites even when the product includes the entitlement.
DIRECTORY_PROVISIONING, SINGLE_SIGN_ON and SECURITY_EVENT_EXPORT are independent definitions. Do not infer dependencies from a marketing bundle or from neighbouring settings tabs. M2M_WEBHOOK_DELIVERY also requires an exact-owner feature check because its definition has scopeBoundary: true.
Keep frontend discovery and backend decisions coherent
The standard settings destination makes an unavailable feature understandable; it is not a substitute for the backend integration’s own checks. Verify the service consumer, its required scope, and the configured provider when promising an enterprise control.
These feature names describe how an application packages capabilities for its customers. They do not define Wildo’s own open-core or commercial licensing boundary. That is a separate product decision, not something an enterprise label or a feature grant determines.