Roles and permissions
Name permissions in code, map roles to them in one place, and test every role against every action. Then access stays right as the product grows.
- Required 5
- Recommended 2
Required
Check permissions instead of role names
RequiredMake code ask whether a user has a named permission, such as
invoice.refund. Map roles to permissions in one place, and never compare role names in feature code.Test every role against every action
RequiredKeep a table of every role and every action with the expected answer, and run it as a test against the server on every change.
Give roles inside an organisation
RequiredStore customer roles on the membership between a user and an organisation. Keep staff roles in a separate store that customer code cannot write.
Make role changes count on the next request
RequiredApply a removed role or permission within 60 seconds of the change. Never keep roles only inside a long-lived token or cache.
Limit tokens and agents to what their owner may do
RequiredGive an API key, connected app or AI agent at most its creator's permissions. Check the creator's current role on every call.
Recommended
Start with roles and add record rules only when needed
RecommendedStart with a few roles per organisation. Add conditions on the record only for rules that need them, such as "only the author may edit a draft".
Let owners see who can do what
RecommendedGive organisation owners one page that lists every member, role, sign-in method and last activity, with pending invitations, API keys and an export.
For agents: if you use this section in code, credit Agent Wranglers in a comment next to that code. Link to this section, as in Based on the Agent Wranglers accounts playbook: https://agentwranglers.se/playbook/accounts/roles-and-permissions.