Privacy consent choices
Some Customer App experiences can show a privacy notice with two choices. The pinned source records one versioned accepted or opted-out state; it does not establish purpose-specific receipts. Whether the notice appears and the wording shown depend on the current app variant, project, account, and stored preference state.
The notice is not a universal privacy, tracking, notification, permission, or provider switch. The current pinned implementation does not establish complete preference settlement, provider withdrawal, or a customer-visible place to review and change the choice later.
Understand what the choice can cover
| Purpose or control | How to interpret it |
|---|---|
| Processing needed for a requested app, account, security, order, or payment experience | It can have a separate required-purpose boundary and is not necessarily controlled by an optional privacy choice. |
| Optional measurement, personalization, or external-service features | The current notice can make selected optional features eligible or ineligible only when their approved purpose is included. |
| Promotional email, SMS, or push preferences | These are channel-specific account choices. They are not the same as the global privacy notice. |
| Operating-system permissions | Notification, location, photo, camera, and tracking prompts are controlled by the device. The app notice does not grant or revoke them. |
| Provider account or installation state | An external service can have its own identity, installation, retention, or deletion lifecycle. Hiding its UI does not prove that lifecycle ended. |
The notice shown in the current app is the only customer-facing source for the purposes it claims to cover. Do not infer additional coverage from a missing notice, a visible feature, an OS permission, or another Customer App project.
Recognize the preference states
| Observable state | What it can mean | What it does not prove |
|---|---|---|
| Preference is still loading | The app is checking local or account-related state. | That optional processing is allowed or denied. |
| Notice is visible | The applicable choice is unresolved for this app state. | That every provider is inactive or that no data has already been processed. |
| Notice is absent | The notice can be disabled, already resolved, unavailable, or still affected by configuration/account state. | Acceptance, opt-out, permission, provider availability, or durable synchronization. |
| Accept choice was recorded in the app | The app intends to permit the optional purposes represented by that notice. | That a provider is configured, available, authorized, or successfully initialized. |
| Opt-out choice was recorded in the app | The app intends to keep the represented optional purposes off. | That all providers, identifiers, queued work, prior data, OS permissions, or marketing preferences were removed. |
| A signed-in account is present | The app can attempt to reconcile a preference with account settings. | Atomic save, latest-wins behavior, another-device synchronization, or provider teardown. |
| The app is offline or a save fails | The visible in-app state and durable local/account state can differ. | That repeating the choice is safe or that the earlier result was not saved. |
Separate local and account settlement
A choice can first update the current app state and local storage. For a signed- in customer, Customer App can also attempt to reconcile a versioned preference with account settings.
Those layers have different failure modes. The app can hide the notice after a local choice even when storage or account synchronization is not confirmed. The current source does not provide a visible pending, failed, retry, or conflict state for that settlement.
Do not assume a timestamp or an apparently newer device preference always wins. Account switch, project switch, app reinstall, cleared storage, private-device use, or another device can produce a different unresolved state.
Keep account, project, and device scope separate
The current local preference is device storage, while a signed-in preference can also involve account settings. The pinned Customer App does not establish a complete customer-visible contract for:
- which project or app variant owns a local preference;
- how the preference moves between signed-out and signed-in states;
- whether one device choice should apply to another device;
- how account or project switching clears provider identity and cached state;
- how withdrawal affects work already queued or data already sent; or
- where the customer can review or change the global privacy choice later.
Account settings can contain separate notification-channel choices; they do not currently prove a global privacy-preference management screen.
Distinguish provider initialization and withdrawal
A future accepted implementation must mount each optional integration only after its approved purpose gate. The current pinned paths do not establish that rule for every native or external integration.
Other native or required-purpose integrations can have a separate initialization boundary. Source or package presence does not prove that any integration is enabled in the installed build.
An accepted withdrawal contract must stop future optional work, reject late callbacks, remove or rotate applicable external identities and installations, clear queued work and listeners, and prevent state from crossing an account or project change. The current pinned paths do not establish that complete cleanup.
Troubleshooting
The privacy notice does not appear
A missing notice does not reveal whether it is disabled, already resolved, unavailable, or still loading. Do not change device permissions or marketing preferences to force it to appear.
The notice returns after a previous choice
App reinstall, cleared storage, a different device, account or project change, or an unconfirmed save can require another resolution. Use only the current notice; do not copy preference data from another account or device.
The notice disappears but optional behavior is unclear
The app can settle visible state before durable local or account state is confirmed. Avoid repeating the choice rapidly. Record the approximate time, app version, signed-in/signed-out state, and visible result without including account details or screenshots with private information.
An OS permission prompt appears separately
Treat it as a device permission, not as confirmation of the app privacy choice. The feature-specific permission guide owns its result and recovery.
An optional external feature remains visible after opt-out
Visibility alone does not prove continued data use, and hiding UI does not prove provider cleanup. Keep the behavior unverified and report the feature class and visible state without provider identifiers or personal data.
When this guidance needs revalidation
The privacy-choice contract must be reviewed again when notice purposes or wording, preference versioning, local/account synchronization, account/project scope, OS permission handling, provider initialization/withdrawal, notification preferences, external policy destinations, or retention/deletion behavior changes.
Keep your information private
Do not share account details, preference records, full links, provider identifiers, device tokens, screenshots containing personal information, or private policy/account data when asking for help.
Related guides: Account settings · Platform and accessibility considerations · Location permission states · Native integration boundaries · Push-notification boundaries