Creating custom fields

Creating a custom field is easy; creating one your organization will still understand in two years takes discipline. This guide covers naming conventions, choosing the right type, deciding which roles may view or edit the field, and how to roll out changes without breaking existing imports or integrations.

Database stewards and program directors should collaborate before fields proliferate.

Overview

Draft each field with a plain-language label and a stable internal key mindset—even if the UI hides keys, integrators will see them. Choose types that constrain bad input (picklists over free text when the universe of answers is known) and document allowed values for anyone entering data offline.

Pilot with a small team, validate reports, then expand permissions. When retiring a field, prefer deprecation workflows (stop writing, keep historical values) over hard deletes that erase audit context; detailed lifecycle steps will ship in a later revision.