Schedule and preorder states
Some Customer App experiences present an as-soon-as-possible choice or candidate future slots. A date or time shown by the app is only a candidate for the current context. It is not a reservation, business acceptance, server eligibility decision, or order commitment.
:::warning Important boundary
Scheduling controls can change cart-wide order timing without a final confirmation tap. Do not open, refocus, or revisit a scheduling surface to test whether a previous choice settled.
:::
Standard and catering surfaces differ
The current source has related but distinct timing controllers:
| Surface | Candidate behavior | Important boundary |
|---|---|---|
| Standard moment page | Can show as-soon-as-possible and generic future intervals within a date window | The generated interval list is not the business's final eligibility decision |
| Business-aware moment page | Can apply a supplied business schedule and business timezone | Business data can be missing, stale, or different from server validation |
| Catering preorder | Uses additional lead, range, interval, minimum-day, and maximum-day inputs | Malformed or missing inputs can change or empty the candidate list |
| Inline cart timing | Can select a next candidate automatically when catering constraints require it | Mounting or recalculating can write timing without a tap |
Do not assume these surfaces have identical schedules, confirmation behavior, or error handling.
A candidate slot has several gates
| Gate | What it contributes | What remains unresolved |
|---|---|---|
| App and project policy | Whether scheduling controls can appear | Current server and business eligibility |
| Order type | Which standard or catering rules are considered | Compatibility with every cart and item |
| Business or menu schedule | Candidate open intervals | Exceptions, capacity, closure, and server acceptance |
| Lead and date limits | Earliest and latest candidate windows | Whether the selected slot is still valid later |
| Interval generation | Candidate start and end labels | Business capacity or reservation |
| Cart and fulfillment context | Current delivery, pickup, reservation, or other timing inputs | Payment, placement, and order settlement |
| Server validation | Authoritative acceptance should occur against current context | Deployment behavior remains unconfirmed in this guide |
A visible slot can expire, disappear, or be rejected after any relevant input changes.
Timezone, clock, and interval boundaries
Scheduling can cross device, business, and server clocks. The app can calculate with the business timezone when one is available and otherwise fall back to a local device interpretation. Display formatting can then differ from the value stored or sent for reconciliation.
Day boundaries, daylight-saving changes, ambiguous or nonexistent local times, overnight business schedules, interval end times, and clock drift can all make a displayed candidate differ from business or server eligibility. Treat the business and server's current accepted time context as authoritative; a device label alone is not proof.
Selection, storage, and navigation settle separately
| Stage | What may change | What it does not prove |
|---|---|---|
| Date highlight | Local date and candidate list | Any cart timing write |
| Time highlight | Local time state or an immediate moment change, depending on surface | Server acceptance or reservation |
| Global moment change | Local order context, storage, or a server update can begin | That every write completed |
| Cart refresh | One or more carts can receive recomputed timing context | Same revision across every cart |
| Navigation away | The scheduling surface closes or another page opens | That the timing update settled |
| Checkout or order state | Later stages use the current timing context | Payment, placement, or order completion |
The current controller does not consistently wait for the timing update before calling the next callback or navigating away. A changed label or closed screen is therefore not a settlement receipt.
Automatic and no-tap changes
Several source paths can change scheduling without a deliberate final action:
- catering cart timing can select the next candidate during recalculation;
- a stored scheduled time that reaches expiry can reset to as-soon-as-possible;
- focusing one preorder surface can reset the current moment to as-soon-as-possible;
- changing a date can clear the prior time or moment before another time is accepted; and
- shared order context can propagate one timing change beyond the visible surface.
These are timing mutations, not passive display refreshes. Do not interpret an automatic fallback as customer confirmation, business availability, or a safe replacement for an expired slot.
Multi-cart and subtype consequences
A shared moment can affect more than one current cart. In a multi-business checkout, businesses can have different schedules, timezones, lead limits, interval rules, and eligibility. One candidate cannot be treated as valid for the whole group without an exact current per-cart result.
Gift, school, service/reservation, catering, delivery, pickup, and other order subtypes can have separate ownership and scheduling rules. A timing choice does not preserve a service reservation, student context, cart validity, payment state, or group completeness.
Unknown and partial outcomes
| Observed state | Safe interpretation |
|---|---|
| Date changed and prior time disappeared | Local clearing may have occurred; server/cart state is unresolved |
| Candidate became selected automatically | A no-tap write may be pending or partial |
| Screen closed after a selection | Navigation and timing settlement remain separate |
| Scheduled label changed to as-soon-as-possible | Expiry or focus logic may have reset timing; do not infer customer intent |
| One cart reflects the time and another does not | Multi-cart timing is partial |
| Slot disappears after refresh | Candidate generation or eligibility changed; no reservation is proved |
| Error or lost response appears | Local, stored, cart, server, socket, and plugin results can disagree |
| Checkout or order proceeds | Timing, payment, placement, and order settlement remain separate |
While the result is unknown, do not repeat the selection, reopen the timing surface, change the device clock, or place another order as a diagnostic.
Troubleshoot safely
| What you observe | Safe next check |
|---|---|
| Scheduling controls are absent | Treat scheduling as unavailable for the current context; do not infer a global fault |
| No candidate slots appear | Recheck the current business and order context without changing time or cart state as a test |
| Candidate labels look offset | Treat device/business/server timezone authority as unresolved |
| A slot ends outside business hours | Do not use it; interval-end eligibility must be reconciled |
| Selection closes the screen too quickly | Treat the timing write as unknown; do not repeat immediately |
| A stored time resets automatically | Reconfirm current context through an approved path; do not treat the fallback as intent |
| Multi-cart times disagree | Preserve per-cart uncertainty; do not infer group readiness |
| Account, project, business, or order type changed | Disregard prior timing results and rely only on the current context |
Support reports should use only a value-free state class, such as “scheduled moment unresolved.” Do not include real dates, times, timezones, business or customer data, cart/order identifiers, links, or private screenshots.
Privacy and accessibility
- A scheduled time can reveal location, routine, fulfillment, school, service, or event context. Keep timing details out of documentation and support notes.
- Date tabs, time choices, as-soon-as-possible state, selected/disabled/busy/ expired/error state, and interval start/end need explicit accessible text.
- Horizontal date lists and time grids must remain operable without relying on color, borders, motion, or haptics.
- At large text sizes, slot labels and warnings should reflow without hiding the selection state. Focus should return predictably after confirmation, Back, or automatic expiry.
- Screen-reader, keyboard, switch, safe-area, Back, reduced-motion, timezone, and daylight-saving behavior require current-platform verification; this guide does not certify them.
Recertification triggers
Revalidate this reference after changes to standard or catering controllers, business/menu schedules, lead/range/interval/date-limit policy, timezone or DST handling, interval ends, device/server clock use, global moment storage, expiry timers, focus behavior, automatic selection, navigation, multi-cart propagation, order subtypes, payment/placement, sockets/plugins, or accessibility primitives.
Also recertify after changes to API deployment authority, server eligibility, operation versioning, idempotency, stale-response cleanup, or unknown-outcome recovery.