4 ms·

I'm a little confused how the PropelAuth concepts map to typical B2B scenarios. For example, say Alice works for Acme, and she signs up for Jira. She is now th

I'm a little confused how the PropelAuth concepts map to typical B2B scenarios. For example, say Alice works for Acme, and she signs up for Jira. She is now the admin, so puts the credit card in to upgrade the account, and then invites her colleagues. Is Acme an "organization" in terms of PropelAuth? Organizations sound looser and more user defined, almost more like a Gmail group of users than a "company".

aisrael 5y ago
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?
- asommer12 5y ago
  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
- satyrnein 5y ago
  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.
  - aisrael 5y ago
    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.

aisrael 5y ago

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?

asommer12 5y ago
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
satyrnein 5y ago
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.
- aisrael 5y ago
  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.