Keep a connected menu item matched by tracking its identifier in each system, not just its display name. Before a change, decide whether the item is truly the same product, a replacement or a returning item. Then give one person ownership of the change and retest the expected order after publication.
A rename may preserve an existing connection. Deleting an item and creating another with the same name may not. The result depends on how your POS, ordering channels and integration handle their identifiers. Ask the provider to show you that behavior before relying on it during a busy service.
Know which menu change you are making
A mapping connects an item selected on one menu to the item that should appear in the POS and kitchen workflow. Names help people recognize items, but they are not always reliable keys. Two items can share a name, and one item can have different names across channels.
Rename: same item, new display name
Changing “Garden Burger” to “Garden Veggie Burger” may be a rename if the underlying product, options and kitchen instructions remain the same. Check that the item retains its identifier in the POS and that each connected channel still points to the intended item. Also check any channel-specific name that staff or guests will see.
Do not assume a name change is harmless if the recipe or fulfillment has changed too. A new allergen, preparation instruction or required choice can make the old mapping inappropriate even when the identifier remains stable.
Replacement: new item behind a familiar name
Suppose a restaurant replaces a bowl with a different recipe but keeps the same public name. Decide whether the existing POS item should be updated or a new item created. That decision affects reporting and kitchen instructions as well as integration matching.
If you create a new item, record the old and new identifiers and explicitly remap each connected listing where required. A familiar name alone does not prove that an order will reach the new item. Check sizes, required choices and optional add-ons separately; an item can arrive correctly while one of its modifiers does not.
Deletion and seasonal reactivation
Deleting an item can remove or invalidate a reference another system still uses. Before deletion, check whether an unavailable or inactive state is an option in each system. Ask what happens to connected listings and existing mappings in either case.
A seasonal return deserves the same attention. Restoring an old item may preserve its identifier, or the workflow may create a new one. Even if the old mapping survives, the current price, recipe, modifiers and availability may have changed. Record what you expect before putting the item back on sale.
Record identifiers and give each change an owner
For every connected item, keep a record of the POS item ID and the corresponding ID or reference used by each ordering channel. Include variant and modifier references when those are mapped separately. A stable identifier is useful only if the systems actually use it to maintain the connection, so ask where to find each reference and what actions can change it.
Names still belong in the record: they make the IDs understandable to staff. Add the location, channel, expected POS item, current price and availability. If the POS is supposed to supply the price or availability to a channel, note that too. If someone maintains either field separately, name that person.
One change owner should coordinate the whole job, even if different people edit the POS, an aggregator and a direct ordering menu. The owner does not need every login. They do need confirmation of who made each edit, when it was published and who will check the result. A kitchen lead can confirm the preparation details while the person responsible for online ordering checks the guest-facing listing.
Ask your provider these questions for your actual POS, locations and channels:
- Which identifier keeps an item matched after a rename? Does changing a category or variant affect it?
- What happens to the mapping if an item is deleted, duplicated, archived or restored?
- Are modifiers and prices synchronized, mapped separately or maintained by a person?
- How are unavailable items handled, and how long can a published change take to appear?
- Who can see a failed match, and what can staff do while it is being corrected?
If you are comparing connection approaches, the guide to direct POS integration and middleware helps frame the discussion. For ongoing maintenance, ask for the answer for each connection rather than assuming that all channels behave alike.
Use a change log and retest the result
The following log is hypothetical. The identifiers and prices illustrate a restaurant's own records, not the behavior of a particular product. The POS item is the expected destination; each retest checks whether the published channel selection reaches that destination with the right details.
| Change | Expected match and state | Owner and action | Retest and record |
|---|---|---|---|
| Rename: Garden Burger to Garden Veggie Burger | Channel item C-14 still matches POS P-208; price $12; available | Ordering lead updates the display name; POS lead confirms P-208 remains the intended item | Simulate one order; record the test ID, P-208, $12 total and kitchen name |
| Replacement: new recipe replaces the old bowl | Channel item C-31 should match new POS P-319, not old P-115; base price $14; required sauce choice present | POS lead creates P-319; ordering lead updates the connection | Simulate one bowl with sauce; record P-319, choice and $14 total if sauce has no added charge |
| Seasonal return: squash soup | Channel item C-46 should match POS P-412; price $8; unavailable until the planned opening date | Menu owner confirms the recipe and whether P-412 is restored or newly created | Check the unavailable state first; after opening, simulate an $8 order and record the destination |
The prices are item totals for these checks. They exclude delivery charges, payment fees, applicable tax and other order-level charges; no fixed, variable or exception operating costs are being compared. If your test includes any of those amounts, add them to the expected order total before checking the result.
For each test, use a unique identifier that staff can recognize in the permitted test workflow. Trace one source order to the POS and kitchen result. Compare the item, variant, modifiers, quantities and total with the expected result. Record the date, channel, location, tester and outcome alongside the change. A screenshot or test record can help the next person understand what was verified, provided your team is authorized to retain it.
Practice in a sandbox or other provider-approved simulation that cannot charge a real card, send a guest message or dispatch a courier. Confirm those protections before starting. Check an unavailable item using the supported test method; do not submit an order that could trigger real fulfillment. A simulation is not a live service pilot. If you later run a live pilot, agree on its controls and responsibilities with the provider first.
Test exception handling that the connection supports, such as the documented response to an unavailable item or failed match. If a case is intentionally unsupported, record the limitation and the staff workaround instead of treating it as a successful automated recovery.
Plan the seasonal return and a way back
Start before the return date, not when the first guest tries to order. The menu owner should compare the returning item with last season's record: recipe, size, required choices, price and kitchen instructions. Then the POS and ordering leads can determine whether to reuse an existing item or create and map a replacement.
- Set the owner and dates. Record who approves the item, who edits each system, the publication window and the person responsible for the retest.
- Capture the current state. Save the existing item references, channel names, prices, modifiers and availability. Note whether the item is inactive, unavailable or deleted in each system.
- Write the intended state. List the expected POS destination and channel references, current price, choices and the time the item should become available. Confirm which system controls each field.
- Prepare a rollback. Agree how to take the listing out of sale or restore the prior configuration if the check fails. Identify who can make that change and how staff will be told. Do not assume a rollback restores every old mapping automatically.
- Publish and retest. Check the unavailable state where applicable, then run an authorized simulation after the item is made available. Record the test identifier and result for every affected channel.
- Close or escalate. Mark the change complete only when the expected results are confirmed. If the match, price or modifier is wrong, keep the item out of sale where possible, contact the responsible provider and repeat the check after correction.
A small menu edit can affect several locations or channels. Schedule a regular review of the log and revisit it after bulk menu imports, POS changes or integration updates. Ask the provider how staff will be alerted to a failure between reviews and what manual process is available if a connected order cannot be matched.
Next, take one upcoming menu change and fill out the log before publishing it. Bring the item references, expected result and rollback plan to a POS provider. You can also review Fleksa's restaurant integrations and integration questions, then discuss your requirements for a restaurant POS.
Frequently asked questions
Will renaming an item always preserve its POS mapping?
No. It depends on the identifiers and behavior of the connected systems. Confirm the intended POS item and retest the published listing after the rename.
Should a seasonal item be restored or created again?
Choose based on the current recipe, reporting needs and how the connection handles restored items. Either way, confirm its identifier, mapping, price, modifiers and availability before taking orders.
What should staff do if a mapping fails?
Follow the agreed workaround, keep the affected item out of sale where possible and contact the responsible provider. Record the failure and retest the corrected connection using an authorized method.
