ClickUp Productivity Tactics That Break Then Start Working Again

1. Creating nested ClickUp views that do not stay saved

I spent a good chunk of last Tuesday filtering a ClickUp List view to show active bugs assigned to me, grouped by priority, with a nested sort by due date. Everything looked clean — until I navigated away and came back. The filters vanished. ClickUp just quietly reset the view but preserved the view’s name like a prank.

This isn’t just user error. If you save a view, then tweak a filter and forget to click “Save view,” ClickUp doesn’t warn you. It lets you believe the change persisted. Refreshing clears it. That same day, two other team members messaged me saying, “The Bugs-My View is broken again.”

Turns out, views you save from filtered templates sometimes revert depending on whether the parent List was duplicated using a public or private template. If the List was built from a private team space, saved views quietly disconnect from filter persistence logic. That’s not anywhere in ClickUp’s docs, but it showed up when I exported then re-imported to a blank space. The views snapped back to default.

It started working once I remade the view from scratch inside the space itself — not by duplicating. There’s some kind of anchor binding to the List’s UUID that doesn’t come through when copying embedded views. Inspecting exported JSONs from two Lists showed slightly different field alignment orders even with the same settings, which seems to matter for ClickUp’s renderer.

2. Using custom fields as conditional flags inside automations

I built a ClickUp automation to reassign cards when the status changed to “In Review” — but only if the custom field “Reviewer Assigned” was filled in. Seemed straightforward. Triggers: Status changes, Condition: Custom field not blank, Action: Reassign.

Except it fired even when that field was blank. The UI logic let me save the automation just fine. ClickUp didn’t warn me. I only caught the bug because I got tagged in a card and asked, “Why am I the reviewer for something with no code change?”

The fix wasn’t changing the condition — it was spacing. Literally. The field had been bulk-filled earlier via CSV import from Airtable, and for blank rows, the import tool inserted invisible whitespace. ClickUp sees those as not empty. There’s no visible sign in the UI unless you copy-paste the field value out and paste it into a string-linter.

One surprise workaround: You can use the dynamic value logic and check specifically for the string length using an automation condition like Custom Field - contains - "" and negate it. That’s less intuitive than a simple “is not blank” checkbox, but it caught the rogue whitespace. Also, if you toggle automation history logging via support (you have to beg them), you can see the actual evaluated value.

3. Getting ClickUp automations to update across linked tasks

Behavior here is inconsistent at best. If you create subtasks within a task and link other cards as dependencies, only the direct subtask chain reliably inherits automation updates. Tasks linked via relationship fields like “relates to” or “blocked by” don’t trigger automations unless they’re manually updated.

Multiple people on our team assumed that updating Task A’s status to “Blocked” would flag all its linked dependencies. That’s how it feels like it should work. But unless those dependencies exist as a true subtask or share the same parent folder, ClickUp treats those relations as passive references. No automations will fire.

I even tested it using Make to watch the status field of a task, then loop through all linked relationships and update them in batch. That worked better — but again, only if the relationship had been added via the UI. Links inserted via the API sometimes lacked metadata tags like link directionality or linkedIds array, so the task technically wasn’t “connected.”

If this bugs you too, here’s what actually updates reliably:

• Subtasks changing status when parent task changes — always works
• Parent task updating when all subtasks are closed — works with toggle enabled
• Shared folder automations applying across Lists — works, but only when copied with automations replicated (toggle that!)
• Relationship-type updates — usually don’t do anything unless manually scripted
• Webhooks for linked task changes — fire only from initiating task, not recipients

4. How ClickUp task templates overwrite existing field logic silently

I had a checklist template for bug triage that added sub-items, a due date three days from now, and custom priority level. One day, someone applied that template to an existing bug task and poof — 3 other custom fields became hidden. Tracked it down: the template didn’t include them, and ClickUp decided that meant “unset = delete.”

It appears that when you apply a task template, ClickUp doesn’t merge field presence. It overwrites the field schema of the task with whatever exists in the template’s DNA. So if the template was built in a Space that didn’t use certain fields, applying it cleanses the task down to whatever the template knows about.

