Understand feature availability and missing controls

Use this reference when a documented feature, button or provider is missing, or a visible action is rejected. A feature flag is one condition: it does not grant team access, supply credentials, start a missing service or give permission to read restricted documentation.

Diagnose the missing capability

1. Confirm the installation, application/team and selected documentation version. Use Access and teams to check the account's actual role and action permissions.
2. Check Settings → Features for the features enabled for your installation, then the task's Availability note. Distinguish a deployment-wide feature from a team plan/module entitlement or publication policy.
3. Ask the deployment operator to check the running services' effective configuration, not only the value saved in a configuration source. Web UI, API, workers and telephony can have different environments.
4. Check dependencies: provider credentials, permitted origins, shared variables, storage and the required service must work independently of the flag.
5. Retry a controlled action and verify its result. A visible control proves neither authorization nor successful execution; a hidden control does not establish that every API path is disabled.

Do not change the reported application version to make development-only controls appear. Request the intended supported configuration from the operator.

See which features are enabled

Availability: from 0.9.19. Every signed-in user who can open Settings sees the Features tab. It is read-only.

Open Settings → Features to check which optional deployment features are enabled for your installation, before you look for a missing control. The tab shows Features of your installation and lists each enabled feature with a short description, for example Browser voice (WebRTC), Audio preprocessing, SMS, Browser SDK, Additional AI providers, Subscription management, AI flow builder, Conversation QA scoring, Resilience controls or Documentation assistant. When none is enabled, it shows No optional features are enabled for your installation.

• The list shows only enabled features. A feature that is missing from it is off for the installation, or it is not one of the optional features the tab lists.
• The features apply to the whole installation. Every team in it sees the same list; it does not show team plans, modules or your own permissions.
• To change a feature, contact your platform administrator. The deployment operator changes the effective configuration, as described in Apply and verify an intended change.

Integration capabilities

Availability: from 0.9.18, the integration capabilities below are independently controlled and default to off. They replace the former combined API access setting. The deployment operator selects them in the Portal feature profile for the target release.

Capability	Environment variable	Services	What it controls
Browser SDK	FEATURE_BROWSER_SDK	API, Web UI	Team SDK keys, endpoint discovery, session HTTP routes, text, TTS and actions, /ws/session and team TTS usage
Browser voice (WebRTC)	FEATURE_WEBRTC	API, Web UI	Voice sessions and the browser phone; also selects the WebRTC gateway and TURN containers on the telephony host

Apply these rules when you plan or check a deployment:

• Set each value to the literal string true or false. The API and Web UI refuse to start when one of these variables has any other value.
• Browser voice requires Browser SDK. FEATURE_WEBRTC=true without FEATURE_BROWSER_SDK=true stops the API and Web UI at start-up with FEATURE_WEBRTC requires FEATURE_BROWSER_SDK=true. The Portal rejects the same combination before it saves a profile.
• Browser text and TTS need Browser SDK only. Browser voice also needs configured gateway infrastructure and a team whose API key grants the WebRTC channel.
• Deployment flags grant no team permissions, API-key scopes or documentation access.

Upgrade from 0.9.17

FEATURE_API_ACCESS and the Portal key apiAccess are retired. In 0.9.17-patch2, FEATURE_API_ACCESS was on unless set to false. Because Browser SDK now defaults to off, an installation that relied on that default loses the SDK routes after the upgrade.

1. Before you deploy 0.9.18, save an explicit Browser SDK and Browser voice selections in the Portal profile for the new release. Retired keys have no aliases and grant nothing.
2. Use Remove obsolete selection for each retired ID that the Portal reports, then preview again.
3. Deploy. With Browser SDK enabled, the database migration step moves team SDK keys stored under the former WebRTC key names to the Browser SDK names on every rollout. A team whose key cannot be migrated is listed in the step output and keeps working through a read fallback.
4. Verify that the running services match the selected profile and complete a controlled call through the enabled integration.

With Browser SDK enabled, verify session routes, browser text and TTS. With browser voice enabled, verify that voice connects through the configured gateway.

To roll back, restore the previous image, configuration, profile and documentation together. Changing only a flag back does not restore the previous combined API surface.

Web UI feature conditions

The following table describes how the Web UI decides whether to show feature-controlled controls. It is not a backend authorization matrix. Controls can add their own permission or data conditions.

Here, runtime ready means the browser's runtime-configuration object is present. Development version means its reported version is edge, local, latest or dev (case-insensitive). It does not mean any arbitrary staging build. Unless a row says otherwise, the resolver enables the flag when its value is not the exact string false.

