Manage staff and roles safely

Separate user, role and permission

A user belongs to one person with their name and email. A role describes a job such as front desk or housekeeping. Permissions decide whether it can read, write or manage.

Hotel Nordlicht starts with management, front desk, housekeeping and finance profiles. One person may cover several tasks but still uses one personal account and the smallest adequate role.

Keep three concepts separate. A user is one identifiable person with personal credentials, language and active state. A role groups an approved job scope. A permission allows a concrete action such as reading bookings, changing finance settings or managing users. Never create a shared “reception” user, because actions, errors and later audits would no longer belong to one person. Map every employee to the correct hotel and avoid carrying permissions from another responsibility merely for convenience. System roles provide a maintained baseline; custom roles are justified only by a stable operational need. Document the role owner and approval date. Before configuration, write the intended task set and sensitive exclusions. The model is ready when management can explain who the person is, why the role exists and which exact actions it grants or denies without relying on an informal job title.

Plan tasks before permissions

List five to ten frequent tasks per workplace. Front desk works with bookings, guests and messages; housekeeping with the daily plan; finance with documents and payments; management with reports and configuration.

Mark whether each task needs read or write access. Viewing rooms does not imply availability management; viewing invoices does not imply payment correction. Do not enable modules “just in case”.

Design access from tasks and risk. List what front desk, housekeeping, finance, management and temporary cover must do in a normal shift, then identify the smallest data and action set required. Separate read, create, edit, approve, export and administration where the product supports it. Pay special attention to guest data, documents, payments, rates, hotel settings and user administration. A person who needs a report does not automatically need configuration rights; a housekeeper who updates room work does not need guest finance. Define emergency escalation instead of granting every user permanent administrator access. Note which actions require a second approval or later review. Compare the plan with real substitute arrangements and off-hours support. Task planning passes when each permission supports a named workflow, every sensitive exclusion has an operational alternative and no privilege exists solely because “it may be useful someday”.

Review system roles and add custom roles deliberately

Open Settings → Users & roles. STRYK provides Owner, Admin, Front desk and Housekeeping as starting profiles. Review description, active state, assigned users and module permissions.

Create a custom role only for a lasting distinct job, such as Finance without hotel configuration. Use a clear name and description, select required modules and verify saved state.

Review existing system roles before creating a custom one. Compare the role’s actual permissions with the task matrix and test the product areas it exposes. Choose the closest least-privileged baseline, then create a custom role only when a recurring job cannot be represented safely. Give custom roles clear names based on responsibility, document their owner and avoid person-specific names that become meaningless after staffing changes. Never copy an administrator role and remove a few visible items without testing hidden actions. Reopen the saved role and compare every permission. Maintain one canonical role for the same job instead of several almost-identical versions. If a new feature adds a permission, review its effect before broad assignment. Role design passes when the selected role supports all required tasks, blocks unrelated sensitive actions and remains understandable to a manager who did not create it.

Create personal users securely

In the user area choose Create user and enter full name, reachable individual email and prepared role. Share the initial password securely and check the email spelling before saving.

Hotel Nordlicht creates separate users for management, front-desk shifts, housekeeping and finance. Shifts may share a role but never an account.

Create one account for the named employee using a verified work email and the correct hotel. Set the intended language, active state and approved role; do not preconfigure fictional personal data to make screenshots look complete. Deliver onboarding through the approved account flow and require the employee to keep credentials private. Never send a shared administrator password in chat or store it in a front-desk note. Confirm the person can sign in and lands in the correct hotel account and language. Review the user record after save and verify no unintended role was inherited. For elevated access, record the approver and review date. A kiosk identity is a dedicated dedicated kiosk user for that hotel and should open the kiosk experience, not the normal admin; it is not a substitute for employee accounts. User creation passes when one real person controls one attributable account and no credential or role must be shared to complete a shift.

Test every role with positive and negative cases

Sign in with a role test user and verify positive cases: front desk reaches bookings and guests, housekeeping the daily plan, finance the correct document. Use marked test data.

Then verify deliberate restrictions. If a task is missing, change the central role using the smallest required permission, sign in again and retest both allowed and blocked cases.

Test each role with positive and negative cases while signed in as the test user. Positive cases prove required work: a receptionist opens and updates an approved booking, a housekeeper uses the shared day plan, a finance user reaches the intended document, and management performs its authorised configuration. Negative cases are equally important: the same users must fail visibly when attempting unrelated finance, user administration, sensitive guest export or hotel settings. Test direct navigation as well as hidden menu entries; security cannot rely on a missing link alone. Record role, action, expected result, actual result and evidence. Treat an STRYK error that still changes data as a critical failure, and treat a locally simulated success as invalid. Retest after role edits and after material product changes. A role is approved only when required actions succeed, forbidden actions fail in STRYK and the result survives logout and fresh login.

Handle cover, role changes and leavers cleanly

For cover, define dates and the concrete extra task. Distinguish reading documents from managing payments and record when access must return to normal.

For a permanent job change, update the personal user instead of creating a second account. Disable leavers by their last day but preserve history. STRYK deactivation does not replace the hotel’s full offboarding list.

Handle cover, role changes and leavers as dated access events. For temporary cover, grant the smallest additional role for the defined period, record approver and removal date, and avoid credential sharing. When an employee changes department, compare old and new task matrices and remove permissions no longer needed before adding new ones. On departure, deactivate the personal user promptly, preserve audit history and reassign open operational ownership such as housekeeping rooms or approvals. Do not delete the account to erase history and do not leave it active “just in case”. Review active sessions or related access where the system provides it and change any shared external credentials that the person legitimately knew. Test the replacement employee independently. The event is complete when the former user cannot access the hotel, necessary history remains attributable, open work has a new owner and the successor has only approved current permissions.

Review and approve access regularly

Run a short monthly team reconciliation and a full quarterly role review. Check active users, jobs, seasonal staff, cover, duplicates and unused roles.

Record date, reviewer, changes and next review. Hotel Nordlicht confirms six personal accounts, four operating roles and no shared login.

Run a periodic access review using the active user list, role definitions and recent operational responsibility. For every user confirm identity, employment or contract status, hotel, role, elevated permissions, last approval and continuing business need. Review custom roles for duplication and permissions added by new features. Sample audit evidence for sensitive finance, guest, pricing and administration actions. Ask managers to approve or remove access explicitly; silence is not approval. Track temporary grants past their end date and inactive accounts that still remain enabled. Record review date, reviewer, corrections and completion evidence without copying unnecessary personal data into a second spreadsheet. Repeat after major staffing or product changes and at a defined regular interval. The review is complete when every active account has a current owner and reason, every role has passed its tests, excess access is removed and management can trace the decision from the central system.

At the end of the review, perform a separate hotel account check: all active users should only access the hotel for which they have been approved, and direct requests made with another hotel account's ID should fail on the STRYK side. The test certificate should not contain guest data or password; the user, role, hotel, action, expected ban and time are sufficient. In this way, the authorization check is not only at the menu level, but also actually verifies the multi-hotel data separation.