All posts
Guides
·
·
6 min read
A practical guide to organizations and roles
How to model teams, invitations and permissions so your B2B plan doesn't need a rewrite in a year.
Aarav Mehta
Head of Engineering
Most products start with one user per account. Then a customer asks to invite a colleague, and the data model that made sense on day one starts to bend. Here’s the structure we recommend, and the one Lintel’s organizations are built on.
Users belong to organizations, not the other way round
Keep users global. A person has one identity and can be a member of many organizations, each with its own role. The consultant who works with three of your customers signs in once and switches between them, instead of juggling three passwords.
Start with three roles
Admin, member and billing cover most early needs. Resist adding more until a customer asks. When they do, add permissions rather than roles: org:invoices:approve is easier to reason about than a fifth role with a vague name.
Check permissions, not roles
In your code, ask whether a user has a permission, never which role they hold. When you later let customers define their own roles, none of your checks have to change.
Keep reading.
More from the blog.
Product
·
Passkeys are ready. Here's how we turned them on by default
What we learned switching passkeys on for 9,000 products, and the fallbacks that kept sign-in working for everyone else.
Tobias Lindqvist
Security
·
Why your sign-in page should never say “wrong password”
Small copy decisions that stop account enumeration without making the page harder to use.
Kwame Asante
Product
·
Designing a sign-in form people finish
Four details from a year of testing: field order, error timing, social buttons and remembering the last method.
Hana Sato