How do you handle teams/invites?
I'm trying to figure out the best way to support teams or companies for a SaaS application. The issue is if User A signs up for an account using their email and invites User B via email. Then User B creates an account and is put on User A's team. What if User B now wants to create their own team account, do they have to use a separate email? Or alternatively User B already has an account when invited, are they able to join User As team, should I make them create a separate account to join?
The way I see it I can either:
A) Use something other than email as the primary key, such as username (or team+email combo), that way users can create as many accounts as they want for using with different teams/companies.
B) Users have one account , and a field is just added to each team record indicating which users have access. Then have some sort of toggle to switch between teams. I'm worried this one could be confusing about which teams you're being billed for vs. teams you're just accessing. Also not being able to sign directly into a team could be problematic.
C) Force users to just use separate emails.
How do you typically handle it?
This is how Ive solved this problem in the past. It is a little more complicated from a UI perspective since you now need a "team switcher" mechanism and for your front-end/app to be aware of the team currently selected.
The way I typically do this is:
i.e. "A team belongs to many users through a teamUser table". "A user belongs to many teams through a teamUser table".
Now that you have a "teamUser" join table/entity, you can use that to attach any roles or team-specific data for that user.
I don't think this is as big of a problem as you think it might be. For example, on Github, you can be a member n many teams, but billing is tied to the team and not to the individual user. Teams then have roles for being able to manage billing.
IMO this ends up being the worst experience EXCEPT if your app is targeting users that will be grouped in teams based on their company and is not a service they would otherwise use as an individual. In which case, they're likely signing up with a corporate email and not their personal email so having segregated accounts could actually make sense.