When an employee becomes a manager or returns to a staff role, give them the access their new duties require and remove permissions they no longer need. Set an effective time, assign an owner to make the changes, and review the employee’s own login afterward. A title change alone does not establish what someone can see or approve.
The owner or another designated decision-maker should approve the access change. The person making it might be a general manager, an administrator or a vendor support contact, depending on the software. Keep those responsibilities clear: the person who requests a change should not have to guess who can authorize it.
Start with the work, then choose the access
List the tasks the employee will perform in the new role. A shift manager may need to review orders, handle exceptions and adjust a reservation. A staff member returning to service may need to view the information required for a shift without changing settings or seeing broader reports. The exact permissions depend on how your restaurant divides the work.
Separate viewing from changing and approving. For example, viewing an order is different from changing its status, and reviewing a discount is different from approving one. Also check access to customer details, sales summaries, menu settings and account administration. Do not grant a broad manager role just because one additional task is needed without first asking what else that role includes.
Look across the tools the employee actually uses. Your restaurant POS system and reservation system may have separate accounts or controls. A change in one place should not be assumed to update the others. If payroll, inventory or accounting work happens in separate tools, review those accounts separately too.
Plan the timing around the actual handoff. If a promotion starts at the beginning of a shift, access should be ready for that shift, not several days later. If management duties end at the close of a shift, decide who covers approvals afterward. A manager who cannot approve a legitimate exception can slow service; a former manager who still has approval access can make changes outside their assigned duties.
Choose how to make the change
Use a standard role when the software offers one that matches the new duties. Ask for the full permission list before applying it, including any less obvious settings or reporting access. A standard role is easier to repeat across employees, but it can be too broad or leave out a necessary task.
Adjust individual permissions when the software allows it and the job needs a narrower mix of access. This can fit an employee who manages reservations but does not approve financial exceptions. It also creates more items to document and check. If individual controls are unavailable, decide whether a standard role is acceptable or whether another authorized person should handle the extra task.
Use a temporary assignment when someone covers a manager’s absence, if the system supports it. Record both the start and end of the assignment and who will confirm the rollback. If access cannot expire automatically, put a manual removal on the administrator’s calendar and assign a backup. Temporary access without an end check can become permanent by accident.
Changing someone back to a staff role deserves the same care as a promotion. Remove obsolete approvals and settings access, then confirm that ordinary shift tasks still work. Avoid deleting and recreating an account as a shortcut unless the vendor explains the consequences for its records and access history. Do not share another employee’s login to bridge a gap.
Use a role-change worksheet
The following is a hypothetical example. Jordan moves from server to shift manager at 3:00 p.m. on June 10, then returns to the server role at 3:00 p.m. on June 24. The owner approves the change; the restaurant administrator applies and checks it. The permissions below are sample requirements, not a description of any particular product.
| Task or access | Server before June 10 | Shift manager, June 10–24 | Server from June 24 |
|---|---|---|---|
| View assigned orders | Allowed | Allowed | Allowed |
| Approve a discount exception | Not allowed | Allowed | Not allowed |
| Change menu settings | Not allowed | Not allowed | Not allowed |
| View shift sales summary | Not allowed | Allowed | Not allowed |
The table separates what stays the same from what changes in each direction. It also records a permission that should remain off: promotion does not automatically justify menu-setting access. Add a row for each relevant tool and task, including any access that cannot be controlled separately. Record the effective time and time zone alongside the worksheet if shifts or locations cross time zones.
Before June 10, the owner checks the requested manager duties against the worksheet and approves them. The administrator then applies the available settings. If the software only offers a manager role that also allows menu changes, the administrator should stop and tell the owner. The owner can decide whether another authorized manager should handle the exception or whether the broader access is acceptable. That decision belongs on the record, not in an assumption.
After the promotion takes effect, Jordan signs in with the usual individual account. The administrator checks that the assigned-order view works and that the account has the intended manager access. For a safe practice check of the discount approval, use a vendor-provided sandbox or simulation with no real payment, guest message or courier dispatch. The expected result is that the sample approval is available; the administrator records the outcome and resolves any mismatch before relying on the setup.
At the June 24 handoff, the administrator removes the manager permissions and checks Jordan’s login again. The expected result is continued access to assigned orders, with discount approval and the shift sales summary no longer available. In the simulation, an attempted sample approval should be denied. If it is not, the administrator should treat the change as incomplete, restrict the affected access as appropriate and contact support. The owner assigns another authorized person to handle real approvals until the issue is resolved.
Keep the approved worksheet with the effective dates, the person who applied the change, the check result and any unresolved issue. Record which account and system were checked, but do not store passwords in the worksheet. Revisit open items after support responds.
Run a vendor acceptance test before buying
Ask each vendor to demonstrate the role change using the tasks your restaurant listed. Use a sandbox or another isolated simulation. Agree in advance that the exercise will not create a real payment, send a guest message or dispatch a courier. A simulated check shows how the controls behave in the demonstration environment; it is not proof that your live configuration has been reviewed.
- Map the role. Ask the vendor to show all permissions included in the staff and manager roles. Pass if you can identify the access that changes and understand any permissions bundled together. Fail if the vendor cannot explain a consequential permission.
- Approve and apply the promotion. Have the demonstrator record the owner’s approval, apply the change and sign in as the sample employee. Pass if the intended task is available at the agreed point and unrelated access remains restricted. Fail if the task requires an unapproved privilege or the result cannot be checked.
- Reverse the change. Return the sample employee to the staff role. Pass if the manager approval is no longer available and the employee can still perform the agreed staff task. Fail if the old approval remains or the staff task is lost.
- Handle an exception. Ask what happens if the change is applied late, the administrator is unavailable or a role contains more access than requested. Pass if the vendor can show a workable manual recovery path, identify who can perform it and explain how to confirm the result. Fail if service depends on sharing a login or an undefined support response.
Also ask whether the system records who changed access and when, whether a future start or end can be scheduled, and how a manager can review current permissions later. If those controls are not available, decide whether your own approval record and calendar check are enough for the restaurant. Ask support how to reach them during your service hours and what information they need to resolve an incorrect permission.
If the demonstration meets your requirements, make the first live change at an agreed handoff and review the employee’s actual login afterward. That live review is separate from the simulation. Coordinate with the shift lead so someone authorized can cover work while any problem is corrected.
Bring a completed worksheet to your next vendor conversation. Compare your access and approval requirements with Fleksa restaurant management software, and confirm which controls are available for your setup before choosing a role-change process.
Frequently asked questions
Should a promotion automatically give an employee every manager permission?
No. Match access to the duties the employee will perform. Review what a manager role includes, and decide explicitly whether any bundled permissions are acceptable.
What should happen when a temporary manager returns to a staff role?
Remove the temporary management access at the agreed time, retain the access needed for staff duties and check the employee’s individual login. Assign someone else to handle approvals after the handoff.
How can an owner check access without affecting guests?
Use a sandbox or isolated simulation for practice, with no real payment, guest message or courier dispatch. Separately review the employee’s live login after the approved change and coordinate any correction with the shift lead.
