Single-owner accounts with team members

AuthRocket is flexible enough to support a variety of account styles, from simple to complex. For an overview, see Storing accounts within AuthRocket.

This document discusses a middle (and rather common) use case, more flexible than the simplest case, but less so than the complex case.

In general, this starts with a base of 1 User = 1 Account, but additional users/team members also have secondary access to the account.

It is implied that the original user is the owner of the account and that this doesn’t change. This may seem like an arbitrary limitation, but in practice simplifies a number of things. For example, it tends to work substantially better with a number of metrics and analytics products (which are often unable to handle a change of a primary owner of an account).

For this use case, the initial user (the account owner) will have a User record. Additionally, one Org record will be created for each account owner, often with that user’s own name as the Org name. A Membership record will be created to link the User and Org records and should contain some kind of permission tag that identifies the initial user, such as ‘owner’, ‘admin’, or the like.

Then, when a team member is to be added to this account, create a new User record for them along with a Membership to link them to the original Org. The permissions field will usually contain one or more tags to identify what aspects of the account they’re allowed to view and/or modify.

We typically recommend that only the account owner be allowed to add or manage team members. In many cases, it’s also appropriate to limit management of billing and plans/subscriptions to the owner as well.

Note that using email addresses for usernames has the potential to create added complexity. The issue arises when one user might want to belong to more than one account (technically speaking, more than one Org). There are four possible solutions to this:

1. Use distinct, non-email usernames instead. In effect, this doesn’t allow multiple Orgs from a single User, but makes it easier for someone to have multiple Users (each with a single, separate Membership to an Org) with a single email address.

2. Use email addresses and usernames anyway. Don’t allow Users to belong to multiple accounts/Orgs, and if they want to, require them to use separate email addresses.

3. Implement Complex accounts instead, which are designed to allow multiple users to be associated with multiple accounts (Orgs). This has the potential to add a fair bit of additional complexity, so we encourage giving fair consideration to options 1 or 2 instead.

It is generally quite reasonable to start with this approach and grow into a Complex account approach later, if/when it is needed. This means you can avoid the added overhead of the Complex approach now without being boxed into a corner later.

4. Instead of using an Org for each team account, use a Realm. Users (and thus emails) are completely isolated between Realms, allowing emails to be duplicated. While not required, this solution is often paired with unique subdomains per-account in your app, eg: account-subdomain.your-app.com.