Loading
Because when the field does not exist the information goes in a notes box. It is then present, unqueryable, inconsistently phrased, and invisible to every report that matters.
A custom field can be added to any object — deal, contact, company, quote — with a type, validation rules, a position in the interface and an entry in the API.
Custom fields behave exactly like built-in ones. They are indexed and filterable, they appear in segments and reports, they are covered by the audit trail, and they are in the API from the moment they exist.
A distributor added "contract end date" as a real date field rather than a note. Renewal reporting, a segment and two automations followed from it in an afternoon, because the field was queryable.
They do not change what a record means to the other products. Loop and Books read the fields they are built on; a custom field is yours to use, not something they will infer meaning from.
Segments filter on them, dashboards report on them, the API exposes them, import and bulk edit maps to them, and the audit trail records changes to them like anything else.
Yes, from creation, with their type. No configuration step, no separate endpoint.
Yes, globally or per stage, which is usually where it belongs.
No hard one. Field-level permissions matter more as the count grows.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.