How many roles should a service business have?

Few. Most businesses are covered by an owner, an administrator, a working member and a read-only observer. Nuance belongs in capabilities and module depth, not in a proliferation of roles nobody can remember.

What is a security-definer function and why does it matter here?

It is a database function that runs with its owner's privileges, so it can answer 'does this user hold this role' without itself being filtered by the policies that are asking the question. Without it, role checks inside policies can recurse.

Should a viewer be able to export data?

That is exactly the kind of question capabilities exist to answer explicitly. Export is a distinct action with its own allowed roles, rather than something implied by being able to see a screen.

Knowledge · Architecture

Roles vs Capabilities

A role is who someone is in the organization. A capability is a specific thing that may be done. Why mature permission systems keep the two separate.

What is the difference between a role and a capability?

A role is a named position in an organization, such as owner or viewer. A capability is a single permitted operation, such as deleting a customer or exporting a list. Roles are assigned to people; capabilities are what the system actually checks. A role is a shorthand for a set of capabilities, not a substitute for them.

Key takeaways

Roles are for humans to reason about; capabilities are for systems to enforce.
Access level per module and permission per action are two different questions.
Roles must live in their own table, never as a field on a profile.
Role checks belong in security-definer functions, not in ad-hoc queries.
Adding a role should be rare; adding a capability should be routine.

Why storing a role on the user profile is a mistake

If the role lives on the same record the user can edit, escalation is a field update. Keeping roles in a dedicated table, written only through controlled paths, means changing your own privilege level is a separate, auditable operation rather than a side effect of editing your name.

Two questions, two shapes of answer

Module access: what depth does this role get in this area — full, read, limited or none.
Action permission: is this specific operation allowed for this role at all.
Action conditions: does the operation additionally require confirmation or a second person's approval.

Least privilege in practice

Least privilege is not a philosophy, it is a default. New capabilities start denied and are granted deliberately to the smallest role that needs them. The opposite default — grant broadly, restrict later — never converges, because nobody removes access from a working system.

Where URBLD fits

URBLD defines four organization roles — owner, admin, user and viewer — in a locked permissions contract. Each module declares an access level per role, and sensitive actions are declared separately with their own allowed roles and optional confirmation or approval requirements. Role membership is stored in a dedicated roles table, never on a profile record, and policy checks call security-definer helper functions so a role lookup cannot recurse through the policies it is evaluating.

Workforce & Roles Security at URBLD

FAQ

Frequently Asked Questions

Straight answers about how URBLD runs the business end-to-end.

Related knowledge

Hiding a menu is not authorization

Access-control verification checklist