Give each temporary worker an individual account with only the permissions needed for the assignment. Set an end time if the software supports it. If it does not, assign a manager to remove access at a specific time and verify that it was removed. In either case, decide how an extension will be approved before the first shift.
The decision starts with the work, not the job title. A temporary cashier may need to enter orders and take payments without seeing sales reports or changing the menu. A worker helping with reservations may need different access altogether. Confirm what the system can restrict, then plan around any gaps before handing over credentials.
Map the assignment to the smallest useful access
Ask the shift manager for the worker's assigned duties and scheduled hours. Ask the person responsible for the software which screens and actions those duties require. Compare those answers with a current role list or a vendor demonstration. A schedule tells you when the person is expected to work; it does not prove which permissions the account will have.
Separate actions that look similar. Viewing an order, changing it, issuing a refund and changing the price are different tasks. The same applies to seeing a reservation and changing its details. If the product bundles several actions into one role, note the extra access that comes with it and decide whether a manager should handle that task instead.
For a restaurant POS system, build a short task list for each assignment:
- What must the worker view, create or change during a normal shift?
- Which exceptions, such as a refund or price correction, should go to a manager?
- Does the worker need access at one location, or across several locations?
- Does the worker need reports, menu settings or account administration at all?
- Can the system grant the needed actions without also granting unrelated ones?
Fleksa's partner portal provides dashboard, order, menu and reservation views, although available views and configuration vary. Ask which views and actions can be limited for the role you have in mind. A screen's presence does not establish that its individual actions can be restricted.
Compare automatic expiry with a managed removal
Use an individual named account in either option. A shared login makes it harder to distinguish one worker's actions from another's and makes removal awkward if others still use the same credentials. Ask whether the product supports individual accounts, restricted roles, scheduled expiry and an access history that managers can review.
The following worksheet is hypothetical. A manager has a schedule for a temporary counter worker covering two evening shifts. The manager also has a task list: enter orders and take payments, but send refunds and menu changes to the manager. Assume the assignment ends at 10 p.m. on the second evening, and the worker needs no access afterward. These are planning assumptions, not claims about any product.
| Decision input | Option A: scheduled expiry | Option B: managed removal |
|---|---|---|
| Account and scope | Named account with order and payment actions only, if available | Same named account and intended scope, if available |
| End of access | Set expiry for 10 p.m. after the second shift | Manager removes access at 10 p.m. after the second shift |
| Verification | Manager checks that access is denied after expiry | Manager checks that access is denied after removal |
| Late shift | Manager approves and sets a revised end time before expiry | Manager records approval and the revised removal time |
The table compares two ways to end the same limited assignment. Option A is preferable under these assumptions if the vendor demonstrates that expiry applies to the relevant account and the manager can approve an extension without broadening permissions. It reduces reliance on someone remembering the removal at the exact end of a busy shift, but it still needs verification.
Option B can work when scheduled expiry is unavailable or does not cover the relevant access. It depends on a named manager being available to remove and check the account. If that cannot be reliably covered, change the staffing plan or have an authorized manager perform the system tasks. Do not treat an unassigned reminder as an access control.
A different result changes the choice: if the vendor shows that automatic expiry ends only one part of the worker's access, use a documented removal process for the remaining access, or do not use that option for the assignment. Also check whether a restricted role includes extra actions. An expiry date does not make excessive permissions appropriate while the account is active.
Demonstrate expiry and a shift extension
Before using a new access process in service, ask the vendor to demonstrate it with a dedicated test account and test data. This is a simulation, not a live shift. Configure the demonstration so it cannot charge a real card, send a guest message or dispatch a courier. Use a safe test environment or vendor-provided simulated actions; if those safeguards are unavailable, limit the demonstration to non-transactional screens.
Have the shift manager act as the detector: that person watches for an account that remains usable after its agreed end time or loses access before an approved extension. A separate software administrator can make the configuration changes if that is how your restaurant divides responsibility.
- Create a named test account with the intended temporary-worker role. Record the allowed actions, prohibited actions, location and end time.
- Demonstrate an allowed action using test data. Then attempt a prohibited action, such as opening a menu-editing control, without making a live change.
- Let the test account reach its expiry, or have the assigned manager remove it at the scheduled time. Attempt to use the account again.
- Repeat with a new scheduled end time. Before that time, have the shift manager approve a fictional late shift and have the authorized administrator extend access only through the revised end.
- Check that the same limited role still applies during the extension and that access is denied after the revised end.
To avoid a misleading result, make a fresh sign-in attempt after expiry and check any session that was already open, if the product permits it. A denied new sign-in alone does not show what happens to an existing session. Record both outcomes separately. If an active session remains usable, ask the vendor how to end it and include that step in the removal procedure.
Pass: the test account can perform the agreed safe task, cannot perform the selected prohibited action, and loses the relevant access at the agreed end. For the extension, an authorized person records approval, changes the end time without adding permissions, and verifies denial after the revised end. Fail: any of those checks does not work, cannot be demonstrated, or requires an undocumented workaround.
A failure is not a reason to improvise during dinner service. The software administrator owns the exception: document what failed, ask the vendor for a workable control, and have the restaurant manager approve an alternative before assigning the worker. A later live service pilot, if appropriate, is a separate operational decision using real staff and normal safeguards; do not use real payments or guest communications to prove the practice scenario.
Record the approval and review the assignment
Keep an access record where the people responsible for the schedule and software can find it. It should identify the worker and account, approver, location, role, allowed tasks, start and end times, and the person responsible for removal. Record any extension with its reason, approval time and revised end. Do not put passwords, PINs or other credentials in the record.
At the end of the assignment, the assigned manager should check the account's status and record the result. If access remains, remove it using the agreed procedure and verify again. Escalate an unresolved problem to the software administrator rather than marking the review complete. Review permissions as well as account status: a worker who returns for another short assignment may need a different role.
Ask the vendor how an administrator can inspect current access and whether the system records changes to roles and expiry times. If those records are limited, keep your own approval and verification log. Do not assume a sales report is an access audit; a sales report answers a different operational question.
For your next temporary assignment, write down the worker's actual tasks and end time, then compare those requirements with Fleksa's restaurant management software. Ask Fleksa to demonstrate the relevant permission and removal workflow before you choose it.
Frequently asked questions
Should temporary staff share a manager login?
No. Use individual accounts where supported. Sharing makes it harder to identify actions and remove one person's access without affecting others.
What if a temporary shift runs late?
Have a designated manager approve the extension before access ends. Record the new end time, keep the original limited permissions and verify removal afterward.
Is an expiry time enough on its own?
Not necessarily. Confirm which access it ends, what happens to an open session and how the manager can verify the result. If the product cannot demonstrate the needed control, use an approved removal process or keep the task with an authorized manager.
