97 permission keys, or: who can actually refund
A least-privilege tour of a CRM permission system: five roles, per-module keys across 24 modules, and why agent versus administrator matters on day one.
Field notes · Built by Arche Axon
Most small teams run WhatsApp sales with one shared login and total trust. It works until it doesn't: a wrong refund, an accidental broadcast, or a price changed by someone who thought they were helping. Least privilege is not corporate paranoia; it is how you make trust cheap to verify.
What a permission key actually is
A named capability like orders.refund or broadcasts.send is checked in the UI and again in the API on every request, not just in the menu. Vendale ships 97 of them across 24 modules, from inbox.view to team.manage. The count is public and verifiable in the catalogue file.
Five roles, one principle
Owner, Administrator, Support Manager, Agent, Viewer. The principle is not hierarchy. It is that each role can do its job without holding keys it never uses. An agent who can reply to conversations does not need billing keys. That is not distrust; it is blast-radius control.
The refund question
'Who can actually refund?' is the question that separates real permission systems from checkbox theatre. If the answer is 'anyone with the password', the audit log is decoration. If two specific roles can refund and every use records an actor and timestamp, you can hire without holding your breath.