ClickUp Custom Fields by Task Type: Company and Contact Setup

ClickUp Custom Fields by Task Type can reduce irrelevant fields in a sales List, but only if the Workspace has a clear record model. Put organization data on a Company task type, person data on a Contact task type, and workflow controls used by both as location-based fields at the narrowest suitable List, Folder, Space, or Workspace level.

This is a configuration pattern, not a built-in ClickUp CRM schema. Before changing fields, decide what each task represents, classify existing records, and document the fields that must remain usable after migration. A task-type field and a location-based field are separate scopes, and one Custom Field cannot use both scopes at the same time.

The practical goal is not to move every field to a task type. It is to show each record only the data its role requires while preserving shared operational controls and making intake, reporting, and integrations easier to validate.

How ClickUp Custom Fields by Task Type work

A task-type Custom Field is displayed according to a task’s custom task type. A location-based Custom Field is available through the hierarchy where it was created, such as a List and its parent Folder, Space, or Workspace. Both models can coexist, so a task can show fields assigned to its type alongside fields inherited from its location.

ClickUp does not inherently know that a parent task is a company or that a subtask is a contact. Those meanings come from the Workspace’s design. You can configure Company and Contact task types, but those names and their business meanings are implementation choices. See ClickUp’s Custom Fields by task type overview and custom task type instructions.

For a sales List, use this decision rule: assign record-specific fields to the task type that owns the record, and keep fields used across multiple record types location-based at the narrowest suitable level. Decide the scope before creating or converting a field.

Choose the record model before choosing fields

A company as a parent task with contacts as subtasks is one possible ClickUp implementation pattern. Parent tasks and subtasks can use different custom task types and therefore display different task-type fields. This model may suit a team whose records mostly follow a one-company-to-many-contacts relationship, but it is not automatically the right structure for every sales process.

Define the data grain first:

• A Company task represents one durable organization.
• A Contact task represents one person associated with an organization.
• A Deal represents one sales opportunity.
• An Activity represents one call, meeting, or follow-up.
• An intake event represents one form submission, email, webhook, or API event.

Decide how deals and activities relate to companies and contacts before building views or Automations. A person associated with multiple companies may not fit cleanly as one contact subtask. If the relationships, reporting, or lifecycle rules do not fit the hierarchy, consider another design or a dedicated CRM.

Place fields by business meaning

Use the field’s meaning and owner to choose its scope. If it answers “which organization?”, put it on Company. If it identifies or helps reach a person, put it on Contact. If both record types use it to operate the same workflow, keep it location-based.

Scope	Illustrative fields	Why it belongs there
Company task type	Industry, Company size, Budget range, Fit	Describes or qualifies the organization
Contact task type	First name, Last name, Email, Phone, Role	Identifies or helps reach a person
Shared location	Owner, Status, Source, Region, Next follow-up date	Supports work across record types

These examples are not a required ClickUp schema. Before migration, create a field contract for every field that records its definition, data grain, owning task type or location, field type, permitted values, source of truth, update owner, required or optional status, and whether historical values must remain usable.

A team could also implement a binary qualification score, such as one point for each confirmed criterion, if that model fits its sales process. It is a team-designed method, not a ClickUp default or validated sales methodology. Verify support before using calculated or other unsupported task-type field types.

Create task types and migrate fields safely

Workspace owners and admins can create custom task types. Existing tasks can be assigned a type individually or in bulk, and a List can have a default type for new tasks. A default establishes a starting point but does not classify every incoming record correctly. Task permissions, plan limits, and feature availability determine who can create, assign, or manage these settings. Required Custom Fields are documented as available on Business and above.

ClickUp’s current task-type field documentation lists Button, Files, Formula, List-to-List Relationship, and Tasks as unsupported field types for Custom Fields by task type. Check the current documentation before designing around one of these types or assuming that a plan supports a particular configuration.

To convert a location-based field:

1. Open the Custom Field settings.
2. Go to Advanced Settings.
3. Edit Field belongs to.
4. Choose Task Type and add the intended custom task type or types.
5. Save and review the impact warning.

These labels and screens can change, so consult ClickUp’s current field conversion instructions while configuring.

