Capabilities

Only show a flow (survey, form, or message) when the current app version can support it.

Last reviewed

Capabilities

Use capabilities when a flow should only appear for people whose current app version can support it.

They are most useful when you have just shipped new or changed functionality. Some people may still be using older cached app code, an older mobile build, or another runtime that does not support the new experience yet. Capabilities let the flow wait until the app reports that it is ready.

Add a capability condition

In the flow delivery settings, open Advanced and choose Runtime has capability.

Enter the capability your app will report, such as:

checkout.drawer

Use a trailing wildcard when several related capabilities should qualify:

checkout.*

checkout.* matches checkout.drawer and checkout.modal. It does not match billing.drawer.

Report capabilities from your app

Send the capabilities the current app version supports when you load the widget. If capabilities change after the page loads, update them at runtime. The widget checks for newly eligible flows after capabilities change.

Browser SDKs apply runtime updates after the widget has loaded. If you use disableAutoLoad: true, include capabilities known before client.load() in the initial options, or call client.load() before awaiting configure().

For the browser global API, see the JavaScript snippet.

JavaScript SDK

Pass the supported capabilities when you create the client:

TypeScriptapp.ts
import { createClient } from "@getuserfeedback/sdk";const client = createClient({apiKey: "YOUR_API_KEY",capabilities: ["checkout.drawer"],});

If capabilities become available later, update them with configure() and handle a rejected update:

try {await client.configure({capabilities: ["checkout.drawer", "messages.compose.v2"],});} catch (error) {console.error("Unable to update capabilities", error);}

React SDK

Pass the supported capabilities in the provider's clientOptions:

TypeScriptapp.tsx
import { GetUserFeedbackProvider } from "@getuserfeedback/react";export function Root() {return (<GetUserFeedbackProviderclientOptions={{apiKey: "YOUR_API_KEY",capabilities: ["checkout.drawer"],}}><App /></GetUserFeedbackProvider>);}

If capabilities are only known or can change at runtime, omit capabilities from the provider options. Let one descendant own the complete current list and update it through useGetUserFeedback():

import { useEffect } from "react";import { useGetUserFeedback } from "@getuserfeedback/react";function CapabilitySync({ capabilities }: { capabilities: string[] }) {const client = useGetUserFeedback();useEffect(() => {async function updateCapabilities() {try {await client.configure({ capabilities });} catch (error) {console.error("Unable to update capabilities", error);}}void updateCapabilities();}, [capabilities, client]);return null;}

React Native SDK

Pass the supported capabilities in the provider's clientOptions:

TypeScriptapp.tsx
import { GetUserFeedbackProvider } from "@getuserfeedback/react-native";export function Root() {return (<GetUserFeedbackProviderclientOptions={{apiKey: "YOUR_API_KEY",capabilities: ["checkout.drawer"],}}><App /></GetUserFeedbackProvider>);}

If capabilities are only known or can change at runtime, omit capabilities from the provider options. Let one descendant own the complete current list and update it through useGetUserFeedback():

import { useEffect } from "react";import { useGetUserFeedback } from "@getuserfeedback/react-native";function CapabilitySync({ capabilities }: { capabilities: string[] }) {const client = useGetUserFeedback();useEffect(() => {async function updateCapabilities() {try {await client.configure({ capabilities });} catch (error) {console.error("Unable to update capabilities", error);}}void updateCapabilities();}, [capabilities, client]);return null;}

Example uses

New checkout drawer

You ship a checkout drawer in your web app and want to show the flow only where people can see it. Add a condition for checkout.drawer.

People on old cached app code, old mobile builds, or pages that still use the previous checkout flow will not see that flow.

Changed message composer

You replace your message composer in stages. Add a condition for messages.compose.v2, then ask about the new composer only where it is available.

If several composer variants should qualify, use messages.compose.*.

Recording replay surface

You release a recording replay panel gradually. Add a condition for recording.replay, so the flow only appears once the user's app version can open that panel.

New command palette

You add a command palette in a new app release. Add a condition for command-palette, so the flow only appears after the user's app version can open it.

Good capability names

Pick names that make sense in your app. We do not require a naming scheme.

Good names are specific enough to target:

  • checkout.drawer
  • messages.compose
  • recording.replay

Keep names stable. If you rename a capability in your app, update any flow conditions that use the old name.

Next steps