Hi,
I’d like to take up one issue from a post a long time ago, and make a strong (IMO) case for it.
Fact is: While linking one table to another (A=>B), the reverse link column (B=>A) is always automagically created and maintained. I assume that’s how Seatable works internally anyway.
As stated in my former post: Why does this not happen when a link column is linking to the same table. Expecially since a lot of new features (Org Chart and Hierarchy plugins) rely on table-internal links?
But such general considerations apart, my actual use case should explain why this would be a game changer:
We have a plain list of projects. A lot of them (>1.000). They contain a link column which basically means “depends on”, linking each project to 1-n others which they need as a basis. Thus, we want to achieve a higher level of planning transparency: A single project may look unimportant if it is viewed separately. But is gains importance when we can see that n other projects depend on that one projects. These relationship are often overlooked.
Here’s the catch: the Definition of the relationsship is done in the direction from the depending project’s view: Every project manager knows which other projects he depends on.
However, the important information lies in the other direction: not “A depends on project B” is interesting, but “B is the basis for projects A, C, R, P, H, X”. And in Seatable terms, that would be the reverse link within the same table. If I had this, I could do countlinks, rollups etc.
We tried almost everything:
- Asked project managers to create the reverse link manually. Won’t happen, or creates a lot of mistakes
- Used scripts or n8n automations. They work, but need to be triggered, are not robust, and often do not update in real time
- Used a very complicated, automation-based “create link” action with 12 help columns. Works, but messy and unreliable
So here’s the question: If it’s already possible in table-to-table-links to create and maintain the opposite direction, what keeps you from implementing this in the same table? I guess that it’s a bit more difficult for the user to understand (erase one column, change the other one at the same time). but nevertheless …
Thanks for listening,
Arndt
