Manage saved addresses
Customer App can present account-saved addresses and address actions when the current account, configuration, and entry context allow them. A visible row, selected style, confirmation, navigation, or success message does not by itself prove that every related address and order-context change settled.
:::warning Address changes can affect an active order context
The saved default address and the address currently used by order options are separate identities. They can disagree while a request is pending, fails, or settles only partially. Address changes can also affect business availability, delivery options, cart state, fees, or totals.
:::
Saved-address states
| Visible state | What it can mean | What it does not prove |
|---|---|---|
| Loading placeholders | The saved-address read has not completed in this view. | That an address exists or that earlier rows are current. |
| Saved-address rows | The app received records that it can render after local filtering and deduplication. | One-to-one record count, current ownership, freshness, or successful mutation. |
| Selected-looking row | The row fields match the address held by the active order context. | That the row is the account's saved default or that a server update settled. |
| Empty list | No saved row is available in the returned state. | Why the list is empty or whether another account or project has records. |
| Filtered empty state | No rendered row matches the selected label. | That the underlying list is empty. |
| Error or unavailable state | The current read did not produce a usable list. | Address absence, mutation failure, or a safe retry outcome. |
The list can offer label filters, add and edit entry points, a delete confirmation for some rows, and different return destinations. Availability depends on the current Customer App variant and context.
Saved default and active order address
| Identity | Purpose | Important boundary |
|---|---|---|
| Saved address record | Account-owned delivery-location data | A visible row is not proof of current authorization or freshness. |
| Saved default address | The account record marked as default | Sorting or editing can change which record appears first; no textual default marker is guaranteed. |
| Active order address | The address currently held by order options | Selected styling can be based on matching address fields rather than saved-default identity. |
| Cart delivery context | Business, delivery, product, fee, and total state derived for the active address | It can lag behind or reject an address change independently. |
Do not assume that changing one identity atomically updates all the others.
Visibility is not settlement
| Visible event | Safe interpretation |
|---|---|
| Add or edit form opens | An editor became visible; no address has been validated or saved. |
| Delete confirmation opens | A destructive choice is being presented; nothing has been deleted yet. |
| A row disappears | The current list changed; active order options and cart context may still require reconciliation. |
| A row becomes selected | The app updated or compared local order-address state; saved-default and server settlement remain separate. |
| The app navigates away | The caller changed screens; pending address or order-option work may still fail or finish later. |
| A success message appears | One reported operation returned success; downstream order/cart/provider state may still be unknown. |
Repeated selection, deletion, submission, Back, or reopening is not a safe way to resolve an unknown outcome. Preserve the latest visible state as unresolved until the owning address and order surfaces reconcile it.
Typed address, precise location, and providers
Address entry can involve typed text, suggestions, geocoding, precise coordinates, a map, device location, or an external provider. These are different boundaries:
- typing can begin suggestion or lookup work before an address is saved;
- choosing a suggestion can return structured address and location data;
- a map can render or adjust a precise point through a provider;
- device location depends on an OS permission and native location state; and
- permission, provider, map, and address-save outcomes can settle separately.
A visible map, pin, suggestion, or permission result does not certify address accuracy, ownership, serviceability, provider approval, or persistence. This guide does not instruct location permission, map, provider, or address mutation steps.
Unknown and partial outcomes
| Situation | Safe interpretation |
|---|---|
| Navigation occurs before the selected row is confirmed | Default and active order context remain unknown. |
| Address save reports an error or stays loading | Do not infer whether a record or downstream selection changed. |
| Saved default and selected styling disagree | Treat them as separate identities awaiting reconciliation. |
| Delete result and active order address disagree | Do not assume an automatic fallback address. |
| Address changes but cart availability or totals do not | Cart propagation can be stale, rejected, or partial. |
| Permission is denied or unavailable | No device location was established; provider and manual-entry behavior remain separate. |
| Provider or map is unavailable | No address-save or order-context outcome follows from provider failure alone. |
| Account or project changes during work | Discard the prior context; late results must not be applied to the new one. |
Privacy and accessibility
Addresses, notes, precise coordinates, account context, and cart relationships are private. Do not place them in screenshots, copied links, diagnostics, or support notes. Use only value-free state descriptions such as “saved list unavailable” or “address context unresolved.”
Selected, default, loading, error, pending, disabled, destructive, and unknown states need text and semantic status rather than color or icons alone. Add, edit, delete, location, map, Back, and confirmation controls need clear names, roles, state, focus order, and predictable focus return. This is a required verification posture, not a claim of current accessibility certification.
Troubleshooting safely
- A missing row or control does not reveal whether another address exists.
- A selected style or screen change is not a mutation receipt.
- A provider or permission error does not establish address-save failure.
- A repeated action can duplicate or race pending address and cart work.
- Conflicting saved/default/order/cart states remain unknown until reconciled.
- Do not substitute a copied address, coordinate, provider value, or private link to force another result.
When to recertify
Repeat isolated review after changes to account/project identity, list loading or filtering, saved-default rules, add/edit/delete behavior, order-option or cart propagation, navigation timing, typed-address lookup, maps, geocoding, location permissions, provider configuration, accessibility semantics, or the App/components/API authority pins.
Related guides: Review your profile · Add or edit an address · Choose a delivery location · Review location permissions · Understand map boundaries