I’m exploring ways to improve automation between main items and subitems. Currently, subitems can influence main items, but main items cannot influence subitems, not even in the simplest case without conditions (“Only if”). This limitation reduces workflow flexibility, especially in Kanban boards, where moving a main item could ideally update subitems automatically. Without this, we need multiple separate automations, which quickly becomes complex and hard to manage.
What are you trying to achieve
I’d like an automation that works like this:
“When Item Status changes to , and only if Subitem Status is [Y], then set Subitem Status to [Z].”
This would allow main items to influence subitems both in the basic case and conditionally (“Only if”), keeping workflows consistent and reducing the need for redundant automations.
@Margoth Hi Martina, since this isn’t supported natively at the moment. However, if you’re open to using a third-party solution, you could explore no-code automation platforms like Make or Zapier, which can handle this type of logic.
Daniel from Fantasy Media team. Great question — this is a very common pain point.
We developed an app called Subitem Automations that provides robust automation capabilities to subitems to solve for most (if not all) of the gaps in the native automations.
It lets you trigger automations from the parent item to subitems, including conditional logic like “only if”.
Hi everyone, quick update from my side after re-testing the automation.
The app works very well for several scenarios, but I’ve noticed a couple of limitations compared to what I was originally asking in this post:
the automation doesn’t set a specific target status when another status changes; it copies the current value of the source status
regarding the “only if” condition: it doesn’t work with default / empty status labels, even though the default label can be selected in the setup (the team is currently investigating this behavior).
Overall, it’s a solid solution, and I’m making the best use of it, though these aspects make it less suitable for a rule-based status transition use case like mine.
Thanks again to the team for their availability and support. I’ll update this thread if there are further developments.