Capability in the resolver	Configuration	Additional UI condition
Browser phone and call buttons	FEATURE_BROWSER_SDK and FEATURE_WEBRTC	Runtime ready and both exactly true (opt-in); the Flow Settings Browser block and its chat control use this too
Browser SDK configuration and API-key surfaces	FEATURE_BROWSER_SDK	Runtime ready and the exact value true (opt-in); team access and entitlement checks remain separate
My Subscription	FEATURE_SUBSCRIPTION_MANAGEMENT and FEATURE_REGISTRATION	Runtime ready; both flags must allow it
Custom Deals	FEATURE_SUBSCRIPTION_MANAGEMENT	Runtime ready
Modular mode and expanded realtime/transcription choices	FEATURE_ADDITIONAL_PROVIDERS	Development version; provider/plan support remains separate
Audio preprocessing	FEATURE_AUDIO_PREPROCESSING	Runtime ready; the processing service and plan restrictions still apply
SMS UI	FEATURE_SMS	Runtime ready; delivery credentials and worker conditions remain separate
TTS media cache resolver flag	FEATURE_TTS_MEDIA_CACHE	Development version; this resolver entry is not proof that a particular UI control exists
Self-service registration	FEATURE_REGISTRATION	Runtime ready; backend registration policy applies independently
AI Flow Builder	FEATURE_AI_FLOW_BUILDER	Runtime ready; see flow assistant availability
QA scoring resolver flag	FEATURE_QA_SCORING	Development version; existing conversation QA tabs are data-dependent, not universally hidden by this resolver flag
Resilience editors	FEATURE_RESILIENCE	Exact value true; see resilience controls for the plan condition
Custom subscription plans	FEATURE_CUSTOM_SUBSCRIPTION	Runtime ready and the exact value true; this flag is opt-in
In-app Ask AI	FEATURE_ALGOLIA_ASK_AI	Runtime ready and configured public Algolia application ID and search API key

The browser obtains configuration from /api/config. Values beginning with FEATURE_ are browser-readable, so never put secrets in feature flags. The route also provides selected public version and integration settings. If the configuration request fails, the client can fall back to a dev configuration with empty flags. Unexpectedly visible controls after a configuration error therefore do not establish the server's enabled features; investigate the request and effective server configuration.

Use literal lowercase false to disable the shared FEATURE_* convention and literal lowercase true for explicit opt-in. Do not substitute 0, FALSE or an empty string: the shared feature helpers and UI resolver do not interpret those as the string false. This rule concerns these feature flags, not every Boolean environment variable in the platform.

Deployment choices and effective service configuration

The Portal's deployment feature keys are configuration-generation inputs. They are not identical to the environment variable names or every UI condition above.

Deployment key	Important generated effect when disabled
browserSdk	Opt-in. When not selected, sets FEATURE_BROWSER_SDK=false for API and Web UI, so SDK keys, session routes and /ws/session are absent.
webrtc	Opt-in and requires browserSdk. When not selected, removes the webrtc and turn Compose services from TelPro and sets FEATURE_WEBRTC=false for API and Web UI.
audioproc	Removes Voice's preprocessing service, sets AUDIOPROC_ENABLED=false there and disables the Web UI preprocessing flag.
ttsMediaCache	Clears the configured cache URL/token/CA settings for Voice and API and disables the UI flag. The Media host's Compose services are not removed by this choice.
sms	Disables the SMS feature in the configured Web, API, Voice and worker/operations roles.
additionalProviders	Sets the Web additional-provider flag off. Resolver booleans alone do not establish a gated editor or provider-runtime authorization.
subscriptionManagement	Disables subscription-management values in affected roles and disables registration in Web, API and Ops. It can affect backend guards as well as presentation.
aiFlowBuilder	Disables the flag in Web, API and Ops.
qaScoring	Disables the flag in Web, API and Tasker. Existing stored scores remain a separate display concern.
resilience	Opt-in. Selecting it sets FEATURE_RESILIENCE=true for the Web UI; otherwise false. It does not erase saved policies or disable runtime recovery.
algoliaAskAi	Disables the Web flag; this deployment feature is opt-in when no deployment feature record exists.

The other listed deployment features default enabled when no explicit record exists. That does not mean all capabilities work by default: generated overrides, actual environment values, UI version conditions, credentials, entitlements and infrastructure still matter. Do not translate an older deployment key such as subscriptions, audioPreprocessing or apiAccess into a current entry. The Portal rejects the retired apiAccess key.

Resilience controls

