PEVENDE team ·
Multi-Company CRM: Roles and Data Separation
A company selection on screen is not authorization. The server must check who acts, which company they belong to and which operation they may perform on every request.
Define permissions before inviting
Create a simple matrix: owners manage the company, administrators manage the team and operators work with authorized records. Read-only roles must not mutate data. Role names are not enough; document concrete operations.
Check every request
OWASP recommends denying by default and validating permissions on every request. A company identifier sent by the browser does not prove membership. Search, exports and bulk actions need the same boundaries as individual editing.
Negative test
Hypothetical exercise: a person belongs to company A, not B. Replacing an A contact identifier with a B identifier in a request must fail without exposing data. Repeat for reads, edits and exports.
Offboarding needs a process too
When removing membership, check sessions, assignments, credentials and delegated integrations. Record who authorized the change. Do not retain access for convenience after a person stops working for the company. Review direct links and attachments too. Hiding an interface option is not enough when a user can replay a request or reuse a URL obtained before losing access. Include removed members in the negative test set and verify that the server denies their requests.
Practical checklist
- Document allowed actions per role.
- Test cross-company access and default denial.
- Review access when removing membership.
Primary sources
Checked October 2, 2026. Policies and products can change; review the source before implementation.