A delivery-to-POS integration needs some way to access the accounts involved, but the exact permissions depend on the channel, POS and connection. Before granting access, ask the vendor to name each account, the actions requested and the person who can revoke them. Do not hand over an owner's everyday password as a shortcut.
Keep a written access inventory for each location and connection. Then agree on what happens when access is removed: who stops the connection, how the restaurant handles incoming orders and what must be checked before reconnecting. This is separate from setting staff roles inside the POS; a third-party connection may have its own access and credentials.
Inventory accounts and administrators first
Start with the channels your restaurant actually uses, not a vendor's full integration list. For each location, list the delivery or ordering account, the receiving POS account and any other service that sits between them. A connection may be authorized directly between two systems or through an intermediary. Ask the provider to draw the path if it is not clear.
Next, identify the named person who administers each account. That person may be the owner, a general manager or someone at a restaurant group. Record a business contact and a backup, rather than relying on a former employee's personal email. Make sure the people listed can reach the relevant account settings or know whom to call.
The following is a hypothetical inventory for one location. It illustrates what to record; the permissions and revocation methods are questions to settle with the actual providers, not claims about a particular product.
| Connection or account | Access to confirm | Administrator and backup | Revocation and open item |
|---|---|---|---|
| Delivery channel A | Read incoming orders; confirm whether menu changes are also requested | Owner; store manager | Find the disconnect control and confirm who can use it |
| POS at location A | Create orders; confirm whether refunds or other actions are requested | Store manager; owner | Confirm whether access can be removed without affecting other connections |
| Integration service | Administer the connection and view any order data needed for support | Owner; operations lead | Confirm how to disable the connection and whom to contact after hours |
The table separates access to the channel, POS and intermediary because disabling one does not necessarily remove access everywhere else. For a second location, make a separate entry even if it uses the same provider. Shared accounts can make it harder to tell which location is affected when access changes.
Also note where credentials or authorization details are held, without putting passwords or secret keys in the inventory itself. If a provider asks for a code or credential, ask how it should be transferred and stored. Prefer an individual administrator and a dedicated connection where the systems support them, so the restaurant can identify and remove access without disrupting unrelated work.
Match requested permissions to actual work
Ask the vendor for a list of permissions before anyone approves an access screen. For each item, request a plain-English explanation of the action it allows and why the connection needs it. Reading an order, creating an order in a POS, changing a menu and issuing a refund are different actions. A permission that helps support one workflow is not automatically necessary for all of them.
Use your exact channel, POS and location in the conversation. Ask the vendor to show the authorization steps for that combination and point out which actions are automatic, which require staff work and which are not supported. If the vendor cannot demonstrate a step in a safe environment, write down what remains to be confirmed before launch.
- What data can the connection read, change or send, and at which location?
- Can we grant only the permissions needed for our chosen workflow? What stops working if we decline one?
- Does the vendor need an ongoing login, an authorization approval, a key or another form of access? Who creates and controls it?
- Who at the vendor can access order details for support, and how is that access removed when no longer needed?
- Can one channel or location be disconnected without disabling the others?
For a practical decision, return to the hypothetical location above. Suppose its owner wants delivery orders sent to the POS but plans to maintain menus in the channel account. If menu editing is optional, the owner can decline that permission and keep the manual menu task assigned to a manager. If the vendor says it is required, the next decision is whether the benefit justifies that access or whether to choose another workflow. Get the answer in writing before approval.
For context on connection options, review the restaurant integrations directory and the guide to direct POS integrations and middleware. A listing is a starting point, not proof that every permission or workflow is available for your setup. Confirm the connection against your restaurant POS system and each channel you use.
Simulate disconnection and reconnection safely
Agree on the revocation steps with both the integration provider and the administrators of the connected accounts. Ask whether disconnecting in one place also invalidates the underlying authorization or credential elsewhere. If not, list every separate step. Record who can carry it out, the support contact and how the team will know the connection has stopped.
Use a vendor-supported test environment or a clearly simulated walkthrough. A practice scenario must not charge a real card, send a real guest message or dispatch a courier. If those safeguards cannot be confirmed, walk through the steps without submitting an order. Do not use private customer data.
In a supported simulation, give a test order a unique identifier. Match the source order to the expected POS or kitchen result, including its modifiers and total. Agree on one supported exception to check, such as how staff are notified if an order cannot be sent. An intentionally unsupported case belongs in the limitations record; it is not a failed requirement unless the restaurant needs it.
- Write the expected result before the simulation: what should appear, where staff should look and what should happen if the connection is disabled.
- With vendor support, simulate removal of access using the agreed control. Record the observed result and the time, or mark the step as a walkthrough if it could not actually be simulated.
- Ask what happens to orders received while access is off and whether any need manual handling. Do not assume they will automatically reappear after reconnection.
- Simulate or walk through a fresh authorization. Check whether the same permissions are requested and how staff would verify that the connection is working again.
Keep expected and observed results separate. For example, if the expected result is that a disabled connection cannot send an order to the POS, but the team only discusses the control without using it, record that as untested. Decide who will resolve the gap and when. A live service pilot is a separate decision with real operational consequences; plan its staffing and fallback with the vendor rather than treating a simulation as proof of live performance.
Set an access review and incident plan
Give the inventory an owner and a review date. Review it when a provider changes, an administrator leaves, a location opens or closes, or the restaurant changes its order workflow. At each review, confirm that named administrators still need access, remove outdated entries and ask providers to explain any permission changes.
For each unresolved item, write an owner and a next decision. For example: the operations lead asks the POS provider whether location A can be disconnected independently; the owner decides whether to proceed after receiving the answer. This turns an open question into a task rather than leaving it buried in a sales call.
Keep an incident contact list outside the system being connected, where authorized managers can reach it. Include the restaurant's decision-maker, account administrators, vendor support route and backup. Document who can pause the connection, who contacts each provider and how staff switch to the agreed manual order process. Ask the providers how to preserve useful records without sharing passwords or unnecessary guest information.
If access is revoked unexpectedly, the immediate priorities are to identify the affected location and channel, follow the agreed fallback and contact the relevant providers. Reconnection should be an explicit decision by an authorized administrator, followed by the checks the restaurant and vendors agreed to perform.
Bring your channel list, access inventory and test cases to a Fleksa demo. Start with Fleksa's restaurant integrations and confirm availability for your location and POS before granting access.
Frequently asked questions
Does an integration vendor need my POS owner password?
Ask for the supported authorization method and whether a dedicated connection or individual administrator can be used. Do not share your everyday owner password as a shortcut. Confirm who controls and can revoke the access granted.
Is disconnecting the integration enough to revoke all access?
Not necessarily. Ask each provider whether disconnecting also invalidates related credentials or authorizations. Record any separate steps for the channel, POS and intermediary, along with the person responsible for each.
What should we do with orders during a disconnection?
Agree on a manual fallback with your providers and train the relevant staff. Ask where orders will appear and whether any require manual handling; do not assume they will automatically reach the POS after reconnection.
