Account settings
Customer App can expose Languages, promotional Notification preferences, Security/Sessions, and Logout as separate surfaces. Their visibility and settlement depend on the current account, project, configuration, session type, device, and provider lifecycle.
A selected language, changed switch, removed session row, or closed account screen does not prove that every local, server, device, push, or provider state settled. If a response is lost, keep the outcome unknown and do not repeat a destructive action merely to force a visible result.
Keep the settings surfaces separate
| Surface | What it can control | What it does not prove |
|---|---|---|
| Languages | The app's selected language and translation context | That every screen, cached value, provider, or returned service message changed together |
| Notifications | Promotional email, SMS, and push preferences for the current account | OS notification permission, device installation ownership, provider delivery, or eligibility for unrelated features |
| Security / Sessions | A supported session list and explicit controls for one, current, other, or all sessions | Immediate revocation everywhere, provider logout, push teardown, or removal of cached private state |
| Logout | A separate server/local sign-out request for the current app session | That every other session, device installation, provider identity, room, callback, or notification preview was removed |
A missing row is not an error or proof that the capability can be enabled.
Mount-time work and explicit actions
Opening a settings surface can already cause reads or state work:
| Surface opened | Possible mount-time work | Explicit customer action |
|---|---|---|
| Profile settings | Resolve row visibility and available languages | Select one available row |
| Languages | Load languages and translations; reconcile a stored or default language | Select a different language |
| Notifications | Refresh current account data and initialize promotional channel state | Change one channel switch |
| Security / Sessions | Load a supported session list | Revoke one session, revoke all except current, revoke all including current, or request session management activation |
| Logout control | Rendering the control does not sign you out; local notification-installation state is read when Logout is requested | Request Logout |
Opening Notifications can begin preference persistence from initialized state without waiting for a switch. Do not assume that opening the screen is read-only; treat a preference as changed only after an explicit action and a current result.
Language selection and settlement
Language has more than one state: the visible selection, locally stored choice, shared app/API language, and returned translation dictionary. Selecting a row can update the visible choice before every layer refreshes.
If text changes only partly, loading continues, or the previous language returns, treat the outcome as unsettled. Do not repeatedly select languages or switch projects to test it. A language row can also be absent when fewer than two eligible languages are available.
Notification preferences, permission, and delivery
These states must remain separate:
| State | Owner | Boundary |
|---|---|---|
| Promotional channel preference | Current account/settings service | Requires explicit channel-specific consent tied to its purpose, account, project, policy, and time |
| OS notification permission | Device operating system | Permission does not create account consent or prove a device installation is current |
| Device notification installation | App/backend lifecycle | Must belong to the current account/project/device generation and rotate or be removed safely |
| Provider acceptance | Push provider | Does not prove OS presentation, customer viewing, or correct current audience |
| In-app operational status | Owning order/message/account surface | Must be authorized and reconciled independently of marketing preference or OS permission |
Turning a promotional preference off must not be described as revoking OS permission or proving device/provider teardown. Likewise, enabling OS permission must not opt the account into promotional email, SMS, or push. Notification state is not a valid eligibility rule for an unrelated feature.
Security and session actions
| Action | Safe interpretation |
|---|---|
| Load sessions | A point-in-time list for a supported session strategy; entries can be stale or incomplete |
| Revoke one other session | A revocation request for that selected session; the local row is not authoritative revocation confirmation |
| Revoke the current session | A revocation request that can lead to local logout only after a supported response |
| Revoke all except current | A request to keep the current session and revoke the others |
| Revoke all including current | A request that can lead to local logout after server settlement |
| Activate session management | A request to change how sessions are represented; it is not a new login or universal device reset |
Session revocation and device/provider teardown are different operations. A revoked session must stop its authorized use, but removing a session row alone does not prove that push installations, socket rooms, cached SDK credentials, or late callbacks were cleared.
Logout is a separate lifecycle
Logout can request server sign-out, then remove local session state and reset selected app state after a supported response. It can also pass the currently known notification installation to the server. This is not the same as revoking all sessions and does not prove complete push/provider cleanup.
If Logout loses its response, server and local state can disagree. Do not assume that a returned Profile screen, missing row, or retained notification proves success or failure. Re-establish the current signed-in state through the normal app entry before changing settings again.
Optimistic and unknown outcomes
| Observable outcome | Safe interpretation |
|---|---|
| Selection or switch changes immediately | Local/optimistic presentation; server settlement may still be pending |
| Success message appears | One response was accepted; other local/device/provider layers remain separate |
| Error appears and the control stays changed | Local and server state may disagree; do not infer rollback |
| Session row disappears | The local list changed; authoritative revocation and downstream teardown require confirmation |
| Screen closes or account returns to entry | Navigation/local state changed; server logout or revocation can still be unknown |
| Response is lost or app restarts | Keep the exact operation unknown; do not automatically repeat it |
Troubleshooting safely
A settings row is missing
Use only the rows currently available. Do not use a private route or another account/project to force the surface.
The language changed only on part of the app
Treat translation state as unsettled. Avoid repeated language or project changes until the current app context is stable.
A notification switch changed or returned to its prior state
Treat the account preference as unknown. Do not change OS permission or send a test notification to determine the result.
Notifications still appear after a promotional preference is off
Promotional preference, operational notices, OS permission, device installation, and provider delivery are separate. Do not infer that one of those layers failed or succeeded from a single notification.
A session action is busy, errors, or loses its response
Do not repeat it or choose a broader revoke-all action. Reconcile the current session list through the same authorized Security surface.
Logout returns an unexpected screen or notifications continue
Do not infer complete sign-out or provider teardown. Avoid copying account, session, device, or notification details into diagnostics.
Accessibility and privacy
Every row, language choice, notification switch, current-session marker, destructive action, confirmation, busy/error/unknown state, and Logout control needs a clear name, role, state, consequence, focus order, and predictable return. Large text must keep consequences and cancel actions visible; screen readers must announce selection, checked state, current session, progress, error, and unknown settlement without exposing private session or device data.
These are accessibility and privacy requirements; they do not establish current support in those areas.
What can affect settings
Settings behavior can vary with Profile row gates; available-language reads, storage, API language or translations; notification defaults, preference mount/toggle behavior, consent, OS permission, device installation or push provider lifecycle; session list/strategy/current/all revocation; Logout server/ local teardown; account/project switching, socket/provider cleanup; accessibility; or changes in the app, its components, or related services.
Related guides: Profile and account overview · Privacy and consent · Use the app offline and reconnect · Platform and accessibility behavior · Push-notification boundaries · Customer App experience variants