Four rights, considered separately
Role-based access control usually decomposes into view, create, edit and delete, applied per module. Treating them as one setting is the common shortcut and the common mistake.
A representative who should see every account may have no business deleting one. Someone in finance may need to view opportunities without editing them. Collapsing these into "access" forces you to grant too much or too little.
- View: which records appear at all.
- Create: who can add new records.
- Edit: who can change existing values.
- Delete: who can remove records — usually the shortest list.
Permissions are not tenant isolation
These are different mechanisms and conflating them is a real risk. Permissions govern what a user inside your organization can do. Tenant isolation ensures users in one organization cannot reach another organization's data at all.
The first is configuration you control. The second is an architectural property of the product, and worth asking a vendor about directly rather than inferring from a permissions screen.
Design from roles, not individuals
Permissions granted person by person become unmaintainable within a year, and nobody can answer who can see what.
Defining a small number of roles — administrator, manager, representative — and assigning people to them keeps the model reviewable. When someone needs an exception, that is a signal the role definitions need revisiting, not that the person needs bespoke rights.
The interface should follow the permission
A well-implemented model adapts what is shown, rather than presenting options that fail on use. Navigation, actions and buttons a role cannot use should not be offered.
This is partly usability and partly security hygiene: an interface that advertises capabilities it will refuse invites people to look for ways around the refusal.