In Subscription Billing and Plans we wired up the part of the product that collects money. This article covers the part that gets people into the product in the first place: how a company brings its teammates on board, and how you model the groups they work in once they're there.
This is part of the Full Stack SaaS Masterclass, a build-it-for-real series that started with choosing the tech stack and has been layering on the pieces a real SaaS needs, module by module. We already covered the organization and membership schema back in the authentication module. This article builds on that foundation and adds two things most products need soon after: teams as an optional grouping inside an organization, and an invitation flow that lets an existing member bring in someone new without you, the founder, manually creating accounts.
Invitations sound like a small feature. They're the first thing a paying customer's admin does after signing up, and a clunky or insecure version of this flow is the kind of thing that shows up in a support ticket or, worse, a security report.
Teams as a layer, not a replacement
Once an organization has more than a handful of people, someone will ask for a way to group them: a Sales team, an Engineering team, a team scoped to one client account. The instinct is to reach for a second permissions system, one where each team has its own roles and its own access rules layered on top of the organization's.
