Okta - Read User will most definitely will return custom attributes. Just as part of setting up the card you select the attributes you want to map. For example, if you go into profile editor and create a new customAttribute then immediately go and add an Okta - Read User card one of the selectable fields is going to be the new custom attribute.

If you are saying the attribute is not populated (empty / null) this is likely because of timing. For example the create user event occurs and starts the flow before the user creation is actually completed in the Okta backend.

Hey Tim - thanks for the quick reply. Responsiveness is always appreciated.

So, after further experimentation, I found what I think is the problem.

I have two user types defined in my org. The default "Okta" user type, and lets' call the other type "Type B". The custom attribute I'm interested in only exists on the profile of Type B users.

But the Read User card only allows me to select fields that correspond to the profile of Okta type users, whose profile has no custom attributes. I don't see any way to configure the Read User card to target a specific user type, or all user types.

Maybe I'm misusing the UserType concept?

So when you have created a non-default User Type (Directory > Profile Editor > + Create Okta User Type) it will allow you to create a new subset of users attached to the specific user type. When that user is created it is going to generate a uniqueID for the user just like it will for the default

Example: https://myDomain-admin.okta.com/admin/user/profile/view/00u4wxx3oD0AAAn5d7

This user can be read via the user's API endpoint the same way as users in the default. The problem you are running into is the built-in Read card performs a dynamic enumeration of the "Default" User Type attributes only. It is not designed to work with non-default user types. Unfortunately, this is also going to be true for the "Update" type cards also (Basically any of the built-in cards that dynamically list the properties are only going to work with the Default User Type).

To work-around this utilize the "Custom API Action" option. The "relative URL" would be the following taken from my example above:

/api/v1/users/00u4wxx3oD0AAAn5d7

This will return all of the user's properties. You can then pull out the attributes you want utilizing an Object Get (or Get Multiple).

To update the properties you will want to reference the API documentation and will have to do some build-out yourself.

https://developer.okta.com/docs/reference/api/users/#update-user

(Note: You are likely going to want to utilize POST which is partial instead of PUT which is strict, make sure to read the differences).