Skip to main content
You have the menu built and the price list ready. None of that sells yet: what’s missing is saying which store, which channel and which fulfillment type they’re used for. That decision is this screen, and it’s also where you press the button that pushes the menu to the channel. Go to Restaurant OS → Menu and Products → Menu assignment.
Menu assignment matrix by store, channel and fulfillment

​
The minimum you need to know

1. The unit is the row: store × channel × fulfillment. One row per possible combination. The same store appears several times, once per channel and fulfillment type it serves.2. A row needs a menu and a price list. With only one of them it can’t be synced: the button stays disabled.3. Assigning does not publish. Publishing is Sync. And Sync sends what exists at that moment, not what existed when you assigned.

​
The simple path

You opened a new store and it needs to start selling:
  1. Filter by that store with the Store selector.
  2. On each row you care about, Assign menu.
  3. On the same row, Assign list.
  4. Select the rows and Sync.
The status turns Pending, and when the channel confirms it settles on Synced. That’s it.
If your operation is one store and one channel, you’re done. The rest of the manual is for when it’s forty stores and they all have to change on the same day.

​
The matrix: one row per combination

Each row is a real selling destination. These are its columns: At the top there are seven filters — store, group, channel, fulfillment, menu, list and sync status — and a search that matches store, menu and channel names. With forty stores and five channels the matrix has two hundred rows: the filters are not decoration.
What store groups are for. A group lets you filter every store in a region, a brand or a format at once, and assign them the same menu in a single operation. Without groups, changing a region’s delivery menu means ticking stores by hand and missing one.

​
Assigning in bulk

Tick several rows with the checkboxes and the bulk action bar appears: Assign menu, Assign list and Sync, with the count of what’s selected.
Bulk action bar with rows selected
The dialog always states how many combinations the change will apply to before you confirm.
Assign menu dialog
It also works the other way round: Remove assignment takes the menu or the list off the selected rows. A row without a menu can no longer be synced, but it keeps the last snapshot it already sent. Up to 200 combinations can be touched in one go.

​
The fulfillment rule

The assign-menu dialog does not show you every menu. Only the ones serving that row’s fulfillment type, plus the agnostic ones — the Golden, which serves them all. It’s the same criterion that makes a menu’s fulfillment type final: a delivery menu on a dine-in row means nothing.
If you selected rows with mixed fulfillment types, all you’ll see is the Golden. The screen says so: “The selection mixes fulfillment types: only agnostic menus (Golden) can be assigned.”It isn’t a screen error: it’s that no custom menu serves two fulfillment types. If you meant to assign your delivery menu, filter by Fulfillment first and work one type at a time.

​
Sync: what actually happens

Sync does three things, in this order:
  1. It flattens the menu. It takes the menu’s structure, applies the assigned list’s prices, and builds a flat menu with no inheritance and no formulas: the literal list of what is sold and for how much.
  2. It sends it to the channel. The status turns Pending.
  3. It waits for confirmation. The channel answers later, on its own time, and the status settles on Synced or Failed.
The four sync states in the Sync column
While there are rows in Pending, the screen refreshes itself every fifteen seconds. No need to reload or sit watching: you can walk away and come back. The button stays disabled — “Assign a menu and a price list first” — while the row is missing the menu or the list. That’s on purpose: without a list, every price would go out at zero.

​
The snapshot is from now, not from yesterday

There are no versions. Sync sends the current state. It takes the menu and the list exactly as they are saved in that second. There is no “publish Monday’s version” and no going back to an earlier snapshot.That has a practical consequence worth keeping in mind: if somebody left the menu half-edited, that’s what goes out. Before syncing in bulk, it’s worth confirming the menu is in the state it should be.
The reverse is also true, and that’s the comfortable part: you don’t need to “republish the menu” after changing a price. That row’s next sync already carries the new price, because it reads the list at that moment.

​
It synced, but something was left out

A row can end up Synced and still have dropped things along the way. When that happens, a warnings chip appears in the Sync column.
The first one is the one that costs sales in silence. The sync says Synced, the menu reached the channel, and that product is simply not on the menu the customer sees. Nobody gets an error: you have to open the warnings to find out.It’s fixed by giving the product a price in the list assigned to that row and syncing again.

​
Batches: 50 at a time, one at a time

You can select as many rows as you like, but each dispatch processes at most 50. If you selected 120, the first 50 go out and the screen tells you: “Syncing the first 50 rows; 70 left for the next round”. On top of that, the channel processes one batch per vendor at a time. If a dispatch is in flight, the next one waits. It isn’t an arbitrary limit: flattening a menu is expensive, and sending two hundred menus at once ends in timeouts and half-finished syncs, which is worse than going in batches.
If you’re going to sync many rows, do it in tidy batches — by region, by channel — instead of selecting everything. When something fails you’ll know exactly which group to check.
Selected rows missing a menu or a list are skipped automatically, and the screen tells you how many.

​
Seeing exactly what was sent

