Choose one authoritative system for each menu field, not necessarily one system for the entire menu. Your POS might own prices, while an ordering platform owns customer-facing descriptions. The important part is that every connected system follows an agreed rule for each field, and staff know where to make changes.
Start by listing the fields staff can edit. Then ask your integration provider which way each field travels, what happens when two edits compete, and how a failed update becomes visible. Put the answers in a field ownership matrix before you rely on the connection during service.
Matching menu items across systems is a separate job. Mapping tells the integration that a POS burger and an online burger are the same item. Ownership decides which burger name, price, modifiers and availability should appear when those records disagree. Both decisions matter.
List the menu fields that can change
Gather the people who maintain the POS, online ordering menu and any other connected channel. Open an ordinary item in each system and list the fields that can be changed. Include fields that seem minor: a small wording change can confuse a guest, while a modifier change can alter what the kitchen receives.
At a minimum, cover these groups:
- Item identity and presentation: item name, category, description and photo.
- Price: base price, location-specific price and any channel-specific price.
- Modifiers: option names, prices, required selections, selection limits and the order in which options appear.
- Availability: whether an item or option is active, sold out, scheduled for certain hours or available at a particular location.
Break a field into smaller decisions when the business rules differ. For example, the base price and an extra-cheese price should not automatically be treated as the same field. A modifier group may have one owner for its options and another for its display order. Ask whether the integration can actually support that division before adopting it.
Also note the scope of each decision. A sandwich can have different prices at two locations, and a breakfast item may be available only until a set time. The owner must be able to maintain the relevant location, channel and schedule. If a receiving system cannot represent one of those distinctions, choose a workable process rather than assuming the detail will carry over.
Build a field ownership matrix
Use the matrix to record the desired rule, then confirm whether the systems can implement it. The following is a hypothetical setup for one restaurant using a POS and an online ordering platform. It is a decision example, not a claim about any particular integration.
| Field | Authoritative system | Desired direction | Check before approval |
|---|---|---|---|
| Item name | POS | POS to ordering platform | Does an online edit remain local or get overwritten? |
| Base price | POS | POS to ordering platform | Does the correct location price arrive? |
| Modifier options and prices | POS | POS to ordering platform | Do required choices and price changes arrive together? |
| Customer description | Ordering platform | Platform only | Can a POS update leave the description untouched? |
| Sold-out status | POS | POS to ordering platform | How quickly does the status appear, and how is a failure shown? |
Read each row as an instruction. For the base price, staff would change the POS price and then check the ordering platform for the right location. They would not make a separate online price edit just because that screen allows it. The description row works differently: staff would maintain the customer-facing wording on the ordering platform, provided a POS update does not replace it.
Add rows for every field and destination that matters. If two online channels need different descriptions, name each channel and its owner. If a provider says a field cannot sync in the direction you want, record the actual behavior and decide whether a manual process is acceptable. A useful matrix describes what the team can operate, not just what it hoped to buy.
Map the direction and timing of each sync
For every row, ask which system sends the value and which receives it. A connection between a POS and another platform does not, by itself, tell you whether a field moves one way, both ways or not at all. It also does not establish whether an edit is sent immediately, on a schedule or only after someone starts an update.
Ask the provider to walk through a price change from the moment a manager saves it. Where is it sent? What triggers the update? How can staff tell that the receiving menu has accepted it? Ask the same questions for an item name, a modifier and sold-out status; they may have different rules.
Pay special attention to menu publishing. A value might be updated in an administrative screen but still need a separate publish step before guests see it. Confirm who performs that step and whether it applies to all locations or only the one being edited.
Use the same discipline when considering restaurant integrations. Fleksa's directory distinguishes live connections from connections available on request. Ask about the particular POS, location and channel you use, as well as the menu fields and directions you need. The presence of a connection is not a substitute for a field-level agreement.
Set conflict and failure rules before launch
A conflict occurs when two systems hold different values for a field. That can happen because two people edit at nearly the same time, an old update arrives late, or a connection is interrupted. The matrix should state the expected winner and the action staff should take if the result is unclear.
For a POS-owned price, the desired rule might be that the POS value wins over an online edit. Ask whether the integration enforces that rule, how quickly the correction occurs and what staff see in the meantime. Do not assume the most recent edit wins or that the designated owner always wins. Get the actual behavior explained for each important field.
Run a simulation with the provider using a designated test item and a safe test environment or other agreed non-live method. For a simultaneous-edit scenario, enter two different test values as directed and check which value appears in each system after synchronization. Then check a failure scenario: interrupt or reject an update only if the provider can safely simulate it, and see how staff would notice and recover.
Keep simulations separate from a live service pilot. Practice must not create a real card payment, guest message or courier dispatch. If the safe setup cannot reproduce a condition, document the limitation and ask the provider to explain the expected behavior; do not call it a passed test.
A live pilot, if you choose to run one, is an operational rollout with approved real menu changes and staff watching the results. Set its scope, timing and rollback steps in advance. Do not use live guest orders or dispatches as practice transactions. If a mismatch appears, staff need a clear instruction: pause the affected change or item where possible, notify the owner, and verify the corrected value in each relevant channel before resuming normal updates.
Assign people to changes and daily checks
A system can own a field, but a person still needs to own the work. Give each field group an editor, an approver and a person who checks the result. In a small restaurant, one manager may hold more than one role. The distinction still helps when that manager is off duty.
For a planned menu update, use a short checklist:
- Confirm the item, location, channel and effective time.
- Check the matrix for the authoritative system and make the edit there.
- Have the designated approver review the change when required.
- Confirm the update in the receiving system and, where appropriate, on the guest-facing menu.
- Record the result and flag any mismatch to the person responsible for recovery.
For a sold-out item during a rush, the process needs to be faster. Decide who is allowed to change availability, where they make that change and how they confirm it reached the ordering channel. Also decide what to do if the update is delayed: for example, a manager may need to pause the affected item through an agreed supported control. Confirm that control with the provider before depending on it.
Review the matrix whenever you add a location, channel or integration, or change your menu workflow. Remove access or update responsibilities when staff roles change. Keep a copy where managers can find it, and make sure the support contact for each system is recorded alongside it.
Before committing to a restaurant POS or a connected platform, bring the matrix to the provider and ask for a field-by-field walkthrough. Use Fleksa's integration questions as a starting point, then discuss your specific requirements with the provider: owners, sync directions, conflict behavior, alerts and a safe simulation plan.
Frequently asked questions
Should the POS own every menu field?
Not necessarily. Choose an owner for each field based on where staff can maintain it accurately and what the integration supports. Some customer-facing content may be easier to maintain elsewhere, provided updates do not overwrite it.
Is menu mapping the same as field ownership?
No. Mapping identifies which records represent the same item or modifier. Field ownership determines which system's value should control a particular attribute when records differ.
What should we do if a menu update fails?
Follow the agreed recovery process: identify the affected item and channels, notify the responsible manager, correct the value in the authoritative system and verify the receiving menus. Use any pause controls only as supported by your setup.
