Permission keys, or: who can actually refund
A least-privilege tour of CRM permissions: action-level access, role defaults, 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 such as orders.refund or broadcasts.send can be checked in the interface and enforced by the API. The permission catalogue changes as the product grows; use the permissions visible in the exact release and workspace rather than relying on a fixed count.
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.