26% of Part II — hands-on configuration, not multiple choice.
5 tasks · this deck covers task 4 of 5
↑ User Management OverviewTask 3 was about creating the container — the user type itself. This task is about what goes inside it: giving that type an attribute the default profile doesn't have.
Each user type operates independently when it comes to attributes. Beyond the 31 base attributes every type starts with, an org can layer on custom attributes specific to a given type — a "Contractor" type might get a Contract End Date attribute that a full-time "Employee" type never needs.
Organizations can apply different constraints on attributes across types — for example, enforcing a different email domain requirement for one user type than another.
The same attribute name can behave differently depending on which type it's attached to.
Two user types can point the same custom attribute at two different destinations in a downstream app. Don't assume attribute mapping configured for one type automatically applies to another — it doesn't.
This is the same underlying resource as Task 3, but a different angle: Task 3 = creating the type and assigning a user to it. Task 4 = going back into that type afterward and extending what it carries.
Watch for these in your own sandbox run:
→ Adding an attribute to the wrong user type and wondering why it doesn't show up for other types — that's expected; attributes are per-type.
→ Assuming an app-attribute mapping carries over between types — it has to be configured per type.
Sources: help.okta.com — usgp-usertypes-about.htm
Next: Task 5 →