Safe / Unsafe

The Safe / Unsafe setting for a person-scoped field determines how the field can be updated if an application in an active period exists for a record.

If a person-scoped field is configured as Safe, the field value is not updated by a safe source import or a safe form submission if the record has an application in an active period.

You can override the safe field behavior in the following ways:

Setting Behavior
Unsafe set on field Always treats the field as Unsafe, regardless of the settings on the import or the form.

Unsafe set on form or Unsafe set on import

Treats all mapped fields as Unsafe, regardless of the individual field settings.
Unsafe set on specific field destination Treats a specific mapped field as Unsafe, even if the form or import and the field are set as Safe.

By default, all forms (that are not application, application creation, or reader-scoped) and custom fields that are not application-scoped are treated as Safe, unless one of the three methods above is used to override this setting.

For data imports, any data mapped to application-scoped fields is always treated as Unsafe, and is always imported, regardless of the Safe or Unsafe setting on the import.

  • Devices and relationship-scoped fields are safe.
  • Tests and school-scoped fields are unsafe.


In most cases, custom fields should be configured as Safe. Remember, it is possible to override a field’s Safe setting when configuring a form, a source import, or even a specific mapped field destination.

There is no way to override the behavior of a field configured Unsafe (that is, an Unsafe field is always updated regardless of the conditions set on a form or import). Only set a field to be Unsafe if under every circumstance, the data in that field should be updated by a form submission or a source import (such as an SIS ID field).

Example Safe Fields Timeline

The following example describes the timeline for a Hispanic field that is configured as Safe:

Was this article helpful?
12 out of 14 found this helpful