Understand attribute rules for the profile enrollment form
When working with the profile enrollment form, you should understand the requirements and user permission settings of the Okta Universal Directory (UD) attributes inherited by the form.
The goal of the profile enrollment form in a Progressive Enrollment scenario is to collect information about the end user and add it to their Okta user profile. Therefore, the attributes shown to the end user must already be defined in the default user profile of UD.
Base attributes
There are 31 predefined attributes in the Okta default user profile. See Profile types. You can add any of these base attributes to the profile enrollment form, but they must adhere to the following rules:
-
Any UD attribute that you want to use in the profile enrollment form must have a User permission setting of Read-Write. This is necessary to allow users to update the value of this attribute during the sign-in process.
-
If a UD attribute has a User permission of Hide or Read Only, the enrollment form is disabled. You can't add, edit, or delete any part of the form until you change the User permission level using the Profile Editor.
-
-
If the Attribute required setting is enabled for the attribute in UD, it's automatically added to the profile enrollment form when you create the enrollment policy.
-
You can edit the Form label shown to the end user for this attribute.
-
You can't change the Input requirement for this attribute. It's set to Required because the end user must provide a value so Okta can add it to the user's UD profile and continue the sign-in process.
-
The profile enrollment form shows the value for this Input requirement field in the Requirement column.
-
You can't change the Input display type.
-
You can't delete this attribute from the form.
-
-
If the Attribute required setting isn't enabled for the attribute in UD, then the attribute isn't automatically added to the form.
-
You can add or delete this attribute from the enrollment form later.
-
You can edit the Form label shown to the end user for this attribute.
-
You can change the Input requirement for this attribute to either Required or Optional.
-
Required: The end user must provide this input to continue the sign-in process.
-
Optional: The end user can skip this input and continue the sign-in process.
-
-
The profile enrollment form shows the value of this Input requirement field in the Requirement column.
-
You can delete this attribute from the enrollment form, as the attribute isn't required at the UD profile level.
-
The following table explains the required conditions and permitted actions for a few example base profile attributes.
UD: Variable name | UD: Attribute | PE: Automatically added to form | PE: Action permitted |
user.login | Yes | Yes |
|
user.firstName |
Yes |
Yes |
|
user.middleName | No | No |
|
user.title | No | No |
|
Custom attributes
Custom attributes are any attributes outside the base Okta UD attributes (for example, a favorite team for a sports fan or a vaccination status for a pharmacy customer). The custom attributes for which you want to collect data from the end user must be added to the UD profile before you can add them to the profile enrollment form.
Custom attributes follow the same restrictions as base attributes:
- You must set the attribute's User permission setting to Read-Write in UD so it can be added to the profile enrollment form.
- If it's marked as a required attribute in UD, you can edit the attribute's label for the profile enrollment form, but you can't delete it.
- If it's marked as an optional attribute in UD, then you can edit the attribute's label and input options (including specifying it as a required or optional step for the enrollment form) or delete it.
-
You can change the Input display type to a value that best reflects the kind of information expected from the end user. Most fields have a string data type and use a text box as the input type, although the enumeration data type uses either a radio button or a dropdown menu. However, if you select fields with a data type such as country code or a boolean the enrollment form changes to the corresponding input type.
The following table explains the required conditions and permitted actions for a few example custom profile attributes.
UD: Variable name | UD: Attribute | PE: Automatically added to form | PE: Action permitted |
favoriteTeam | Yes | Yes |
|
favoritePlayer | No | No |
|
Multiple identifiers
Early Access release. See Enable self-service features.
Identifiers are attributes that a user can enter instead of their username to sign in to an app or recover their account. You can select two custom attributes in the default Okta User profile to serve as identifiers, as long as they're unique, non-sensitive, and have a string data type.
When this feature is enabled, the profile enrollment policy is renamed user profile policy.
Identifiers are configured in the user profile policy on a per-app basis. There's nothing that you need to do in the Universal Directory to enable identifiers, but if you're adding new attributes for this purpose, follow the Custom attributes recommendations.