How can I access custom user properties in my custom action?


I’m trying to implement a custom post-login action. I’ve setup an enterprise connection (OIDC), which itself provides custom claims to the user object after login.

    "created_at": "2021-07-26T13:43:47.409Z",
    "family_name": "Mantz",
    "given_name": "Maximilian",
    "identities": [
            "user_id": "my-oidc-connection|my-user-id",
            "provider": "oidc",
            "connection": "my-oidc-connection",
            "isSocial": false
    "idp": "local",
    "name": "Maximilian Mantz",
    // these are the custom claims
    "master_roles": [
    // ...

In my custom action, I would like to forward these claims in the idToken and accessToken like this:

const roleIdentifier = "master_roles";
if (event.user[roleIdentifier]) {
  api.idToken.setCustomClaim("", event.user[roleIdentifier]);
  api.accessToken.setCustomClaim("", event.user[roleIdentifier]);

However when this action executes, the claims are not written into the tokens. When I test the action and customize the user object by inserting the roles into the user object manually, it works perfectly. But it seems like in production the event.user object does not contain the custom claims.

When using rules, accessing these claims works. However, it seems that rules will be deprecated soon. How can I achieve this behavior using actions?

Thanks in advance!


I am also having this problem with our implementation. Auth0, please advise

FWIW, I have been able to work around this limitation by explicitly loading the user via the Admin API. Unfortunately, this won’t scale well, because you will run into API rate limits at higher usage.

I’m really hoping the folks at Auth0 rectify this shortcoming soon!

Ben Schreiber
Adaptive Biotechnologies


My workaround was to use rules instead of actions. Rules will be deprecated soon however and every part of the Auth0 documentation presents actions as a better alternative. In this case however, this is not true.

I have the same issue. I’m using custom attributes on the user profile to store custom claims obtain during saml login when Auth0 plays the role of the Service Provider.

After the SAML login is done I have a rule that processes the custom SAML claims that were stored as custom attributes on the user profile.

I tried to migrate my rules to actions but I’m stuck since the custom user attributes are not populated on the user object in an action.

This is a very bad limitation of actions. Maybe it’s just an oversight ?

Can someone from auth0 confirm this and inform the engineers of the issue so it can be fixed soon ?
Until then I see no way why I would migrate to actions since in the current state they are inferior to rules in term of functionality.

1 Like

Did you have a fix on this issue? Challenging a relative issue yet no response from anyone and couldn’t see this point taking a gander at in google.

master roles are related to access of the user so can’t you just put in app_metadata like

app_metadata = {
   "master_roles" : ["admin",..]

No, the user object doesn’t come from Auth0 but from my OIDC provider. This provider doesn’t care or know about Auth0’s app_metadata.

I saw in another thread last year that this request was passed to the engineering department (that people want identity provider data in actions), but I guess it still hasn’t been implemented?

This is actually something that seems a perfect usage for actions. Due to the nature of our business, we have a lot of different clients with their own enterprise connections of various types (AAD, SAML, etc.). If we can access this data in an action, we can normalize any metadata that we need to act on in our API. Right now we are manually dealing with it in API code, but it’d be much better to keep differences related to specific provider data in Auth0 itself. We might just create a rule for now, but I’d hope this feature will be implemented before rules are fully phased out, or else a lot of people will be in trouble!

This is also a blocker for us preventing from migrating from rules to actions.
We need to access custom attributes set by SAML providers during an action without calling the management API to avoid rate limits.
I asked the auth0 support about it. This is the response I got on January 28th, 2022.


Thanks for contacting Auth0 Support today.

We are very aware of the current “feature gap” between Rules/Hooks and Actions. We are working towards a final release but progress has been delayed due to the need to complete other major engineering projects.

We are now working towards a release of the remaining Actions capabilities in Q2, though this may change if any higher priority tasks emerge.

Rest assured, customers have will have plenty of time to fully migrate Rules to Actions.


Can you share some news about it ? We really want to migrate to actions but right now we can’t because of this.

@dan.woda @konrad.sopala Do you have some news to share about when the limitations referenced at Actions Limitations will have a proper solution ?

For this topic, we are especially interested by the last one “Top-level event.user attributes added by an external IdP or custom database script”

Thanks !

Hi @vb1,

I can reach out to the team and will update here when I have a response. For expectations, I would expect a response Monday at the earliest.

Just checking in as another user looking to get this functionality working… Have there been any updates on this issue?



I don’t have an update/ETA for this. It is an identified issue and is in our backlog.

Hello @dan.woda
Now that the actions have been released officially has this feature been prioritized ?
Currently we still can’t acces “Top-level event.user attributes added by an external IdP or custom database script” as per the documentation
This is a total blocker to migrate to actions.

Hi @vb1,

Thank you for reaching out. The status is the same as the last time I posted. I’ll update this thread when I have new information.

Thank you for your patience.

Hi Dan,

I was wondering, whether this has already been implemented.

Kind regards


Look like this one is still in the backlog.

Hi all, please make sure you are clicking the “Vote” button for this topic if you are interested in seeing it implemented.

This is becoming more urgent as the scheduled deprecation of Rules will break our third party SSO login flow (only currently works with Rules). Can we get an update on whether this is scheduled for development before the deprecation?