Nowhere does the UI say this. When you click “Apply Template,” the only indication is a spinning icon and a micro toast “Template applied.” That toast is lying. It should say “Fields deleted, best of luck.”

This caused a regression in our sales handoff process — the salesperson would fill in Lead Score and Pipeline Stage, then someone else would add the task template and wipe both. Cue two confused Slack threads a week later.

To fix this: build templates from dummy tasks inside the same space where they’ll be used. That way, the Space’s field schema is automatically included. Bonus: ClickUp does seem to respect hidden fields if they’re in the Space schema but not present in the template — they remain untouched unless explicitly removed during template creation. Big difference.

5. Dashboards showing incorrect completion rates by filter type

I wanted a dashboard widget that showed completion rate of content tasks that were due this month. So I set a bar chart to count Tasks Completed vs. Open by Due Date — filtered to the current month. Sounds simple enough.

But my widget kept showing 0% completion — even though I’d finished five out of ten tasks. The culprit was the filter behavior: toggling to “Due Date: this month” hides all tasks marked Done unless their due date still falls in the month. And since marking it complete moves it out of visibility, those tasks disappear from both the numerator and denominator.

This is not a bug, apparently, just a very opinionated filtering engine. The completion stat literally means “percentage of remaining seen tasks marked complete,” not “percent of tasks due this month that were completed.”

I got around it by using a custom calculated field: I created a formula field on the task level to mark “OnTime = TRUE” if status was `Done` and `Due Date` was within X days of `Completed Date`. Then filtered the dashboard to count TRUEs instead. Wild workaround, but worked better than the default chart logic.

One chart I still don’t trust is the Pie widget for Time Tracked by Member — it groups entries by the current visible filtered task list, so if someone logs time on a bug task not in the dashboard’s folder view, they show as having worked zero hours. You have to include an unfiltered data source just to avoid undercounting.

6. The ClickUp Chrome extension blocks Notion embeds from rendering

This one caught me completely off guard. I had a Notion doc that embedded a ClickUp task via public link for reference. But whenever I opened the doc in Chrome, the embed grid would be blank and quickly flash an OAuth prompt. Reloading would cause it to vanish entirely.

Turned out it wasn’t Notion misbehaving — it was the ClickUp Chrome extension. If you’re logged into multiple Google accounts and also running the ClickUp extension, it injects authentication headers into iframe requests that break expected behavior inside Notion. I only figured this out after launching DevTools and watching the iframe errors — 403, invalid referer.

Disabling the extension made Notion embeds reappear instantly. The ClickUp embed script still runs (because it’s inside an iframe), but the Chrome extension tries to intercept and throws auth noise into the request headers. None of this shows up unless you’re running extensions in debug mode.

No reliable way around this other than disabling the extension for Notion pages or opening Notion in a clean profile. I reported it and got back a standard email suggesting I clear cookies. Yeah, not the issue.

7. Why task dependencies sometimes don’t block anything at all

A team member created two tasks: “Write Proposal” and “Send Proposal.” Linked them using ClickUp’s dependency: task A must be completed before task B can start. Everything looked fine.

But she was still able to change the status on “Send Proposal” to In Progress without completing the first one. ClickUp gave no warning, no pop-up, just allowed it. This happens when the dependency logic is present, but the workflow settings allow status changes regardless.

You have to enable the “prevent status change if blocked” toggle inside the workspace settings — and it’s off by default. Even with dependencies marked as blocking, none of the protection logic fires unless that workflow setting is flipped on manually.

Aha moment here was discovering hidden modal settings under “Advanced Workflow” — and realizing they apply globally, not just on a per-space basis. We had assumed each space inherited its own rules. Nope, it’s flat across the workspace, and there’s no override per folder or List. That mismatch caused more than one team to skip requirements they thought were enforced.

If you’re managing several client spaces in the same account, make sure you communicate this or you’ll end up with a sequence that visually implies logic that isn’t actually enforced.