Answer
Roles should arise from actual responsibilities, not from as many technical switches as possible. First we clarify who may see, edit, approve, return or merely analyse a case. Location, customer, organisation or case type can also restrict access. Particularly critical actions may need a second confirmation or a four-eyes principle.
A role matrix alone is not enough. Permissions must be enforced on the server, tested with realistic accounts and maintained when the organisation changes. Interfaces need their own technical identities with as few permissions as possible. For business-critical decisions it should remain traceable who changed what and when. The specific design depends on risk and contract; a small internal application does not need the same complexity as a multi-tenant customer portal. Even so, invisible security assumptions should never be replaced by the user interface.
As of 3 September 2026
Further reading
Related topic: Business applications and web software