Project management

ClickUp has a field for everything, which is exactly why nobody agrees on what goes where

ClickUp's pitch is that it replaces every other tool, and the hierarchy shows it: spaces contain folders, folders contain lists, lists contain tasks, and a task can have its own custom fields, a custom task ID, subtasks and a dozen view types on top. Almost anything a team wants to track has a place to go.

Which is also the problem the moment two teams set it up differently. A "client" field is a custom field of type text in one space and a relationship to a whole other list in another, and a task ID that looks stable — PROJ-142 — is only stable if nobody reconfigures the custom ID prefix for that space later.

  • Spaces, folders, lists and custom fields, mapped per level
  • Custom task IDs handled as their own case
  • From €1,700 plus service fees
The tool

What ClickUp is, and why its hierarchy is the whole story

ClickUp organises everything into spaces, which contain folders, which contain lists, which contain tasks, which can contain subtasks. Custom fields — text, dropdown, a relationship to another list, a formula — get defined per space or per list, so the same field name can mean different things in different parts of the same account. Custom task IDs give tasks a readable reference like DEV-142, convenient until the prefix is changed and old references stop matching new ones.

Its API is a documented REST API structured around that same hierarchy — reading a task usually means knowing which list it lives in, not just its ID. ClickUp also ships many native automations of its own, so the first question on any project is whether those already do what is being asked for.

What goes wrong

Three things that go wrong around a ClickUp hierarchy

All three trace back to the same cause: the hierarchy makes anything possible, which means nothing is standard, which means an integration has to be built against your specific setup rather than ClickUp in general.

A lead form fills three different custom fields depending who set up the list

Two sales lists in the same workspace both track "deal value", one as a number field, one as a formula, and one as a dropdown of ranges because someone thought exact numbers were not needed. A form that creates tasks across both lists has to know which is which, or it writes a number into a field expecting a dropdown option and the task looks broken.

What you see instead

We map custom fields per list explicitly before anything writes to it, and a form or an integration only ever targets lists whose fields have been checked, not a whole space at once.

A custom task ID prefix changes, and every stored reference goes stale

Somebody reorganises a space and changes the custom ID prefix from DEV to ENG for clarity. Every reference to a task stored outside ClickUp — an email thread, a spreadsheet, another system's notes — now points at an ID format that no longer exists, and nobody flagged the change as risky.

What you see instead

We store ClickUp's internal task ID as the real key in anything we build, and treat the custom ID as a display convenience — so a prefix change is cosmetic, not a broken reference.

A status that exists in one list does not exist in the next one

ClickUp lets each list define its own statuses, so "In Review" exists on the design list and not the development one, which has "Code Review" instead. An automation written against one list's exact status names quietly does nothing on the next list, because the string it is looking for simply does not exist there.

What you see instead

We work off status categories — to do, in progress, done — rather than exact names wherever the logic allows, so a connection keeps working when a list uses its own status labels.

The bill for doing it by hand

What an unmapped ClickUp hierarchy costs you

Most of the cost here is not retyping, it is troubleshooting. When a form or a report breaks because a list's fields do not match what was assumed, finding the actual cause — which list, which field, which status — routinely takes longer than building the fix, because the hierarchy that made ClickUp flexible also makes the fault hard to locate.

The other cost is quieter: teams that give up on cross-list reporting because it keeps needing rework, and go back to a person manually checking three lists and writing a summary — the exact manual work a connection was meant to remove, recreated on top of a partially working one.

What we build

We build the thing on the other end too

With ClickUp the honest first step is often mapping the hierarchy itself before any connection is built, because a quote against an unmapped set of spaces is a guess dressed up as a number.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What can be connected between ClickUp and the rest of your stack

Every row assumes the specific space, folder and list have already been mapped — ClickUp has no global schema to connect against, only the one your team actually built.

  • Website or intake forms as new tasks

    A form submission becomes a task in the right list with its custom fields already filled — client name, priority, source — instead of someone reading an email and building it by hand.

  • A status category change pushed out

    A task moving into the done category triggers a customer email, a Slack message or a status update elsewhere, matched on category rather than a list's exact status name so it survives a relabelling.

  • Tasks kept level with a CRM's deals or a helpdesk

    Tasks mirrored with deals in HubSpot or Pipedrive, or tickets in a helpdesk tool, matched on ClickUp's internal task ID so a custom ID prefix change never breaks the link.

  • Time tracked on a task into invoicing

    Time logged against a task, summed per client or per list, passed to an accounting package as billable lines instead of reconstructed from memory at invoicing time.

  • Cross-list status onto a single dashboard

    Task counts and status, read from several lists at once and normalised onto status categories, so one dashboard tells the truth about a project spread across folders that track it differently.

Rows one and two are the usual starting pair; the cross-list dashboard tends to come later, once the mapping underneath it has proven stable.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

More about system integrations at JKC

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

For ClickUp specifically: the price moves more with how many spaces and lists are in scope than with the platform itself, because each one can carry its own field structure that has to be checked rather than assumed.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Frequently asked questions about connecting ClickUp

Where ClickUp's native automations reach — moving a task, assigning someone, setting a field when a trigger fires inside ClickUp — we use them, because they cost nothing extra to build and ClickUp maintains them. The API and webhooks come in the moment the target is outside ClickUp: your website, your accounting package, a system with no native recipe, and most projects end up using both.

Often next to this one

Tools that often sit next to this one

Almost nobody connects one tool. These are the ones that come up in the same conversation, either because they sit in the same part of the business or because people ask for the two together.

See all integrations

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.

Do the free Growth Scan