The restaurant should decide who can authorize a third party to change an active POS connection. Put that authority in writing, give the vendor a current list of authorized approvers, and require approval for the specific change before it is applied. A vendor employee can carry out an approved change, but the restaurant should not assume that a request from any staff member gives the vendor permission to make it.
The right approver depends on the change. An owner might authorize a new destination location, while a designated operations manager can approve routine mapping changes within agreed limits. Ask the vendor how it verifies that authority, what evidence it keeps, and how an unauthorized request is handled. Agree on those rules before an active connection needs attention.
Match the change to the person who can approve it
A POS integration connects systems that may be managed by different businesses. A restaurant employee, an ordering provider, a POS provider, and an integration vendor might all have a role. Access to one system does not automatically confer authority to change another.
Start by listing each active connection by location, source, and destination. Then identify the settings that matter to service: which location receives orders, how items and modifiers map to the POS, and where an order goes when it cannot be processed. If a vendor can change a setting on the restaurant’s behalf, the approval rule should cover that action as well as changes made by restaurant staff.
Separate the requester, approver, and person implementing the change. A shift manager may notice that orders are going to the wrong place and request a correction. The owner or an authorized operations lead can approve the proposed destination. A vendor technician can then make the change within the approved scope. In a small restaurant, the owner may fill more than one role, but the record should still show which decision the owner made.
Set limits that fit the operation. You might allow a location manager to approve a mapping correction for that location but reserve changes between locations for the owner. Decide who acts when the owner is unavailable and how an approver is removed when someone leaves. Avoid a shared approval identity that makes it hard to tell who gave permission.
These choices also depend on how the systems connect. The guide to direct POS integration and middleware can help you identify the parties involved. For each route, ask who controls the settings and whether a separate approval is needed in the POS, ordering system, or integration service.
Ask how requests are verified and changes are recorded
Before choosing a provider, walk through its normal change process. Ask what a request must contain, how the requester’s identity is checked, and how the vendor determines whether that person can approve the particular change. An email address or familiar name may help identify a requester, but ask what happens if the request comes through a shared account or an unfamiliar channel.
Get specific about the approval itself. Does the approver see the current setting and the proposed setting? Can the vendor link the approval to a particular location and connection? How does it handle a request that bundles an authorized menu correction with an unauthorized destination change? A useful process separates the decisions instead of treating one approval as permission for everything.
Ask for a sample change record or a demonstration of the workflow. Look for a request identifier, the affected connection, the proposed change, the approver’s identity, the decision, and the time it was recorded. Also ask who can read the record later and how the restaurant can obtain a copy. If the vendor says it follows a process, ask to see what a completed record looks like rather than relying on a general assurance.
Record the answer in your own buying notes. Distinguish a demonstrated step from a promise to investigate it. For example, “vendor showed an approval tied to a location change” is different from “vendor will confirm whether location-level approval is available.” Neither statement should be expanded into a claim about every integration or account.
Finally, discuss urgent corrections. Who may request one after hours? Can the vendor contact an alternate approver? If the restaurant wants an emergency exception, define its scope and the follow-up record in advance. If no authorized person can be reached, ask whether the request remains pending and what operational workaround the restaurant has while it waits.
Simulate an unauthorized location change
Use a hypothetical scenario to compare vendors. A restaurant has two locations, Harbor and Hill. An active connection is set to send Harbor orders to the Harbor POS location. A shift supervisor asks the integration vendor to change the destination to Hill. The restaurant’s rule permits the supervisor to request the change, but only the owner or designated operations lead can approve a destination change between locations.
Ask the vendor to walk through the request in a demonstration or isolated test environment using sample data. The expected decision is to hold the change until an authorized person approves it. The vendor should identify the connection and proposed destination, contact or route the request to the correct approver, and record the decision. A request alone is not approval.
Now add an exception: the operations lead has been named as the owner’s authorized alternate for both locations, and the vendor verifies that the designation is current. If the lead approves the specific Harbor-to-Hill change, the decision can change from pending to approved under the restaurant’s rule. The record should show the lead’s authority and approval; it should not imply that the shift supervisor approved it.
Then ask what happens if the request is rejected or the alternate cannot be verified. The desired outcome is that the destination remains unchanged and the request is recorded as rejected or pending. Compare that answer with what the vendor actually demonstrates. If the vendor cannot show the approval step, treat it as an open buying question, not as proof that the step occurs behind the scenes.
For a separate routing check, use a unique sample order identifier and compare the source order with the simulated POS or kitchen result. Check the location, modifiers, and total. Discuss how the provider handles a supported exception, such as a mapping problem; an intentionally unsupported case is a documented limitation, not automatically a failed test. Do not use a real card payment, send a guest message, or dispatch a courier for practice.
A simulation checks the described workflow; it does not establish that an active connection is ready for service. If you later agree to a live service pilot, define its scope, approval, monitoring, and stop conditions separately with the providers. Do not treat a practice result as permission to redirect live orders.
Keep an approval record and compare the evidence
Use the same scenario and record fields for each provider. The table below shows what a completed record might contain before the hypothetical change is applied. Its pending decision matters: no authorized approver has yet approved this request.
| Record item | Sample entry | What the owner checks |
|---|---|---|
| Requester and connection | Harbor shift supervisor; Harbor ordering source to Harbor POS | Is the person identified, and is the affected connection specific? |
| Requested change | Change destination from Harbor POS to Hill POS | Are both the current and proposed settings shown? |
| Authority and decision | Owner or designated operations lead required; pending | Is the requester distinct from the required approver? |
| Test result | Simulated request held; no destination change made | Does the demonstration match the stated approval rule? |
| Rollback owner | Vendor technician designated to restore Harbor destination if an approved change must be reversed | Has the person accepted the role, and is the restoration procedure agreed? |
Add the request identifier, timestamps, approval or rejection, implementation details, and any supporting test reference when they exist. If the change is approved, confirm who will check the result and who will authorize a reversal. A named rollback owner is useful only if that person has the access and instructions needed to act. Ask how the restaurant contacts them during service and what happens if they are unavailable.
Compare evidence like for like. One provider may show a complete record in a simulation; another may describe the process but need to confirm whether it supports location-specific approvers. Note the difference and ask for the missing answer before selection. Also confirm which settings the vendor can actually change, which require another provider, and whether the workflow applies to your locations and POS setup.
Review the integration questions alongside the restaurant integrations directory. The directory distinguishes live connections from those available on request, so confirm the status and setup for your own systems. Then request a demo of Fleksa’s restaurant POS system with the sample scenario, and ask the team to document the approval outcome and any open questions for your connection.
Frequently asked questions
Can a third-party technician approve a POS connection change?
The restaurant should define who may approve it. A technician may implement an authorized change, but ask whether the technician can also approve it and whether that arrangement matches your written rule.
What if an unauthorized employee requests an urgent change?
The request can be escalated to an authorized approver or alternate. Agree in advance on after-hours contacts, the permitted emergency process, and what happens if nobody with authority can be reached.
What should the restaurant keep after a change?
Keep the requester, affected connection, old and new settings, approval decision, test result, implementation details, and rollback owner. Retain a way to find the vendor’s corresponding record as well.
