When ClickUp and Notion Both Break and You Still Need a Plan

1. Why Notion Databases Turn Into Bottlenecks Faster Than You Think

Notion feels like home base until you’re juggling more than a few clients, each with their own SOPs, copy requests, export formats, and weird platform quirks. I had a freelance design project where I kept track of feedback rounds with a fairly basic Notion database—four views, a few filters, a status dropdown. Until the client started dropping in random Loom links and off-platform tasks, and suddenly the whole setup collapsed under the weight of its own clever views.

There’s this moment where you’re adding a new filter condition and realize you’re not even sure what you’re filtering for anymore. Notion lets you generate all kinds of properties—checkboxes, rollups, relations—but half the time you’re just making up structure for work that doesn’t fit. Freelancers don’t get tidy WRs or nice Jira cards. They get back-to-back DMs, PDFs from seven months ago, and misaligned comments.

The core flaw: when you connect multiple databases (e.g. linking a “Clients” DB with a “Deliverables” DB), Notion sometimes delays the rollup field propagation. You’ll update a status in the Deliverables DB, but the summary rollup in the Clients DB just…doesn’t reflect the change for like 30 seconds. No error. Nothing in the UI. You’re just sitting there refreshing and second-guessing your own logic.

Also fun: if you duplicate a database and forget to relink templates or conditional rollups, they silently break. Feels like it should throw an error, but nope—it’ll just pretend those filters work while quietly returning null results.

“Try duplicating your entire task system, relinking all rollups manually, and then realizing your Status filter is pulling from the old database—because Notion duplicated the internal DB ID but didn’t update the rollup source field. Zapier integration? Out to lunch.”

2. When ClickUp Automations Fire and Then Just Forget to Update

ClickUp looks organized until you push automation beyond to-do-list territory. I had a pretty clean setup to track blog post writing for four clients: blog title, due date, word count target, assigned writer. There was even a neat little template task that auto-filled subtasks for researching, drafting, editing, and client feedback.

And then I added a rule: “When status changes to ‘Feedback Received,’ automatically assign the ‘Revise’ subtask to the original assignee.” On paper—great. In reality—ClickUp decided that if one user ever unassigned themselves from the main task, that automation collapsed. It ran, but the field stayed blank.

There’s no logging console inside ClickUp to tell you what fired and failed. You get a single green checkmark next to the automation config, and that’s pretty much it unless you set up a Slack integration to prove it happened.

Workaround that should have worked but didn’t

I tried layering in logic like “if assignee is not blank, assign subtasks to assignee.” That condition straight-up doesn’t evaluate against internal subtasks—it’s only looking at parent tasks. Again, no error. Just bland indifference from ClickUp.

Eventually I had to refactor the entire system to use a Make.com scenario that pulls task data via API, stores the active writer’s email, and then assigns that back via a PATCH request. Wish I was kidding.

ClickUp automation tip list (learned the loud way)

• Avoid chaining more than two update actions off the same trigger
• Never assume subtask logic inherits task parent filters—check explicitly
• Multiselect task fields don’t reliably trigger automations on every change
• Custom fields with spaces in the name break most API calls unless escaped
• Audit your automations with a dummy task per week to verify they still work

3. When Zapier Tries to Help and Actually Duplicates Your Tasks

This one still annoys me. I had a Zap set up to catch new Airtable form submissions, run a quick OpenAI draft input using the submitted copywriting brief, and then create a new ClickUp task in a specific content list. That worked… until it didn’t.

Somewhere in late March, I noticed tasks were appearing twice. Sometimes instantly. Other times with a 10-minute lag. I checked for duplicate Zaps—nope. Turned off all but the main one. Still happened. Dug into the task history. Turns out the webhook Zap was re-firing if the Airtable view was filtered and then reset due to a manual field edit. Huh?

In Airtable, if you have an automation watching for new records in view, and a collaborator re-edits the form-linked table (even if the record was already processed), it can reintroduce the record into the view and fire the Zap again. Nothing marks it as already processed unless you manually add a “Zapped?” checkbox or timestamp it as handled.

“One click inside Airtable, and your task gets cloned into ClickUp like some kind of productivity hydra.”

The fix was stupid: I had to edit the view filter to include a Date Added field that was automatically marked on form submission, and then set a 5-minute buffer to ensure only truly new records made it in. Bonus: had to rebuild the ClickUp task-creation step from raw JSON to dodge the Zapier field mapping bug that blanked subtasks if the ClickUp list’s template changed midweek. Yeah.