Values on tasks outside the selected type may become temporarily hidden. ClickUp says the values are not deleted. Classify existing tasks before conversion, then test representative records and every downstream consumer that reads the field. Do not assume a field disappearing from a Contact task means the data was erased.

For a broader review of field placement and dependencies, see ClickUp audit.

Route incoming records to the right type

ClickUp supports intake through Forms, email, API integrations, Automations, and webhooks. Creating a task does not by itself make it the correct Company, Contact, Deal, or Activity record. Each source needs an explicit mapping for task type, field values, source identifiers, and incomplete or ambiguous submissions.

Use deterministic routing when a form supplies a record-type answer, an integration supplies a known object type, or a stable external identifier is available. AI can suggest a type for ambiguous free text, but keep the permitted types fixed and require review before changing an existing verified type.

Trigger or source	Routing or AI job	Validation	Action and fallback
Form or email intake	Use an explicit record-type answer or a defined rule. Use AI only for ambiguous text.	Check routing data, email format, source ID, duplicate candidates, and task-type assignment.	Create in the designated intake List. Send missing or conflicting data to a sales-ops reviewer.
External API or webhook	Map the source object type to a known ClickUp task-type ID.	Check field applicability, IDs, allowed values, event identity, and authentication.	Write to the target List. Queue unknown types, invalid values, or identity conflicts for the integration owner.
Manual migration	Use the inventory and classified tasks to select the destination type.	Review the impact warning and test views, Automations, reports, and API consumers.	Convert one field in the pilot. Pause or reverse the change if values or dependencies fail.

Illustrative form sequence: a website submission supplies record_type=contact, a contact email, a company name, and a submission ID. The intake rule maps Contact to its task-type ID, validates the email, stores the submission ID as event provenance, and sends an ambiguous company match to a human reviewer. The submission ID identifies that intake event. It does not prove that the organization is a new Company record.

ClickUp documents Form-related creation sources, Automations, email-to-List task creation, and incoming webhooks, but each path has its own permissions, limits, and mapping requirements. Email-to-List can suit lower-volume intake, while ClickUp recommends the API rather than email for large-volume task creation.

Validate API writes and prevent duplicate records

A proposed integration sequence is:

1. Retrieve the Workspace’s available custom task types and their numeric IDs.
2. Create or update the task with the correct custom_item_id.
3. Retrieve the Custom Fields accessible to the List with task-type applicability available through applied_objects when requested.
4. Confirm that each field applies to the task’s current type.
5. Set values through ClickUp’s Set Custom Field Value endpoint.

The Update Task endpoint does not write Custom Field values. Use field IDs rather than display names. Dropdown writes require the configured option ID, not only the visible label. Validate values against their field types, including booleans for checkboxes, numbers for number fields, strings for text and email fields, and the documented Unix-millisecond format for dates. ClickUp documents a 400 response when a field is not enabled for the task’s current type.

For structured events, keep the source event, durable record, and activity at separate grains. A proposed external integration model might use (source_system, source_event_id) as the unique key for one intake event, a normalized company identifier for one company, and a source activity ID for one activity. These are integration design choices, not ClickUp-published uniqueness fields.

For example, an event may contain a source system, event ID, record type, company domain, and contact email. The integration claims the event key, maps the record type to a known task-type ID, validates field values and dropdown options, resolves a possible existing entity, and then creates or updates the task. If two company matches are plausible, stop the write and assign the exception to a named integration or sales-ops owner.

Use the official custom task type API guide, accessible Custom Fields endpoint, and Set Custom Field Value endpoint when implementing the mapping.

Test the design before expanding it

Pilot one noisy sales List and observe how people complete, correct, and classify records. Useful internal measures include irrelevant-field exposure, required-field completion, corrections per record, duplicate rate, intake-to-correct-type time, and integration exceptions. These measures help evaluate your implementation. They do not establish that task-type fields independently improve adoption, reporting, or data quality.

Limit contact details and webhook payloads to what the workflow needs. Check member and guest access for sensitive information, and confirm the target Workspace’s plan, permissions, task-type usage limits, required-field availability, Automation access, and webhook access before rollout. Product limits and interface labels can change.

Expand only when observed errors and team feedback support the design. If you need help reviewing field dependencies or configuring the workflow, explore ClickUp setup and automation.