QSmartQ Support

ShiftQ · How-To

Order Board defaults and Toast Dining Types

Design shared Order Board defaults at group scope and manage Toast Dining Types and live orders at each location.

PENDING-RELEASE — Availability is limited. This article does not describe the feature as generally available.
Verified 2026-09-04 · Source c8faf30a · Requires product verification

What this does

Design shared Order Board defaults at group scope and manage Toast Dining Types and live orders at each location.

Steps

  1. Choose the parent group or All Locations to configure shared display settings and Dining Type categories.
  2. Use Apply to all locations to copy shared settings to the group locations. Local Toast IDs, menu exclusions, badge mappings, and campaign references are preserved.
  3. Select one location and open Order Types. The page reads saved Dining Types without contacting Toast.
  4. An Order Board Editor can select Refresh from Toast to update that location's snapshot. Check Last refreshed and the added, removed, and changed counts.
  5. Add the required saved Toast Dining Types and map each to a shared category explicitly. Matching names do not imply matching Toast IDs.
  6. Select Keep local Dining Type settings on Apply to all when that Dining Type needs an override. Save Settings to persist your mappings.
  7. Verify the location's Player output. The Admin editor uses a demo preview; live order processing runs independently.

Source availability is not production activation

The current source describes saved location Dining Types and an explicit Refresh from Toast action. It does not establish that the revised frontend and required Functions have been deployed to your account. The source-only merge does not activate the optional private Player projection or retire existing Player access. No deployment, refresh or migration was performed by this Support audit.

What happens next

Your change is available within the scope you selected.

Warnings

  • This revised Dining Types workflow is merged into current source, but deployment and activation have not been verified by this Support audit. Confirm availability before relying on the revised controls. A source merge does not refresh Toast, change mappings or migrate Players.

Troubleshooting

  • If Dining Types have never been loaded, an Editor must refresh once. Read Only users can view the state but cannot refresh.
  • If Toast is temporarily unavailable, saved Dining Types and configured selections remain available. Wait a minute before retrying.
  • A removed Toast Dining Type is kept in your configuration for review. Remove or replace it deliberately.
  • Shared settings are materialized by Apply to all; this is not continuous inheritance. Later local edits remain until the next apply. Explicit Dining Type overrides survive that apply.
  • Parent scope does not display or store live orders. Select the exact location to investigate its live queue.
  • If multiple locations have identical Toast IDs, refresh each exact location and compare IDs against its saved snapshot. Equal names do not prove equal IDs. Preserve valid local IDs and have an Editor confirm each remap; retain the before/after mapping diff and change record.
  • If a Player link stops working during a security migration, verify its assigned location and pairing with Support. Do not make raw order collections public or copy another location?s IDs to bypass access checks.

Was this helpful?