Modeling users and groups

I’m in the process of building out an efiling service, and one of the things I have to do is figure out how to give companies and their employees access to our service. In earlier roles, this is the sort of design work that had already been done long before I joined, so I was just adopting the existing pattern. There is no existing pattern to fall back on, since we are building from scratch, so I am grappling with these issues properly for the first time. I am trying to figure out from first principles how to model users and the groups they form.

There are a few layers to this cake. The first one is foundational and, I think, mostly uncontroversial: identity is organized around individuals. A user is the digital identity for an individual, and by individual we usually mean a natural person. There is some nuance around exactly how to represent that identity—an opaque id, an email address, a username—but the meaning is the same irrespective of the representation. Conceptually, a user is the most elementary unit of identity that a service can reason about.

The next layer is about how to group users in meaningful ways. At my last company, we called this grouping an account, but that never sat right with me. To my mind, an account is synonymous with a user, and it gets used that way in passing all the time. For instance, you might need to “log in to your account” or “reset the password for your account.” Interestingly, AWS started out with the idea that one account is for one user, but they have been discouraging that approach for more than a decade now. Once they introduced the concept of IAM and multiple identities in a single account, the account became more of a grouping mechanism.

The better name for this grouping is organization. Instead of logging in to an organization, you log in as an individual user, and then you can access organizations that you are part of. The organization itself is a collection of shared resources that users can access. When you create a user account, the standard flow is to associate it with an existing organization or create a new organization to associate the account with. A user can be part of multiple organizations and can have different roles in each one. This participation in an organization is called a membership. This is the framing that GitHub, Braintrust, and others use. Slack and Notion call these workspaces, but I think that language only makes sense in specific domains.

There is one more layer above that can be used to group the groups themselves. GitHub calls them enterprise accounts, Slack calls them enterprise organizations, and AWS calls them organizations, but the idea is the same. This enterprise container is a way to manage multiple organizations, and it seems most useful for massive corporations that have many departments, each of which might come to your service independently and at different times. At some point, the top level entity needs to coordinate permissions and billing across the board, and merging the organizations is impractical for a variety of reasons. This might also be the case when one company merges with another, and each one has its own organization that predates the merger.

This is the piece that I have the least clarity on in terms of what gets managed at the organization level and what gets managed at the enterprise level. I think it is also the piece that varies the most across services in terms of its shape. In any event, I expect that most service providers can get away without defining this layer for a long time, and so I am going to leave it at that for now.