Access rules: who can see and change what

Start with actions, not job titles

Manager does not explain what someone needs to access. List actions such as viewing, creating, editing, deleting, exporting and approving. For each action, identify the records and conditions. One employee may see all departmental orders but edit only assigned ones; another may review payments without access to customer conversations.

Define the visibility boundary

Access is about both opening a section and seeing the right records inside it. Discuss organisations, branches, projects and assigned owners. A user from one company must not receive another company’s data through search, files or direct links. Make those boundaries explicit requirements and verify them with concrete examples.

Review sensitive actions separately

Exporting an entire database, changing prices, issuing refunds and granting permissions differ from editing a note. Assign explicit authority and additional approval where the workflow requires it. Staff should understand the consequences before acting. Avoid granting broad access merely because it makes an initial demonstration easier to complete.

A hidden button is not an access check

The interface should show available actions, while the server must enforce permission decisions. Acceptance checks should include opening another user’s record and attempting a prohibited operation through its direct address. Cover file downloads, exports, search and support tools as well as the main pages people normally visit.

Record events that explain what happened

History should answer who changed a status, when an owner was assigned and why a result changed. Define relevant events and who can inspect the log. Avoid indiscriminately copying every piece of data. A clear record tied to an object is more useful for investigation than unrelated technical messages.

Cover the employee lifecycle

Inviting someone is only the beginning. Plan department transfers, temporary cover, access removal and reassignment of unfinished work. Discuss active sessions and file access after someone leaves. Preparation should produce a role-and-action matrix with examples of both allowed and prohibited workflows for the team to verify later.