User accounts and permission sets have attributes (data fields) associated with them such as an account holder's name and email address. The attributes that appear are controlled by the attribute schema which you can tweak for your domain via the schema editor.
The schema editor allows domain administrators to define additional attributes to be stored on accounts and permission sets. These custom attributes can be used for things such as:
These custom attributes are in addition to some 'core' attributes which are hard wired into the system. The core attributes cannot be edited and will appear in interfaces ahead of any custom fields you add.
If you look at the account create dialogue you will notice that all the mandatory fields appear on the same tab and the optional fields are similarly grouped together on another. Custom attributes you create via the schema editor will appear below the core fields on either of those two tabs based on whether or not you have set the required flag on them.
Whilst the list of optional core fields is long, it is expected that most of the custom attributes you will want to add will be ones you set as required so would appear below the small number of mandatory core attributes, which are:
Single or multi-line text fields for information such as identifiers or course codes. Can be set as reportable if single line.
For drop-down lists of options for things like job roles, disciplines or other things to group on. Can be set as reportable.
For either / or questions such as whether someone is full time or has agreed to something. Can be set as reportable.
Similar to a single line text field but includes validation for an email address. Can be set as reportable.
Similar to a single line text field but includes validation for a URL - e.g. must start with a protocol such as http://. Can be set as reportable
Similar to a multi line text field. Can not be set as reportable as it is multi-line.
Has a configurable default value of a number of days later. Can be set as reportable.
Each custom attribute has the potential to be released to service providers alongside the releasable core attributes... if you mark it as releasable in the schema editor. Whether or not it is then released and to which resources is controlled by the release policy.
Modifications to your schema can have far-reaching consequences, especially if you have already added data; you should always plan out what you want to achieve before making changes.
When attributes are released they use the target name you entered when the attribute was created and this cannot be edited. Should you need to change this name you would need to create a new attribute and migrate data either one account at a time or by using bulk download / upload tools.
If you disable or delete custom attributes they no longer appear in any interface including bulk upload, download, and the API, so any processes you have set up that expect that data will run into difficulty. The reporting function will stop collecting their data.
When you set an attribute as required, the account edit functions will not let you save changes until the mandatory field is completed.
The reporting function starts collecting data on custom attributes as soon as it starts seeing accounts that have a value, but cannot apply it retrospectively to data that has already been collected.