[Status: Not Planned] Cascade Custom Field "Value" from Folders/Projects to Sub Projects/Folders/Tasks
If we had a custom field that would cascade down it's VALUE to child tasks/sub-folders/projects, that would solve a few key challenges we run into.
Perhaps it's adding a Boolean setting called "cascade value" and then which items it cascades to is dependent upon what's been determined in the "Apply to:" section, just below that.
Here's a screenshot of the settings idea.
Just started working with Wrike, but this feature is extremely important! Wrike Sales maybe you want to have a look into this. A request dating back at least 6 years and not being picked up by Wrike. Not the best advertisement...
We are new to Wrike and I am spending hours trying to figure out workflow workarounds because custom field data from the project level will not populate into that project's tasks. I would very much like to see this feature on the list to be implemented.
Hi folks! Thank you for all the feedback. While there's no update to share at the moment, we'll keep an eye out for any changes and keep you posted. 🤝
Basudha Sakshyarika Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover
Basudha Sakshyarika Wrike Team member Become a Wrike expert with Wrike Discover
Hi, here to ask if this could be brought up again with the Wrike Product team. I have custom fields set up in an intake form. I would like the information that gets entered in to show up at the task level as well as the project level. I am using the same custom fields, so I am confused as to why they wouldn't show up. I would love a resolution here as it would remove lots of manual work for our project management team.
If I'm not mistaken, the ability for data in custom fields at the project level, to cascade to/populate at the task level is available through professional services.
Hi everyone, thanks for your continuous feedback. We are making sure it's forwarded to the responsible team for visibility. At this time, there are no new updates regarding this suggestion. If there are any improvements, I will be sure to post them here. Thanks again for your patience and understanding.
Rohan V Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover
Rohan V Wrike Team member Become a Wrike expert with Wrike Discover
I'm running into this issue myself — I'm trying to have the assignee from the parent task automatically inherited by its child tasks, but that doesn’t seem possible due to this limitation. Unfortunately, it sounds like there’s no current workaround. As someone who leads full-stack development teams, this feels like it should be a fairly straightforward feature to implement. Could you help clarify where the complexity lies?
Suggestion: a new type of Wrike Automation rule "IF [Custom Field X = empty] THEN [copy value from parent]". Would that take care of managing which custom field values get inherited?
(Crossposting https://help.wrike.com/hc/en-us/community/posts/115000313265/comments/32119162949143)
Tuomo Suominen How would items with multiple parents be handled?
Stephen Barnecut I would expect the automation to respect the item-subitem structure, e.g. the "Material (SAPID)" custom field in the screenshot below:
Adding a value to the "Material (SAPID)" custom field on the project's top level (row 1052) should apply it to every subitem. Editing a subitem's "Material (SAPID)" custom field after that should override the previous inheritance and cascade the new value to that subitem's children.
Tuomo Suominen I understand how it might work if there were only a single parent to each child item. I'm wondering how you propose it might work where a child item has more than one parent items.
Stephen Barnecut
I'm convinced every child item has only one logical parent item.
Maybe the Wrike team (Lisa?) could comment on the parent-child relationship and how crosstagging affects inheriting values from a system viewpoint?
Writing simply to voice my need for this feature as well! Our use case is we need the ability to group tasks (and other items) by Project Name, but Location doesn't fill the need when things are nested. The only option we've found is to have a custom field called Project Name, but it must be manually add to tasks. Would love if we could set the value on a Folder or Project and have it inherit to all sub-items
Rohan V Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover
Rohan V Wrike Team member Become a Wrike expert with Wrike Discover
Rohan V Thanks for your response. I appreciate the fundamental problem of there being a lack of a true "parent". FWIW, my suggestion is that the user should be able to turn parent status on or off for any item. If it's on, items tagged as belonging to this item can only be in this item. If there are items within the item which are also in other items when you turn parent status on, the user would be given the opportunity in a dialogue box to keep or remove those items. This approach would allow Wrike to continue to work as it does now, but also offer the user the opportunity to create areas of Wrike where items only have a single parent, and that parent can automatically pass values down to child items.
You’re welcome, Stephen Barnecut, and thank you for providing additional context. I’ve now forwarded your suggestion to the Product Team 👍
Rohan V Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover
Rohan V Wrike Team member Become a Wrike expert with Wrike Discover
Hi all, I am new to Wrike but have worked with many PPM systems and am pretty floored this function does not exist in either native settings or via automation (or even allowing of a limited cascade of automations); especially since this thread was opened in 2018, an eternity in tech. Our Wrike consultant pointed out that Custom Fields are the backbone of Wrike but the fact inheritance is only an option via manual updates seems like a massive oversight. Are there any other options for raising this issue to the Wrike Product teams' attention?
Hi Wrike Product team,
I just upvoted this request and wanted to add a comment: this feature would be a much-needed solution for us.
We need to group certain tasks and custom type items by a project number, project name, or another custom field that exists at the project level. Right now, these fields must be manually updated at the task level. This becomes a real challenge as new tasks are added and those updates are missed—leading to failed groupings when we run reports.
I understand the complexity of a “true parent” setup. But as a suggestion: could there be an option for a project parent to be marked as the “true parent” (chosen by the user)? If so, the custom field values from that true parent could be automatically mirrored to all child tasks/items under it.
Piling on here to say that we would benefit greatly from this, at least until our contract with Wrike expires. Would love to see a solution to this that doesn't involve scripting with APIs or other workarounds. Very surprised this feature isn't already included, especially since people have been asking for it for almost a decade.
+++ Adding my voice to this too - it would be fantastic to have this as a native feature, especially when using Request Forms to utilise blueprints/projects/etc without having to manually go and update the Custom Fields of all the subtasks every time would be super powerful.
If it helps, I have found good ways to do this using either Wrike Integrate or through the Wrike API if you don't have WI, so you might want to look at that if you're good with your coding and development!
We understand your sentiments, everyone, and thank you for sharing your honest feedback with us. Although we do not have any new updates to share at the moment, we continue to share every comment from this post with the Product Team. If we hear any news, we will be sure to share the update. Thanks again for your patience!
Rohan V Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover
Rohan V Wrike Team member Become a Wrike expert with Wrike Discover
I've mentioned this before, but the ability to cascade custom values has always been at the very top of my wish list. We really do need this feature. We love Wrike, but many of our solutions feel a bit “MacGyvered” to compensate for this obvious shortcoming. Please consider making this a priority.
The addition of this feature would allow us to solve a lot of information finding and dashboard problems that we are using manual entry to solve and is time consuming and includes risk of error in translation.
Please add this feature and cascade the information what is set in our 'project heads' to its tasks, so we can use this custom field information in the tasks automations, e.g. The problem will be: what is the 'master project' of a task, so the right 'head information' goes to the task..... Thank You !
Looking at the Product Feedback portal:
This request is currently #10 overall by votes (292).
It’s also the #6 request on the Backburner list by votes.
That ranking clearly shows how much customer demand there is. Wrike Product Team, please revisit this request for prioritization. It’s not just a “nice-to-have” - it’s a structural feature that would unlock a lot of efficiency and trust in Wrike for many of your customers.
This has been requested for a long time, and my team also would love to have this as a standard feature.
I'd take the ability to cascade data to subtasks over the AI integrations they keep pushing any day of the week :(
I'm running into this problem again. However, it's a complicated issue. I have several fields created when the project starts that I want to flow down to sub-tasks and sub-folders. However, we also have fields that we fill out during the project that we want to flow up to the project level.
Could Wrike create automations to allow this to occur?
Example:
Trigger: when custom field changes,
Action: Change the parent's (or child's) custom field value (same custom field) to the same thing.
This could result in recursive calls in projects with multiple levels, which would require a stop condition.
When cascading down the project (from parent to child), we need to specify which child requires the update.
There are still issues with this approach, but this feature is needed badly.
Hello,
Checking if any progress was made here.
The ability to cascade costume fields from the project level to the task level is important to us, and I didn't find any workaround that does not require manual work which is no-practical.