Monday has updated dependency column with multiple features(Dependency) and one of them is the dependency type that can be set for each relationship. My question is when dependencies are created by the api it is possible to pass the type argument along as well?
Hi @Matias.Monday , we had an integration setup for a customer to have dependencies in a board and since how the behavior has changed by monday.com the it is not meeting customers requirement. What is the way around this? Since the functionality is introduced it means that the internal api’s support these parameters and only they are not exposed via graphql api. Why hasn’t monday.com think of external integrations getting affected due to new functionality. Changes shouldn’t break existing functionality.
If you would be able to send us this information with the mutation you were using and how said mutation is failing now to email@example.com we will be glad to take a look into it and raise the matter to the team involved in the change.
I have this same issue. I built a scenario in Make involving dependencies. It took me a long time because I am not a programmer and learned from scratch. While I love the addition of new dependency types, not being able to differentiate them in Make renders my scenario useless now because it was built for finish to start dependencies. When the web hook is sent resulting from a change in the dependent_on column, there is data sent indicating the dependency_type (0,1,2,3). But this is the only time I can see this information. It seems like this would be an easy thing to provide when listing the board’s items or getting info on a single item so I can map them in my scenario. I do not need to mutate, just query for my purposes. It may seem like a small thing but not being able to see the dependency_type has completely disrupted my small business which I was building around Monday.com.
This one really caught my client off-guard. I’d like to echo the comments of others in recommending caution over rolling out and some additional planning, as well as of course API support and legacy support.
The function of the new dependency column is in fact so different that I would advise maintaining it as a separate column and continuing support for the legacy column for at least a decent period of time. Otherwise the transition would be too drastic. I am nervous about how this will affect other clients who are heavily dependent on their dependencies and related integrations.
My addition to this question relates to lag time. Since we can no longer update dates directly with strict dependencies, can we modify lag days through the API?
A major frustration is that we cannot modify lag days with automations and date related automations are kaput.