Comparing Project Management Tools When Features Do Not Match

1. Cross-assigned subtasks behave differently in Asana versus ClickUp

In Asana, you can assign a subtask to multiple people, but it doesn’t roll up into the parent task’s timeline or workload view unless you manually link it. ClickUp, on the other hand, lets you multi-assign tasks a little more cleanly—until you realize that updates made by one user silently overwrite others’ changes unless they’re commenting instead of editing the description directly. One day I thought a teammate was ignoring an update only to discover ClickUp had replaced his edit with mine… silently. He was pissed. I was confused. Now we comment everything to be safe.

Also worth mentioning: Asana’s recurring tasks don’t play well with subtasks. A recurring parent task will duplicate every time, but the subtasks aren’t guaranteed to copy unless you open them and toggle them to recur individually. That’s not documented anywhere — I just noticed after realizing subtask #3 never showed up again after a Friday ritual checklist reset. Fun times.

• In Asana, subtasks won’t auto-show on timeline views — you have to manually promote them to project level
• ClickUp can show subtasks inline or nested, but filtering them is clunky unless you use advanced filters
• Multi-assignee updates in ClickUp aren’t tracked per user — version overwrite risk is high
• Asana’s Rules ignore subtask triggers unless you add a premium-level workaround
• You can’t convert subtasks to tasks via CSV import/export cleanly in either tool

The aha moment came after I tested a zap mapping Asana updates into Slack and realized subtasks weren’t sending any events unless I assigned them directly — so they were ghosting my automation entirely.

2. Monday dot com automations cannot react to item status changes reliably

This happened mid-migration during a team switch: we were mapping Monday columns to Slack message triggers, expecting status changes (like “Needs Review” to “In Progress”) to reliably fire automations. No dice. Turns out the automation won’t trigger if multiple status pulses change at once — like if a user drags a whole item instead of using the dropdowns. One click = no event.

Worse: if you have a “Status” column duplicated (maybe one for design status and one for PM status), Monday’s automation builder can’t consistently distinguish between them. You’ll think “when status changes to XYZ” refers to column A, but it may actually trigger on column B without warning. I only caught this when our QA label randomly fired the dev alert flow — triggered from QA’s field, not dev’s.

The workaround is naming every status column with obnoxiously specific names (“PM-Status”, “ENG-Handoff”), then referencing those names precisely in your automation filter. It’s not elegant, but it stops the ghost triggers.

Undocumented edge case:

“If a status column is hidden in board view, it won’t trigger automations tied to it — even if values are updated via API or integrations.”

Found that one the hard way during a board cleanup while trying to make it prettier for demo day. Oops.

3. Notion task databases fail silently when filtering by team members

I’ve used Notion project boards for maybe two years. It’s fine for solo workflows but buckles hard as soon as actual teams need visibility on filtered views. If you try to filter a task database by current user, it sometimes just shows nothing — even when tasks exist — unless the user created the entry themselves. That broke our review view for freelance editors completely.

There’s no error. No blank-loading message. Just an empty board that made us wonder whether anyone had submitted anything. They had. Notion just considered the @mentions different from “Assigned to” person fields because the original template used two different properties for people. So I rebuilt the whole database with merged properties. Painful.

The kicker: once I rebuilt it, I had to re-share each new property manually so automations still worked with Make and our calendar sync. Notion’s API still treats rollups inconsistently when people properties are involved — you can’t filter by a person inside a rollup. No fix for that yet.

4. Airtable’s sync views are brittle when permission levels differ

One surprising failure: I had a base set up for client projects with a team-wide calendar linked across three views. When I shared a sync view to another workspace, it appeared fine for me… but half the team only saw blank records. Because some linked fields were restricted, Airtable just trimmed the data entirely for them — no warning, no error, just silently removed fields from their synced view.

I spent a full hour assuming someone had wiped records in the original. Nope. Permissions quietly filter synced rows.

If you plan on using Airtable’s sync to distribute project dashboards across teams, make sure everyone has full access to all linked fields or everything gets neutered. The workaround is duplicating fields and flattening the relationships, which defeats the point of building a relational IDE-style doc in the first place.

Also noticed if a field is renamed in the source base, it won’t rename in the synced base. You’ll think everything maps, but columns will mismatch silently until a record fails to populate entirely — which can nuke prefilled form links.

5. Trello’s Power-Ups randomly disconnect when boards are moved

If you’re using Trello’s Butler automations or any Power-Ups, be very careful moving a board from one Workspace to another. I moved a testing board into our client workspace and suddenly every Button stopped working. Turns out moving a board resets its link to certain Power-Ups — especially Calendar and Card Repeater — without reauth prompts.

It’s not listed anywhere on the Butler FAQs, but the automation connections break unless you visit each automation and re-save it manually post-move. Once I re-saved each rule, the triggers started firing again. No logs. No rollback. You just have to re-click.

This is especially nasty if you use archived rule backups thinking you can restore later — the restored automations assume the board ID hasn’t changed. But it does. So the archive restores blank rules tied to a dead board ID.

The failure state? Tasks won’t repeat anymore, but the UI still shows the automation as active. Love that.

6. Coda’s collaborative timelines break when users edit filters mid-view

One nice thing about Coda: you can build super flexible Gantt-style project timelines with filtered views for everyone. Except… those filters are not persistent per user by default. Which means one person filtering the timeline view instantly affects everyone else. Our sales lead was filtering by Q2 deadlines, and marketing was working off weekly views — they kept flip-flopping live.

There is a team-based workaround by using “control” drop-downs at the top of the doc and linking views to those controls. But it’s clunky, and you have to teach everyone not to click the main filter. Otherwise filters reset globally across editors.

“There is no way to lock filtered views per user unless you duplicate the view for each person manually.”

Found that nugget after digging through the forums. Not ideal for teams rotating across projects weekly.

7. Make scenarios timeout unpredictably on webhook watch triggers

I built a multi-step Make scenario that triggered off a webhook hit and ran a catch-webhook module, a JSON iterator, a few filters, and an Airtable update. It worked maybe 9 out of 10 times. Then I added one extra field to the Airtable schema… and half the triggers just stopped firing. Make would show the webhook was received, but the immediate next module would silently time out after 20 seconds.

No error. No logs past the webhook. It just paused.

The fix? Moving the iterator module to come before any conditional filters helped — apparently a large payload hitting filters before parsing can exceed hidden limits in Make’s webhook buffer. They don’t mention this anywhere in the docs.

I ended up splitting the scenario into two branches: one handles parsing and filtering from the webhook, and a second completely separate scenario takes a pre-parsed payload and updates Airtable. The extra hop gave the system room to breathe, even though it felt inefficient.

Also learned: Make will reuse webhook URLs unless you explicitly regenerate them between scenario clones. So if you duplicate a scenario and think it has its own webhook, double check. I learned that after watching the wrong scenario get triggered after a Zapier inbound event.