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
- Confirm the installation, application/team and selected documentation version. Use Access and teams to check the account's actual role and action permissions.
- Check the task's Availability note. Distinguish a deployment-wide feature from a team plan/module entitlement or publication policy.
- 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.
- Check dependencies: provider credentials, permitted origins, shared variables, storage and the required service must work independently of the flag.
- 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.
Web UI feature conditions
The following table describes the TelWeb feature resolver, not a universal 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_WEBRTC | Runtime ready; the Flow Settings Browser block also uses this condition, including its chat control |
| API-key and API-access configuration surfaces | FEATURE_API_ACCESS | Runtime ready; 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 | Development version in 0.9.17-patch2; builder configuration must also work |
| QA scoring resolver flag | FEATURE_QA_SCORING | Development version; existing conversation QA tabs are data-dependent, not universally hidden by this resolver flag |
| 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 |
|---|---|
webrtc | Removes the webrtc and turn Compose services from TelPro and sets the Web UI WebRTC flag off. Verify API-side voice availability separately. |
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. |
apiAccess | Disables the API and Web feature values. |
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. |
algoliaAskAi | Disables the Web flag; this deployment feature is opt-in when no deployment feature record exists. |
In the reviewed registry, 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 or audioPreprocessing into an assumed current registry entry; check the actual registry and generated bundle for your version.
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.
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.
- Record the desired capability and affected service roles. Preserve the previous effective settings and the recovery path.
- 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.
- 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.
- 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.
- 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.
Continue with the specific task
- For API credentials and voice-versus-text prerequisites, use Connect a browser application.
- For channel controls, use Application entry points.
- For provider choices and plan-dependent configuration, use Provider and channel setup.
- For the creation path and release-specific AI behavior, use Create an application.
- For scores, actions and other data-dependent tabs, use Review a conversation.
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.