Dependencies in groups are duplicated absolut and not relative!

Hi,

I have created a very big group with 43 pulses and 12 dependencies colums and 16 automations of these dependencies. All works fine in this group.
Then I duplicated this group 8 times, because I have 8 episodes of a TV series to plan.
When I change a status in the first/initial group, then also the status of the dependencies in the other groups change. So all dependencies in the other groups refer to the first group.
That’s a very big problem!
I would have to adjust all dependencies in 43 pulses and 7 groups by hand. That would be a real pain.
Isn’t is possible that the dependencies in duplicated groups only work inside their group. So the dependency has to change, if I duplicate the group.

Thanks for the help,

Best Michael

2 Likes

+1 for me. The same for linked column, when duplication board the link column in the duplicated board always link to the original linked board.

This is really important! Same issue for links!!!

We have a series of maintenance steps on every new board set-up and it’s too much for some users. We also cannot really secure them out of using a template, and let them still set up their own personal boards, so we are stuck with some manual pain points like thise.

Hi @straister! Thanks for posting about this - I want to be sure I fully understand your pain points. Do you mind expanding a bit on this? Were you duplicating a group with dependencies and the dependent tasks were still linked to the original group? Or something else? I’d love to pass this onward to our automations team - feel free to add screenshots of easier too :slight_smile: I look forward to hearing from you! Cheers!

Hi @lauraglev -
The situation is that we can’t assign work to our clients (directly) using a people column, unless they are subscribed to the board. We don’t want clients to engage on our boards at this time, so we created a Client Contact Board (per client), which links to our Client Project and Client Support boards, giving us a column we call “Client Assignee”.

Whenever we create a new board from a template - we have the template Project or Support Board linked to the Client Contact board template, and there’s a maintenance step to update that - which our ops team knows to resolve. Because we can’t lock down templates from general use, there’s a strong possibility that users create their own “client” boards - of any type, and do not know to update/maintain the linked columns. This is more of a case for locking down templates than anything else at this moment! Perhaps on the wrong thread, now that I’m further explaining! Sorry! :stuck_out_tongue:

Hi @Mischmaster! You make a great point here and it’s something I’ve brought to our developers attention to see if we can improve this with our dependencies. I might suggest creating a board template with the dependencies set up and then using the board template to set up each episode. You can then combine these boards into 1 board by moving the group. This is definitely cumbersome and not an ideal way to work but as a workaround for now, it should help ease this pain point. Would love to hear your thoughts! Cheers!

1 Like

Laura, as a new Monday.com user this was one of the first “showstopper” issues we ran into when duplicating our projects (Groups). The duplicated Group not only retains the dependency links to the original Group, but trying to “fix” this by editing the Tasks in the new Group will re-assign the tasks from the original Group into the new one, so often both Groups end up a complete mess. This is a huge deal for our team that if not fixed, will likely result in switching to another tool.

2 Likes

This might be a show stopper for us, too. Way more functionality than Microsoft Planner (which we currently use), but if we can’t get away from the manual re-creation of dependencies, we may not be able to go with this platform.

1 Like

@lauraglev any update on getting resolution to this issue? Duplicating groups and keeping dependencies within the new group, rather than retaining link to the original group is a must.

1 Like

Hi @jlaird - Melissa here from the support team! I just reached out to our product team regarding an update on this. To be transparent, they have not assigned a timeline to this yet, but I’ve shared the feedback from this thread with all of them.

In the meantime, the best workaround for this issue is to duplicate the board where you have your dependencies set up to ensure they work as intended for the new information. We will continue to share updates as we have them - thanks for checking back in :slight_smile:

Another issue with duplicating. Sub-items are not duplicated whether board or group… any plans to change this?

Hey @jlaird - thanks for this question! Yes, this is on our roadmap :slight_smile: You can check out all of the subitem developments our team is working on here: https://view.monday.com/480751376-c22b2fe6c069076f55f20289b4d3f04f

2 Likes

How do I have an item added to this roadmap? Currently subitem dependencies can only be with other subitems… need to be able to set dependency on parent items. In general, need subitems to behave like parent items in all ways.

@jlaird - the road map is created by our team, but heavily based on feedback from our users. I’ve been sure to share the community feedback on this topic with our team, and they will continue to add updates to the road map!

You might suggest this but in my case it doesn’t seem to work. The duplicate boards dependencies are still linked to the original group on, on the original board.