1. Navigating to the Custom Fields Page
For employee custom fields: People Tools → Custom Fields
For pay range custom fields: Pay Range Tools → Custom Fields
You must be a Company Admin to access these pages.
2. Entity Type: User vs. Comp Cycle (Proposal)
When creating a custom field, you choose which entity it's tied to:
User (Employee) — The field lives on the employee record itself. It persists across comp cycles and represents standing data about a person (e.g., "Cost Center", "Visa Status").
Proposal (Comp Cycle) — The field is tied to a specific comp cycle's proposals. It only exists in the context of a review and can vary cycle to cycle (e.g., "Manager Rating", "Promo Recommendation").
Range — Tied to pay ranges/bands rather than people.
Key implication: User fields are persistent and global; Proposal fields are scoped to a single comp cycle and can differ each time.
3. "In App" vs. "Computed"
This is the Source Type setting:
In App — Values are entered manually (typed in by users, bulk-uploaded via CSV, or synced from an integration). These fields can be made editable.
Computed — Values are calculated automatically by a logic graph (Comprehensive's visual formula builder). Computed fields cannot be made into editable inputs — their values are always derived from other data.
Integration — A third source type for fields synced from external systems (HRIS, payroll, etc.).
4. Suggested Values
If a custom field is set to In App (editable) AND you enable suggestions:
A logic graph can populate a suggested value alongside the manual input.
Users see the suggestion and can accept, override, or ignore it.
This is useful for things like "suggested merit increase" where logic recommends a value but a manager has final say.
To configure suggestions: create a logic graph that outputs to this custom field. The logic graph's computed result becomes the suggestion shown to users alongside the manual input.
5. Making a Custom Field an Input (and Dropdown Lists)
Check "I want this to be an input field" — this turns the field into something users can type into during a comp cycle or on an employee profile.
Check "Enable selectable options" — this converts the input into a dropdown list. You then define the set of allowed values (e.g., "Exceeds", "Meets", "Below"). Each option is validated against the field's format type.
For currency fields specifically, there is also a Dual Input mode where users can enter both a dollar amount and a percent, with a configurable base value (e.g., % of salary).
6. Annualize Values Based on Pay Frequency
When the format is Currency (Dollar), you'll see a toggle for "Annualize values based on pay frequency":
Enabled — The value represents a recurring payment (like a salary or stipend). The system will normalize it to an annual figure based on the employee's pay frequency (monthly, biweekly, etc.) for apples-to-apples comparison.
Disabled — The value is treated as a one-time amount (like a sign-on bonus) and is not adjusted for pay frequency.
This auto-enables when you select the Dollar format but can be manually toggled off.
7. Format Options
You can choose from these value types:
Text — Free-form string
Number — Numeric, no currency symbol
Currency (Dollar) — Monetary value (displayed as dollars)
Percent — Percentage value
Date — Date value
The format affects validation, how values display in tables, what import formats are accepted, and which features are available (e.g., annualization is only for Currency).
8. Why Custom Fields Can't Be Deleted If Used in Downstream Logic Graphs
Every logic graph tracks which custom fields it depends on (its upstream dependencies). If your custom field feeds into another field's logic graph:
The delete button is disabled with the tooltip: "Delete disabled: Used in downstream logic."
This protects data integrity — deleting the field would break every downstream computation that depends on it.
To delete a field with downstream dependencies, you must first remove it from all logic graphs that reference it.