Appreciate the feedback! We've had people use organizations in both ways, honestly. The implementation is definitely more like a Gmail group of users than a company.

In your example, some people have implemented it as Acme is the organization, and some people have implemented it as specific teams within Acme are an organization.

I suspect we'll need to add a second tier (e.g. a team or a group) underneath a more rigid definition of a company. Would that have made things more clear?

Yeah, for my specific use case, I'm less interested in user-defined teams and more interested in company admins inviting users with specific roles (which sounds like a common scenario).

We're currently integrating Auth0 for authentication but sticking to our own authorization stuff. Auth0 organizations seem way heavier than what we need, more for like white-labeling an app to a handful of huge enterprise clients, rather than just having lots of small clients with a handful of users each.

That makes sense - and is definitely something we'll need to more clearly support. The distinction between the two cases is also pretty clear, thanks for you all your thoughts here!

We had similar feelings about Auth0's org implementation, it doesn't really match the way most companies think about orgs, especially at an early stage.

This company/team distinction describes what we're looking for next in our implementation :)

Also, hey, I'm Adam, a very happy customer of PropelAuth at Kable.io. Andrew is an incredibly responsive founder, who has been a great partner in the launch of our own B2B business. High recommend from me -- PropelAuth rules