Efficiently getting full organizations membership for a user

Good day.

We are building small b2b app, which relies on Organizations feature, and utilizes Actions quite heavily.
We rely on Auth0’s TS(JS) Kit for Auth0-related interactions within codebase.

We have quite a trivial task, of getting a User’s memberships in different organizations, including roles.

At the moment we achieve that by

  • Getting membership in organizations
  • ForEach request roles

That works, but is quite demanding on network (several subrequests), and is not too efficient, as we think :slight_smile:

We came up with an idea of maybe getting this info within the Action.

First issue we faced is that unfortunately it is not available there OOB (not in user information and/or apis).

But, as you probably know - one can get ManagementClinet in Action, using something like this: How can I use the Management API in Actions?, and then - run pretty much any request that ManagementClient can deliver. THus - just move our wf there.

Thus, the Questions:
1. This method (creating ManagementClient instance in Action, running getOrganizations, then getRoles per each Organization within Action)- does it have a huge impact on the speed of the process?

I mean, currently we:

  1. Get the Login Done
  2. Get the organizations Info.
    1st step is done fast, and is non-blocking for the end-user.
    If we move 2nd step into same action - it will ofc make it slower, but question is - how bad it’s gonna be? :slight_smile:
    As bad as outside of action? Or at least a bit faster?

2. Any alternatives to this method?

3. Is there any plans to somehow expose this kind of information in more efficient way?

Because it feels a bit… unefficient to make subrequests per organization just to get participant’s roles, and imho does not facilitates usage of Organizations.
We even considered at some point switching to just storing RBAC-alike filters in metadata, and drop usage of the whole Org feature…

4. Is there a plans for more natively support ManagementClient within Actions, and if yes - any schedules, at least theoretical ones? :slight_smile:

Why I’m asking is - again - because I consider that being a very good “native” extention of Actions per-se, which we would deff use for that, and other tasks.

Thank you in advance.

BR, Seva

Hi Seva,

Just to make sure, which endpoint do you use for this:

If you read the organization members using the endpoint ‘/api/v2/organizations/:id/members’ then you can already include the roles in the response.
There was a change to this API a few months ago, now you can specify the query parameter ‘fields’ to also include the roles of a user.
For example, if you set ?fields=user_id,roles you will receive an array of members including their user id and roles.

Does that already help you?

If you plan to retrieve this information in an Action you should keep in mind that Actions will run on every authentication and even silent authentications. It pretty much depends on how long this API call will take, but it will be executed every time unless you restrict this somehow.

1 Like

Good day.
Indeed, I have noticed that change already, and using it in few other palces.
Very good change :slight_smile:
Looking forward to have it properly typed in the npm packages :slight_smile:

But for this particular usecase - this option does not really speed things up, as the workflow is

  1. Discover Organizations of User
  2. Discover user’s Roles in each Organization.

Thus, we will anyways have to multiply second phase by list of organizations from the first one.

Additional clarification why this is not viable (after reading some posts concerning similar questions): we are planning to have maybe even thousands of Organizations in the long run (span of several years). Even if we do “cleanup” on inactive ones - it still rounds up to some hefty hundreds.
Thus starting that scan from Organizations perspective - is not viable.

Other possible solution might be making some kind of web-hook, that “Whenever ANYTHING changes roles of User in Organization - inform external Service”.

Or then reliably getting timestamp of “When this User’s roles where updated in this Organization”.

Re-analyzed current capabilities, ended up with feature-request here:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.