Your ClickUp Custom Fields Are Silently Rejecting Data (Here's Why)

You set up an integration between your CRM and ClickUp. You map deal amount to a ClickUp custom field. You run the sync.

The task gets created. The name is right. The description is right. The custom field is blank.

No error. No warning. No failed execution log. The field just didn't populate.

This is the single most confusing integration problem with ClickUp, and it has one cause: type mismatch.

How ClickUp custom fields actually work

ClickUp custom fields are strictly typed. Every field has a type — text, number, dropdown, date, email, phone, checkbox, currency, labels, and more.

When you write data to a custom field via the API (or through Zapier, Make, or any middleware), ClickUp checks whether the incoming data matches the field type. If it doesn't match — the write is silently skipped.

Not rejected. Not errored. Skipped.

The field stays blank, or keeps its previous value. The API call returns a 200 (success). Your automation reports "completed successfully." Everything looks fine except the data isn't there.

The most common mismatches

Text → Dropdown

This is the #1 cause. Your source system sends the string "High Priority". The ClickUp field is a dropdown. ClickUp expects a dropdown option UUID or orderindex — not a plain text string.

Result: blank field.

Number → Text

Your CRM sends the number 15000. The ClickUp field is a text field. ClickUp expects a string.

Some middleware tools auto-convert this. Some don't. If the number arrives as an integer, the text field may silently reject it.

String → Number

The reverse. HubSpot returns ALL property values as strings — even numbers. So your deal amount arrives as "15000" (text), but the ClickUp field is a number type expecting an actual integer or float.

Result: either blank, or 0, or the string gets written literally as text (depending on the ClickUp field version).

Date format mismatch

HubSpot dates are Unix timestamps in milliseconds. ClickUp dates are also Unix timestamps — but the timezone offset handling differs. A deal closed on April 15 in your timezone might show up as April 14 or April 16 in ClickUp.

No error. Just the wrong date.

Multi-select → Single-select

Your source field allows multiple values (ClickUp Labels, for example). Your target field is a single-select dropdown. You can't put an array into a scalar field.

What happens varies by tool. Some take the first value. Some crash. Some send the entire array as a string and it gets rejected.

How to debug this

Step 1: Check the field type on both sides

Open the ClickUp field settings. Note the exact type — not what it looks like, but what type it's configured as.

Open the source field (HubSpot, Zapier, wherever). Note what type of data it sends.

If they don't match exactly — that's your problem.

Step 2: Check the actual payload

If you're using Zapier or Make, look at the execution log. Find the API request that writes to ClickUp. Look at the custom_fields array in the request body.

Each custom field entry should have:

• id: the field UUID
• value: the data being written

Check what value contains. Is it a string? A number? An array? An object? Compare that to what ClickUp expects for that field type.

Step 3: Add explicit type conversion

If your middleware lets you add formatting steps, add one before the ClickUp write:

• Text → Number: Use a formatter to parse the string as an integer or float
• Number → Text: Wrap in a text formatter or concatenate with an empty string
• Text → Dropdown: Use the ClickUp dropdown option UUID (not the display name). You'll need to look up the options first.
• Date → Date: Ensure Unix timestamp format with the correct timezone offset applied

Step 4: Test with one record

Don't test with a batch. Send one record. Check the ClickUp task manually. Verify every custom field populated correctly.

If one field is blank — that's your type mismatch. Fix that field's mapping, test again.

The dropdown problem specifically

Dropdown fields deserve their own section because they combine two problems:

1. Type mismatch: You can't send plain text to a dropdown field
2. Index instability: The ClickUp API identifies dropdown options by orderindex (position integer starting at 0). If someone reorders the options in ClickUp settings, every index shifts. Your integration silently maps to the wrong option.

I wrote a separate deep-dive on the dropdown index trap in this post.

The safe approach: map dropdown options by their UUID or name string — not by position index. If your middleware doesn't support this, build a lookup table that maps display names to UUIDs.

Why this keeps catching people

Three reasons:

1. The API returns 200 on silent skips. A successful HTTP response doesn't mean the data was written. It means the request was processed. ClickUp processes the request, skips the invalid field, and returns success.

2. No field-level error messages. If 5 custom fields are in the request and 1 has a type mismatch, the other 4 write successfully. The API doesn't tell you which field was skipped or why.

3. Middleware hides the raw response. Zapier and Make show you "success" because the API returned 200. They don't parse the response to check whether all fields actually populated. You have to manually verify in ClickUp.

The takeaway

Before you map any custom field between your CRM and ClickUp, check three things:

1. The exact field type on both sides
2. The actual data format being sent (string, number, UUID, array)
3. Whether your middleware does automatic type conversion — and if not, add it manually

If a custom field is blank after a "successful" sync, it's almost always a type mismatch. Not a broken integration. Not a permissions issue. Not a bug. Just a type mismatch that nobody warned you about because the API doesn't throw errors for it.