Availability: from 0.9.18, the Portal feature profile drives FEATURE_RESILIENCE through the Resilience controls selection, which is off by default. The flag must be exactly true.

The flag shows the platform Resilience defaults card under Admin Settings and the team and flow resilience editors. When subscription management is enabled, the team and flow editors appear only for teams on the custom plan. When subscription management is disabled, the flag alone decides. Hiding the editors does not delete saved resilience policies, and runtime recovery keeps using them.

For container names versus image repositories, dependency placement and optional services, use Service topology. Removing a container from a generated bundle does not prove an old running container has already stopped.

Release profiles in the Portal

Availability: this workflow requires a Portal documentation operator account and an imported feature manifest for the exact release. A customer membership or a Delphi team administrator role alone is insufficient. A manifest import does not approve its release evidence or activate any deployment.

1. Open the Portal's Feature catalogue and choose the Context: Public documentation, a customer's defaults, or an explicitly assigned deployment. An unassigned deployment needs a customer owner before it can have a profile.
2. Choose the Release and manifest revision. Review the capabilities available in that release. Restricted features require the customer's current module entitlement; public documentation cannot select them. A capability absent from an older release is not supplied by today's catalogue.
3. Set the intended choices and select Preview selections. A new deployment draft takes a snapshot of valid saved customer defaults for the same release and manifest revision, when available; otherwise it starts from the release defaults. Review the displayed snapshot revision before overriding a choice. For an existing profile, the preview compares capability states, release modes, affected configuration keys and container removals with the saved profile. Resolve dependency, entitlement or obsolete-feature errors before saving. After changing releases, use Remove obsolete selection for each retired ID to keep other explicit choices, then preview again. Do not interpret an unavailable or renamed flag as permission to enable its replacement.
4. Select Save draft profile after the preview is valid. This creates a saved revision. It does not change running services or publish documentation. Customer defaults and existing deployment profiles are separate: editing a customer default does not silently update the deployment fleet.
5. Choose the next action for the saved revision using the table below. If another operator has changed the revision or customer access, reload, review the current state and preview again; do not repeatedly submit the stale draft.

Action	What it changes	What still needs to happen
Use saved profile for documentation	Selects the revision used to resolve documentation capabilities for that context and release.	The documentation for that context reflects the selected revision from its next publication.
Activate saved deployment profile	Selects the saved deployment revision for future configuration generation.	Generate, review and apply the resulting configuration, then verify running services. Release evidence must already be approved.
Reset draft selections	Clears explicit choices in the current unsaved draft.	Review the resulting defaults and preview again. This does not restore the prior running configuration.

Documentation selection describes the customer's or deployment's available product capabilities. It does not depend on whether a provider credential is currently configured or which team role the reader has. Those runtime and permission prerequisites remain in each task's Availability note. Access to customer-only documents still requires the correct account membership and entitlement; a feature selection is not an access grant.

Apply and verify an intended change

Availability: Changing deployment flags is an operator responsibility. Team administrators can resolve membership and team configuration but do not thereby gain control over deployment bundles or service environments.

1. Record the desired capability and affected service roles. Preserve the previous effective settings and the recovery path.
2. Change the approved source for that deployment, then regenerate or update the affected configuration using Deploy or update an installation. A Portal toggle or SSM edit by itself does not change a running process.
3. Apply the change through the service's activation procedure. Ensure each dependent service has the intended configuration before exposing the capability. Avoid exporting complete environments containing credentials just to verify a flag.
4. Reload the Web UI and inspect its relevant public configuration. Then exercise an authorized request or task against the backend. Test an expected denial when the change is intended to disable access.
5. Check the resulting conversation, job or diagnostic evidence. If behavior differs, compare the actual service environments and dependencies before toggling more flags.

A browser page reload updates its fetched configuration; it does not inject changed environment values into a running server. Restart/recreation and deployment reconciliation follow the affected service's procedure. For a wrong change, restore the previous configuration and repeat the same verification. Disabling a feature is not a rollback of data or already-performed actions.

Product feature availability and permission to read a customer/module document are separate. Enabling a feature does not grant documentation access, and a generic feature can be documented even when it is disabled in a particular deployment.

For subscription-related availability, check the actual plan, usage and billing state before changing a feature flag or account role.

Related

• Connect a browser application — to check API credentials and voice-versus-text prerequisites.
• Flow assistant availability — to diagnose the AI-assisted flow builder and its permission path.
• Application entry points — to find the channel controls for an application.
• Provider and channel setup — to review provider choices and plan-dependent configuration.
• Review a conversation — to interpret scores, actions and other data-dependent tabs.