Applies to

when you create a custom field, the first thing you'll configure is applies to this determines whether the field is attached to a person record or a job record, and that distinction shapes how data behaves across your org people — the field is tied to the individual employee data follows the person regardless of what role they're in use this for information that's fundamentally about a person, not a position examples t shirt size, emergency contact, preferred name, dietary restrictions, personal certifications jobs — the field is tied to the position itself if a person moves into a different role, the data stays with the job use this for information that describes a seat in the org, not an individual examples job level, cost center, headcount type, requisition id not sure which to pick? ask yourself would this information still apply to the person if they changed roles? if yes, it's a people field if it describes the role or position itself, it's a jobs field track changes over time when applies to is set to people , you'll see a track changes over time checkbox when enabled, every change to the field is stored with an effective date you can view the full history of changes on a person's profile under personal history turn this on when you need a record of what the value was at any point in time — not just what it is today turn it on for performance rating, job level, employment type, work location, visa status leave it off for t shirt size, dietary preference, emergency contact — data where only the current value matters a note on legacy "people in jobs" fields if your org was set up before mid 2024, you may see fields labeled people in jobs in your field list this was an older field type that is no longer available for new field creation it has been replaced by people fields with track changes over time enabled existing people in jobs fields continue to work, so you may see them in your custom field list, but no new fields of this type can be created