The eye button, View sync preview, opens that row’s last snapshot. It’s the only way to answer “what did the channel receive?” with certainty.
Preview of the snapshot sent to the channel
It has three tabs:
  • Menu — the menu as it ended up: categories, products, prices and modifiers.
  • Snapshot JSON — the same menu, raw.
  • Sync payload JSON — exactly what was sent to the channel.
The top line says when it was generated. If the row was never synced, the button is disabled: “No snapshot generated yet”. For an argument with a channel — “this never reached me” — the last two tabs are the evidence.

​
Changing the price for a single destination

There’s a separate screen, Prices and availability, for adjusting prices and visibility on one specific destination without opening the whole menu or the whole list. It works on the rows that already have a menu and a list assigned from here. Its rule is worth knowing, because it isn’t obvious:
  • The price you change there lives in the list, and that list may be shared by several destinations.
  • Visibility lives in the menu, which may also be in use across several destinations.
  • But saving syncs only that one row. The other destinations pick the change up on their next Sync.
In other words: the change is already saved for everyone, but only one of them published it. The screen says so in a banner before you save.

​
Recipes: how the real cases get solved

  1. Filter by the store with the Store selector. Its rows will appear, one per channel and fulfillment type.
  2. Select all the ones that store will serve.
  3. Assign list with the list that belongs to it.
  4. Assign menu — remember to filter by Fulfillment and do it one type at a time, or the Golden will be all you can assign.
  5. Select everything again and Sync.
  6. Wait for the statuses to go from Pending to Synced, and check whether any row came back with warnings.
  1. Filter by Group with that region’s group, and by Fulfillment on delivery.
  2. Select every row.
  3. Assign menu with the new menu. The dialog confirms how many combinations it applies to.
  4. Sync. If it’s more than 50, go in batches: the screen tells you how many are left.
The price list is untouched: changing the menu doesn’t change what things cost.
  1. Filter by that Channel.
  2. Select the rows.
  3. Assign menu → Remove assignment.
The rows are left without a menu and can no longer be synced. Careful: this does not delete from the channel what was already sent — that gets turned off on the channel. What you achieve is that no future change reaches it.
After saving the increase in the price list:
  1. Filter by Price list with the list you touched. Every row using it comes up.
  2. Select all of them.
  3. Sync, in batches of 50.
No menu needs to be opened: the flattening reads the list at that moment and carries the new prices.
Walk it in this order, which goes from the most common to the rarest:
  1. Is the row Synced? If it’s Failed, that’s where the trip ended.
  2. Are there warnings? If the product has no price in the assigned list, it wasn’t sent — that’s the most frequent cause.
  3. Open View sync preview → Menu tab. If the product isn’t there, it never left Fire.
  4. Open the assigned menu. Check whether it’s removed (Removed) or hidden (Hidden).
  5. Check Out of stock. It may be turned off by the day’s operation.
If it does appear in the preview and still isn’t visible in the app, the problem is no longer in Fire.

​
A price change, followed end to end

You raised a product from 10.90 to 11.99 on the Delivery list. This is what happens at each link: The row to watch is the third one: a Synced status doesn’t mean what’s published is current, it means the last sync went through. If you changed prices after that dispatch, the channel is still on the old ones until the next.

​
Mistakes that cost money

Changing the menu or the list and not syncing. The assignment is saved and the channel keeps selling with the previous one. Synced refers to the last dispatch, not to what’s in the menu today.
Ignoring the warnings chip. The sync goes through and products still never reached the channel. The most expensive one is the product with no price in the assigned list: it drops out of the dispatch without anyone getting an error.
Syncing 200 rows and assuming they all went. They go 50 at a time. The screen says how many are left, but the notice goes away: if you don’t look again, half the stores are stuck on the old menu.
Syncing with the menu half-edited. Sync sends what is saved at that moment, with no versions. A menu somebody left half done gets published half done.
Removing the assignment thinking it pulls the menu off the channel. Removing it stops new changes from reaching it, but the last thing sent stays published on the channel’s side.

​
Glossary

​
Frequently asked questions

The sync is missing. Assigning only records which menu that row uses; the channel finds out when somebody presses Sync.
The row is missing the menu or the price list. Both are needed: without a list, every price would be published at zero. The tooltip says it: “Assign a menu and a price list first”.
You selected rows with mixed fulfillment types. A custom menu serves a single fulfillment type, so in a mixed selection the Golden is the only assignable one. Filter by Fulfillment and do it one type at a time.
The channel rejected the dispatch. Check that the menu has products and the list has prices, and sync that row on its own to see whether the error repeats. On the menu you’ll also see the “Sync failed — menu snapshot is outdated” banner.
No. There is no versioning: every Sync flattens the menu and the list exactly as they are at that moment. To go back, you undo the change on the menu or the list and sync again.

​
What’s coming

  • Versioned snapshots, so an earlier state can be republished without undoing changes by hand.
  • Aggregator channel status: today aggregators receive their events, but the outcome isn’t reflected in the sync status you see here.
  • Bigger batches: the 50-per-dispatch cap is a defense against timeouts, not a goal.