Begin with roles and work
For a PMS purchase, viewing a permissions settings screen is not enough. Ask for three fictional demo users: reception, housekeeping and manager. Review each person’s necessary work and boundaries together. The goal is not to hide the most buttons, but to let staff complete their tasks without unnecessary access beyond them. This is a procurement checklist, not a security certification or comprehensive technical audit. Use invented users and records only, with no real guest data, private terms or credentials.
What the sources establish
OWASP explains least privilege: limiting permissions to necessary work. Oracle’s public documentation offers a product example of assigning tasks to roles. We read both on 8 October 2026. They do not prove that every PMS offers identical controls or that a particular product is secure. Our matrix is an editorial proposal. Principles and vendor examples do not replace observed behaviour in a permitted demo. We make no claim about specific Stayax permissions or session capabilities, and a public description is not a completed test.
Define task, record and expected result
For each row, write role, task, record scope and expected outcome. A fictional receptionist might view today’s arrivals; housekeeping might update assigned preparation information. Define the manager’s review task separately. These examples do not prescribe one role structure for all properties. Decide who needs what in your own operation, including the property or records within scope. “Can open the screen” does not explain which information and action are available. Describe the expected result in a concrete sentence.
Demonstrate both allowed work and limits
Ask the vendor to show each account through normal demo screens. Confirm that necessary work can be completed as well as restricted work refused. A hidden button alone does not establish an access boundary; ask for the product’s supported demonstration of the relevant information or action. This does not require attacks, URL bypasses or unauthorised testing. If it cannot be observed, mark it unverified and request clarification. Do not treat another role’s demonstration as evidence for the account you are assessing.
Ask about temporary work and departures
Ask how temporary access is granted, approved and removed when someone covers another task. Define the assignment’s end and review owner as requirements, not assumed features. For a departing worker, ask how disabling the account and handling an already-open session can be demonstrated. Do not assume every vendor behaves identically. Distinguish observed behaviour from verbal descriptions or missing demonstrations. Use fictional accounts within the authorised demo, never a real employee account for this scenario.
Assess boundaries without blocking work
An unnecessarily narrow role may force every routine task to a manager. Observe whether normal work succeeds and how exceptions are escalated. If something is blocked, do not default to giving everyone administrator rights. Explain which step needs which information, then ask the vendor to demonstrate suitable scope. This compares operational need with observed behaviour; it does not guarantee a security level or productivity increase. Both excessive access and incomplete work should remain visible in the evaluation.
Base the buying note on observations
Record role, expected behaviour, observed result and open question for each test. Date and demo context make the evidence understandable later. Collect no real client information or access keys. Separate demonstrated, not demonstrated and awaiting explanation. These are transparent procurement notes, not formal audit findings. Do not turn unverified promises into completed tests when deciding on suitability. Apply the same matrix across candidates to compare role boundaries, completed work and remaining uncertainty fairly. If the product version or role definition changes after the demo, recheck that row. Keep the earlier note and date the new observation rather than treating old evidence as proof of new behaviour.