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 and which you can now tweak that schema 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:
- Organising and sorting accounts
- Releasing data to service providers
- Data to be read and used by your own web services
- Statistics and reporting
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 see 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.
PLACEHOLDER - SCREENSHOT
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:
- First name
- Last name
- Email address
Types of attribute you can add (and might release to service providers)
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 allowed to access the restricted sectionhas 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
IP address range
Similar to a multi line text field. Can not be set as reportable as it is multi-line.
Can have Has a configurable default value of a number of days later
. Can be set as reportable.
Each custom attribute can be set as releasable which means that our systems could pass that information on to the resource a user was accessing, subject to the release policy. If an attribute is not marked as releasable it will not appear in the release policy so cannot be releasedhas 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.
Anything to watch out for?
Modifications to your schema can have far-reaching consequences, especially once if you have already added data, so ; you should always plan out what you want to achieve before making any changes.
When attributes are released they use the unique target name you entered when the attribute was created and this cannot be changed later. To do so 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.
Once you create a custom attribute you cannot remove it, only disable it. When you disable If you disable or delete custom attributes they no longer appear in any interface including the API - i.e. they will not be returned by an API call, and any API call that tries to write to that attribute will fail.
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.