Some of this is future-facing since we haven't implemented the multi-org model yet. I will refer to both "organizations" and "teams" as "groups" in this issue.

We have 4 resource types:

• Groups
• Users
• Workspaces
• Templates

When we add multiple groups, we have to decide how resources are associated with them.

Some obvious rules:

• Groups contain at least one user, but each user can be in multiple groups
• Groups can contain other groups, but a group cannot have multiple parent groups
• The root group contains all other groups and every user. A user cannot be removed from this group.

The trickier thing is workspace and template association. In v1, groups owned workspaces. In retrospect, this was a flawed decision. The infrastructure owner is the de facto workspace owner because they have the credentials to manipulate it. This is beyond our control. They must have those credentials to create a template. If we also give the group manager control of the workspace, we have two owners now, which is unexpected and confusing.

I propose we leave template admins as the sole owner of the templates' workspaces. Let's keep templates as a top-level resource but allow template admins to control access by choosing which groups and users can use their template.

For naming: "Organization" implies a group with many configuration knobs and its own resource namespace. The group is just a collection of groups and users in my proposed model. There is little configuration and namespacing. "Team" or "Group" could be good names, but there may be more I'm not considering.

Forward compatibility

In the future, we may decide to associate workspaces/templates with a group. The proposed model should leave those doors open. We can always let groups own more resources, but we can't walk back from that.