> ## Documentation Index
> Fetch the complete documentation index at: https://docs.encorekit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Enable a Use Case

> Which use cases are on by default, which need an explicit enable, and how to turn one on for your app.

Every integration surface (the Web SDK's `useCase` option, the iOS and Android SDKs, the
Encore API) reads the same per-app setting. Ask for a use case your app isn't enabled for
and the request is still well-formed, so nothing fails loudly: the SDK logs
`sdk_offer_presentation_failed` with reason `use_case_unavailable` and resolves as unavailable (the
exact result shape varies by SDK). This page is the cross-platform reference for what
"enabled" means and how to get there.

<Note>
  This page describes both use cases that exist today: [Reduce Churn](/publishers/use-cases/churn-intervention) (`churn-intervention`) and [Reward Users](/publishers/use-cases/post-action-reward) (`post-action-reward`).
</Note>

## Reduce Churn is on by default, no action needed

**Every app is enabled for `churn-intervention` from the moment it's created**, with no
setup step. An app with no explicit configuration for this use case still serves it: that
row's absence means "on," not "off," which is what makes every existing SDK integration
byte-identical to before this dimension existed. If you're only using the paywall/cancel-flow
offer sheet, there is nothing to enable.

## Reward Users needs an explicit enable

**`post-action-reward` is off by default.** An app with no row for it resolves every
request as not-enabled, so the SDK no-ops rather than falling back to the churn-intervention
experience. This is deliberate: showing a purchase-ask offer sheet on a "you did it!"
moment is exactly the failure mode the Reward Users use case exists to avoid.

### Turning it on

Open the app in your Encore dashboard, go to the **Analytics** view, and find
**Placements by use case** → **Turn on Reward Users**. The write is additive, so it never
touches the churn-intervention configuration you already have working, and idempotent, so
turning on a use case that's already on succeeds rather than erroring. Behind the button is
`POST /publisher/portal/v1/apps/{appId}/use-cases`.

<Note>
  This button is rolling out. If your dashboard doesn't show it yet, reach out to your Encore
  contact and they'll turn the use case on for your app.
</Note>

<Warning>
  **Ask for copy without accent markup, especially on web.** Encore's shipped default reward
  headline uses the SDKs' inline accent syntax (asterisks around the run to emphasize, as in
  `*gift*`), and support for it is uneven right now:

  | Surface | Renders `*gift*` as an accent run?                                                 |
  | ------- | ---------------------------------------------------------------------------------- |
  | iOS     | From 1.5.0, which hasn't shipped yet                                               |
  | Android | Not yet; its equivalent hasn't shipped                                             |
  | Web SDK | No. The Web SDK renders headline copy as plain text, so the asterisks stay literal |

  Until that evens out, a surface that doesn't support the syntax shows the asterisks on
  screen. Ask your Encore contact to set copy **without** the markup when they turn the use
  case on for you. On web that is the only way to avoid them, because the Web SDK has no
  accent-run rendering to wait for.
</Warning>

### What "enabled" gets you

Once enabled, a `post-action-reward` request resolves normally instead of `unavailable`,
and the offer sheet renders using:

* **A headline and subheadline**, customizable per app. Setting them is not self-serve yet:
  the dashboard has no copy editor, so ask your Encore contact to set them when they turn
  the use case on. Leave them unset and Encore's shipped default is used: headline
  `Congrats! We got a *gift* for you both to celebrate your 30-days streak!`, subheadline
  `Choose one of our partner offers below`. Both render even unconfigured, so don't assume
  an unset app shows nothing. Two reasons to set your own anyway: the default is
  streak-shaped even though the use case also covers purchases, milestones, and levels, and
  its asterisks are the accent markup from the preceding warning, which most surfaces still
  render literally.
* **The offers your app is otherwise eligible for.** Turning the use case on doesn't
  change which campaigns can serve; it only turns on the surface itself.

## Where the copy comes from

The headline and subheadline on the sheet resolve from up to three sources, in strict
priority order. The first one set wins, and each field resolves on its own, so setting only
the headline leaves the subheadline to fall through:

| Priority | Source           | Set where                                                                                                                                                   |
| -------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1        | SDK override     | `.headline()` and `.subheadline()` on the placement builder, on the native SDKs (iOS, Android, React Native, Flutter). The Web SDK has no per-call override |
| 2        | Dashboard value  | The copy configured for this use case on your app, as in the preceding section                                                                              |
| 3        | Encore's default | Shipped with the screen                                                                                                                                     |

You pass the finished string, so the wording, the tone, the pluralization, and any emoji
are yours to decide. There is no streak-count or milestone-count parameter: Encore never
assembles a sentence out of a count. A blank override is not an override, so the chain
falls through to the next source rather than rendering an empty line.

<Warning>
  **A per-call override beats dashboard-configured copy.** If a screen shows something other
  than what you set in the dashboard, check whether the call site passes `.headline()` or
  `.subheadline()`. The SDK value wins every time. That is deliberate, so a single placement
  can speak to the moment that triggered it, but it does mean a stray override outranks
  anything your team configures later in the dashboard.
</Warning>

## Declaring it in your Setup guide is a separate, cosmetic step

Project **Settings → Outcomes** lets you declare which use cases your project is building
toward; this personalizes which rungs your Setup guide shows, nothing more. **Picking
"Reward Users" here does not turn the use case on for your app**; that's the separate
per-app step this page describes. Outcomes answers what a project is building; the
per-app enable step answers "is it actually on." Today, you need both, and neither
implies the other.

## Related

* [Reduce Churn](/publishers/use-cases/churn-intervention): the always-on use case.
* [Reward Users](/publishers/use-cases/post-action-reward): the use case that needs enabling.
* [Post-Purchase Placements](/publishers/web/guides/post-purchase-placements): the Web SDK's `useCase: 'post-action-reward'` integration.