4. The Case Against All-in-One Work OS Tools Trying to Be Everything

The pitch is always the same: “Consolidate tools, get visibility, work smarter.” But when everything funnels into one god-view—especially as a solo or small-team freelancer—it gets clogged fast. Notion, ClickUp, Coda, even Airtable start to treat your workflow as a schema first, and a lived thing second.

I had a client using Coda to run influencer proposals, payment tracking, campaign briefing, asset reviews, and reporting—all in one doc. Felt slick at first. Then the doc grew massive. Page loads lagged. Buttons started returning silent fails. Lookup columns couldn’t maintain stable mappings across table duplicates.

The most cryptic thing: if you copy a table and forget to turn off “sync with source,” the new table inherits half its formulas, but doesn’t throw an error when they reference undefined columns. No UI warning. Just #Blank cells and vibes.

You don’t notice it until someone goes, “Hey, why didn’t we pay Kaela?”

Functional tradeoffs that stack up

• Views meant for sorting get used for status tracking, leading to missed updates
• Button automations require full context load before triggering, introducing race conditions
• Scheduler integrations (e.g. Google Calendar push) drop events when fields silently null
• Versioned tables rarely inherit logic cleanly; expect redo loops
• Collaborators often break formulas by dragging rows around assuming spreadsheet rules apply

5. Why Real-Time Collaboration Tools Drift From Actual Use Cases

One of the weirdest user behaviors I’ve seen across Work OS platforms is the slow collapse of collaboration in tools meant to improve collaboration. You start out sharing a board or dashboard. Everyone’s active. Then someone makes a comment on a page referencing a field that doesn’t exist anymore, and no one notices. Or a teammate updates a ClickUp task but doesn’t realize the dependency was hidden behind a folded view.

Even with notifications on, most freelancers I’ve worked with aren’t in-platform 24/7, so they treat these systems like async snapshots. By the time they engage, the structure’s out of sync. Real people using synced platforms don’t click every view or open every dropdown. They skim what’s loadable and close out.

Example: A Notion dashboard tracking client work. Each client has a folder, and each folder contains a link to weekly tasks. Except the links are filtered views inside the main database, and if you reorder columns or update the sort criteria globally, those links start showing blank—because Notion inherit filters but override sorts inconsistently.

End users just think “the task list is broken.” And they start Google Doc-ing stuff again. Can’t blame them.

6. Using Make and n8n to Handle What Work OS Tools Cannot

I finally gave up and started piping everything through Make.com. Or n8n.io if I really need to wrestle with conditional branches. It sounds heavier, but for anything involving multi-client task routing + AI + timestamp logging, there’s just no good in-app solution inside most Work OS tools.

One automation that saved my week: Grab a new Airtable form submission, pass it through OpenAI for first-draft generation, use Make to convert that into a rich ClickUp task (with subtasks populated via a template), and push the client ID back into Airtable so it knows it’s been handled. All tied together with labeled error-catching so I can see where stuff breaks.

AHA moment: Make lets you delay any step based on a retrieval trigger. So I now wait until a ClickUp task URL is available, then inject it into the OpenAI output, so the client sees: “Here’s your draft: .” Before, it used to send them to a dead placeholder with brackets because ClickUp ran slow. Little change—huge difference in how professional it looks.

Another weird advantage: Make doesn’t care about Notion’s internal database IDs the way Zapier does. When duplicating Notion databases and updating workflows, I can soft-reference the DB title name instead of some impossible-to-locate field pointer. Way less brittle.

7. Real Limits of Using Work OS Platforms for Freelance Management

The thing most of these platforms don’t acknowledge: freelancers work in uncertainty. Their next gig may not align with their current system. Half your logic breaks when you take on a contract that uses Basecamp or Asana instead. Or the format of deliverables changes, and now half your templated subtasks don’t apply.

Work OS tools aren’t bad. But they wear out fast. After maybe three or four use-case pivots, your Notion or ClickUp or Coda setup starts holding old assumptions. You get system rust. Adjusting it feels like open-heart surgery. Deleting one automation breaks five others. Onboarding new collaborators takes an entire walkthrough video they won’t watch.

At some point you Google “is ClickUp down” while staring at a task labeled ‘was this done?’ that was auto-created four times from a broken webhook and you can’t tell which one is real. That’s about the moment you reconsider everything.