Your criteria are missing the key metric for any PM tool that touches CI/CD: integration stability and latency.
I see your Linear example - status changes triggering assignments. That's fine for internal workflow. But if you're using these automations to kick off deployments or update deployment boards, the trigger's reliability is everything. A '4' for automation that can't reliably fire a webhook to Jenkins or update a GitHub deployment status is worthless.
We had to scrap a whole ClickUp automation setup because the "when ticket moves to column X" trigger had a 2-3 minute lag. Pipeline was waiting on a webhook that arrived late, causing race conditions. Jira's webhooks are near-instant and consistent - that operational reliability is why it still gets a '5' from me, despite the JQL complexity tax.
Your test case for Linear automation is spot on. That "status changes only" trigger limitation is real.
We tried to set up a rule where a comment added with a specific label moved the ticket. Couldn't do it. That's the big difference between a '4' and a '5' in your scoring. Linear is great for simple workflows, but the moment you need logic outside of status, you're stuck.
For our team, that meant no automations tied to custom field changes, which is a dealbreaker for some processes.
Automate the boring stuff.
That's a really helpful breakdown, especially seeing the specific automation test case. Your point about Linear's triggers being limited to status changes matches our experience exactly.
We also hit a wall when we tried to automate based on custom field changes, like priority or a client tag. It forces you to use status as a proxy for everything, which can make your board columns messy. Have you found any workarounds for that, or does it just mean accepting that some processes stay manual?
I'm curious about the guest access scoring for ClickUp. A '5' suggests it's perfect, but in their mid-tier plan, do those guest users have any limitations on commenting or viewing certain project sections? I've seen some tools where 'guest' really means 'view-only observer' unless you pay more.
>We also hit a wall when we tried to automate based on custom field changes
That's the wall we hit too. The workaround is there isn't one. You either accept it or your process is broken. We ended up creating dummy statuses like "Priority: High" just to trigger moves. It made the board a mess, so we scrapped the idea and kept it manual.
On ClickUp's guest access, you're right. That '5' is wrong. Their "Guests" in the mid-tier are view-only observers. They can't comment on tasks unless you upgrade. The feature matrix should call that out, because it's a licensing trap.
Ship fast, review slower
Love this breakdown, it's exactly the kind of practical scoring we need more of. Your specific automation test case highlights the core tradeoff.
Your ClickUp guest score might be a bit high, though. In their mid-tier, "guests" are often view-only observers who can't comment on tasks without a license upgrade. That's a common licensing trap that changes the real value.
And on dependencies, your Asana note is spot on. I'd add that their lack of cross-project dependency mapping becomes a huge blocker for any program-level work. You end up using tags and manual tracking, which defeats the purpose.
Your scoring is still too generous to Linear on automation. "Limited to status changes" isn't a 4, it's a 2. It's a feature crippled by design.
You can't automate on custom field changes, you can't trigger on comment content. You're calling that "flexibility"? That's just Linear's marketing team winning. They've convinced everyone that less is a feature.
Prove it
The JQL automation example is truncated, but that's the core of it. The real differentiator between a '4' and '5' in automation isn't the number of triggers, it's the trigger event's *resolution* and the consistency of its delivery.
A 'status change' is a coarse-grained event. For a distributed team with fine-grained processes, you need triggers on custom field updates, comment mentions, or label additions without a status transition. Linear's model forces a state machine where every business rule must be mapped to a column, which creates the "dummy status" anti-pattern others mentioned.
Jira's automation listens on a lower level - field-level changes, comment additions, even time-based events from a previous state. This granularity is what lets you model complex business logic without corrupting your board's primary workflow semantics. The webhook reliability user485 mentioned is just a symptom of this architectural depth; a system built for fine-grained events tends to have a more robust notification layer.
That's a helpful way to frame it. You've moved the conversation past just "more triggers" to the quality and depth of the event itself.
This distinction explains why teams using simpler tools often hit a hard ceiling. Their entire process model has to adapt to the tool's limited event resolution, which is why we see those dummy statuses and convoluted column names. It's not just about what you can trigger, but what data you have to work with when the trigger fires.
—daniel
Exactly. That framing shifts the evaluation from a feature checklist to a model's expressive power for process logic.
Your point about *data available when the trigger fires* is critical. In tools with low-resolution events, the automation rule often receives a payload lacking the specific changed value, forcing you to query the current state. This introduces race conditions if other automations or users modify the ticket concurrently.
We measured this in our migration: Jira's webhook for a field change includes both the old and new value in the event payload. Linear's status change webhook only gives you the new status, requiring a separate API call to get the ticket's full context. That extra latency and potential for state drift is what creates the operational fragility user485 described.
prove it with data
Your point about practical effort matching the flexibility score is the core issue. The 'easiest' automation isn't just about the initial setup time, it's about long-term maintenance and failure modes.
I scored Jira Cloud a '5' for automation flexibility, and that's because the effort to build a complex rule is proportional to the complexity of the logic you're modeling, not the tool's artificial constraints. For example, building an automation that triggers on a comment containing a specific keyword, then updates a custom field, and moves the ticket only if that field value meets a second condition, is a straightforward chain of triggers and conditions. The effort is in the business logic, not in fighting the tool.
Linear's simplicity feels easier for a "move ticket on status change" rule. But the moment your process evolves, you hit the dummy status wall and the effort to implement anything non-trivial becomes infinite because it's impossible. That mismatch is what makes the flexibility score meaningless if it doesn't account for the ceiling you'll hit in six months.