The system that creates a field is not always the system that should control later changes. In a restaurant POS integration, assign one source of truth to each shared field, name the systems that receive it, and specify which way updates travel. Then test those decisions before relying on the connection during service.
Start with the fields that can change an order: item identifiers, prices, modifiers, availability, order status, and payment status. A connection can send some of these fields in one direction while leaving others local. A field-level map makes that difference visible before an owner assumes everything syncs.
Draw the systems and connection directions
List every system that touches an order. A simple setup might include a restaurant POS, a direct ordering site, a payment provider, and a kitchen display or printer. Add any middleware or delivery channel that actually sits between them. Draw a separate arrow for each kind of data rather than one broad line labeled “integration.”
The following is a hypothetical example, not a description of a particular product connection. The restaurant wants its POS to control the menu, while an ordering site creates online orders:
Menu: POS → ordering site — Orders: ordering site → POS → kitchen display — Payment: ordering site → payment provider; payment result → ordering site → POS, if supported
For a clean HTML diagram without assuming line breaks, read each sentence above as a separate flow. The menu arrow represents item data going out. The order arrows represent a new order moving toward the kitchen. The payment path represents a transaction request and the return of its result; it does not mean the restaurant has received a payout or that all payment details reach the POS.
Mark each arrow as automatic, manual, or undecided. Beside it, record whether updates happen immediately, on a schedule, or only after someone triggers a sync. Ask what happens if the receiving system is unavailable: Is the update queued, rejected, retried, or left for staff to enter? Get an answer for each important flow, not just a general assurance that the systems connect.
Also mark where staff can edit the same information. If a manager can change a price in both systems, the diagram needs a rule for which change wins. Otherwise, the next sync could replace a correction without anyone noticing. A guide to direct POS connections and middleware can help you decide which connection path to examine.
Assign an owner to each field
Use one row per field or closely related group of fields. The owner is the system whose value should govern the shared record. The creator is where that particular record first appears. They may be different: an ordering site can create an order while the POS owns the menu identifier used to match its items.
The matrix below continues the hypothetical setup. It is a starting decision, not a promise that any particular integration supports these directions. Confirm every row with the providers and change it to match your operation.
| Field | Creates or owns | Direction | Decision to confirm |
|---|---|---|---|
| Item ID | POS creates and owns | POS → ordering site | How are items matched after a menu edit? |
| Item price | POS owns | POS → ordering site | Can channel-specific prices be kept separately? |
| Modifier and price | POS owns | POS → ordering site; selected value returns with order | Does the POS receive the selection and its charge? |
| Availability | POS owns | POS → ordering site | How quickly does an unavailable item stop appearing? |
| Order ID and items | Ordering site creates the source order | Ordering site → POS | Are source and POS IDs both retained for matching? |
| Order status | POS owns kitchen progress | POS → ordering site, if supported | Which statuses return, and who can change them? |
| Payment status | Payment provider determines transaction result | Provider → ordering site → POS, if supported | How are failed, pending, and refunded payments represented? |
The last column matters as much as the arrows. For example, an item name alone may not be a safe match if two locations use the same name for different portions. Record the identifier each system uses and whether a rename, deletion, or recreation changes that identifier. If the systems use different IDs, ask where the mapping lives and who maintains it.
Prices need a separate decision from item names. If the restaurant deliberately charges different prices by channel, decide where those prices are entered and whether a POS menu refresh can overwrite them. For availability, specify both the owner and the expected delay. An item marked unavailable after it has already been ordered needs an exception process; a menu update cannot resolve that existing order by itself.
For order and payment status, define the actual values each system uses. “Complete” might mean accepted by the kitchen in one system and handed to the guest in another. A paid status is not an order status, and a payment result is not the same as a settlement or payout. Ask how partial payments, voids, and refunds appear if they matter to your operation.
Test changes without affecting guests
Turn each important row into a test with an expected result. Use a vendor-provided sandbox or another isolated simulation. Confirm beforehand that the practice scenario cannot charge a real card, send a guest message, or dispatch a courier. If the providers cannot isolate an action, leave it out of the simulation and agree on another safe way to verify that behavior.
For the hypothetical menu above, create a test item or use a designated test record. Change its price in the POS and check whether the ordering site receives the intended value within the agreed window. Then try changing the same field on the ordering side, if editing is allowed. Does the change stay local, get rejected, or get replaced by the POS value? Record the result rather than assuming that two editable screens mean two-way sync.
Repeat the exercise with a modifier and availability. Check the item before and after each change, including what the guest-facing menu would show in the isolated environment. If the timing is longer than the restaurant can tolerate during a busy shift, decide whether staff need a temporary manual step or a different ownership rule.
Next, simulate one order with a unique test identifier. Match the source order to its POS and kitchen result. Check the item, modifier, quantity, and total in each place; also check that the payment status is represented as expected without processing a real payment. Test a supported exception, such as a rejected order or unavailable item, and record who would notice it and what they would do next.
Keep a short result log: test identifier, starting values, action, expected result, observed result, time, and person responsible for follow-up. An intentionally unsupported case belongs on the limitations list, not in the pass column. A failure needs a named owner and a retest after the configuration or process changes.
A simulation is different from a live service pilot. Once the isolated checks are complete and open issues are understood, agree with providers on a limited live pilot, staff coverage, monitoring, and a fallback. Real orders in a live pilot require the normal operational controls; do not treat them as practice transactions. Neither a pilot nor a migration guarantees uninterrupted service or that no order will be missed.
Document gaps and agree on a fallback
Some fields may not travel at all. Others may travel only on creation, not when changed later. Add each gap to the matrix with its business consequence, manual owner, and review point. “Not supported” is useful information when it leads to a workable decision.
For example, suppose the ordering site does not receive kitchen status updates. The restaurant can decide that staff will check the POS for progress and use an agreed guest communication process when needed. Name the shift role responsible and establish when the check happens. Do not write “status sync” in the handoff document if the status remains local.
For a menu field that requires duplicate entry, specify the order of work: update the owning system, update the other system, compare the guest-facing result, and record who completed the check. If a failed order must be entered manually, staff should first check whether it already exists in the POS. Use the source order ID to reduce the risk of creating a duplicate, and document how the team alerts the kitchen to the correction.
Finally, agree who can change the mapping after launch. A new modifier group, a renamed item, or a new location can expose a gap that was not present in the first test. Keep the diagram and matrix with the restaurant’s operating documentation, and review the affected rows whenever the menu or connection changes.
Bring the map to the buying conversation
Compare providers against the fields and exceptions your restaurant actually uses. Ask for a walkthrough of the exact POS, locations, ordering channels, and connection path you want. Fleksa’s restaurant integrations directory distinguishes live connections from connections available on request; confirm availability and setup for your combination before making it part of your operating plan.
Request a demo and bring your matrix, one sample order with modifiers, and the test cases you want to run. Include the fields that must stay under POS control and the gaps your team can handle manually. You can also review restaurant online ordering as you prepare the questions for your ordering flow.
Frequently asked questions
Can two systems both be the source of truth for a price?
They can each control a separate price, such as a POS price and a channel-specific price, if the connection supports that arrangement. Define them as different fields and confirm that a sync will not overwrite either one.
What should I check when an order reaches the POS?
Match it to the source order using its identifier, then compare items, quantities, modifiers, totals, and payment status. Check the kitchen result too, and follow the agreed process for any mismatch.
What if a field cannot sync?
Decide whether the restaurant can manage it locally or by manual entry. Record the responsible role, the timing, and the check that catches mistakes. If the gap affects a critical service task, resolve it before relying on the integration.
