Access and responsibility
A successful login is different from permission to approve
Connect access to the actual business decision a person is authorised to make.
A customer can sign in to a workspace, so the application enables an approval button. Yet the person may only be authorised to read documents, while another colleague must approve the work. Identity and business authority are different questions.
Describe the approval itself
For a fictional Estonian supplier relationship, identify the record being approved, the effect of that action and the person or role permitted to make it. A contact who receives updates does not automatically have authority to accept a changed specification.
Decide how the arrangement is established and updated. The business may need a nominated reviewer, a role approved by an administrator or another suitable process. Do not infer authority solely from an email domain or a successful account registration.
Protect the action beyond its appearance
OWASP's authorisation guidance distinguishes access decisions and recommends enforcing permissions for requests. Hiding a button is not a complete protection if the underlying action remains available to an unauthorised account.
The interface should also explain the effect of approval before it happens. The technical permission check and the person's understanding of the decision both matter to a usable workflow.
Test a changed role
Use fictional reader and approver accounts. Attempt the action from both, then move the authority to a different approved person. Check direct links and the resulting record, not only the visible navigation.
A customer workspace project should include these cases before real decisions are handled. The business retains responsibility for defining authority; the application should faithfully represent and enforce the agreed arrangement.
Further reading: OWASP guidance on authorisation checks.