These docs are for AuthRocket 1. Looking for AuthRocket 2 docs?

Complex accounts

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 the most complex of the common use cases, where it is desirable to allow each User to belong to multiple accounts and each account to have multiple associated Users. In database terms, it is a many-to-many relationship.

When a new account is created, a User, Org, and Membership will all be created. The account is represented by an Org record, the user creating the account gets a User record, and a Membership links the two together. Usually the Org’s name field will contain an actual name for the account that isn’t the user’s name, most commonly a company or organization name or a project name.

It is often helpful to create this initial Membership record with some kind of permission tag that identifes the initial creating user as the account owner. To do so, we recommend adding a permission tag of ‘owner’, ‘creator’, or similar. If the owner of record needs to be changed later (perhaps because of employee turnover), move/reassociate the owner tag. If neither your app nor any external software (often metrics/analytics) need to associate a primary user/owner with an account, then you may not need this at all.

When adding additional users to the account, if the user already exists, just create a Membership record linking that User with the account’s Org. If the user doesn’t exist, create both a User record and a Membership record.

It is often necessary to provide two signup / registration flows in your app. One for creating complete accounts (User, Org, and Membership) and another for creating users that are joining an existing account (User and Membership only). It is also sometimes helpful to allow for an existing User who previously registered for the purpose of joining an existing Org to also create their own account/Org (where they will be the owner).

Sometimes all of the above can be simplified by separating user signup from creating an account/Org. For example, after user signup, present the user with options to join an existing account or create a new account. Joining an existing account might prompt for an invitation code or might just show instructions to contact the account owner and have the owner add them to the account.

Likewise, when showing them a list of available accounts to use, provide an option to create a new account.

In nearly all cases, each Membership record will make use of the permission field to enumerate each user’s rights on each account.

Questions? Find a Typo? Get in touch.