Creating Custom Fields for Incident Reports and Events
The custom fields framework allows you to add input fields for use on incident reports, events, or both. Your organization can collect and report on incident-related information that is specific to your environment. You can create fields for specific classifications. These fields will only display when that classification is selected. You can also leave them unclassified. Unclassified fields display even when no classification is selected.
The major headings shown on this page correspond to active Classifications in the page. In the image below, the classification, Motor Vehicle Accident, is inactive. Therefor, it is now on the Custom Fields page. If custom fields are associated with a classification and that classification is inactivated, the fields are not completely removed. Activating the classification again displays its custom fields.
Custom fields that are not associated with a classification display in the Not Classified area. These global custom fields display on all submissions even if a classification is not selected.
While working in this settings page, by default, all except hidden fields display. Options in the drop down menu in the upper right are used to display only fields on Events or Submissions (Incidents). A check box on this same menu will show hidden fields. Hidden fields display with gray text instead of black text.
Best Practices
- Carefully plan the custom fields you want to use and make as few changes as possible after they have been used in submissions.
- Make only spelling or grammatical changes to field or answer labels after they have been used.
- When the meaning of a field or answer changes,
create a new field and hide the old one.
Note: The hidden field will continue to display on previously submitted forms since it was not hidden at the time of the submission. The new field will display on previously submitted forms but as these cannot be updated, the field will remain blank. You may wish to incorporate a revision date in the label to make it easy to identify when the field or answer was added. For example, a field label such as "How many persons knew about this? (060612)" where 060612 represents June 6, 2012. Comparing the submission date to the revision date will aid in explaining why a field may be blank.
- Making fields required after a field was used will display as required on prior submissions that used the field. For example, if a field was not required in January but was changed to required in February, the submissions created in January may be blank because users were not required to complete it at the time they submitted the form.
- Hiding or unhiding fields will not affect prior submissions. Hiding a field prevents it from displaying on future submissions only. Unhiding a field displays the field on future submissions only.
- Hiding fields is preferable to deleting. Hiding removes them from view and can provide good historical information.
Security Permissions
- Manage Custom Fields