Here is my concern, lets see if someone has the same problem
I’m making a coda workspace for project tracking and resource allocation.
based on the information I wanna people work with I made this structure of documents:
parameters (I set a DATES table to use in a normalized way in all the docs, a profile table and other)
resources (people table and people table by date where I have rows per people and per dates as a lookup column from DATES they worked with us linked with dates table in parameters)
projects (project table with project and the people that worked in each one, of course, linked with DATES table as a lookup column from parameters document)
What’s the problem? When I link the DATES table from parameters document in projects document I supposed I’m using the same table that I’m using in resources… but NO! the row “date” in the linked table resources in projects is grey and telling me that the table does not exist…
The only workaround I found with coda’s team help was to add the dates table from resources also in projects document… with that the dates are ok in linked resources table but… are not the same “entities” in order to filter or compare them between the data points comming from table dates comming from parameters and table dates comming from resources!!
Some idea about how to fix this or if it is a schema problem ?
Thanks for your answer and sorry about the description of the problem without the dummy! here it is:
I have a document with “parameters” like this one with seniority… I want seniority to be the same source in all my docs and always talk about the same “entity”
like:
Also I Have persons table in other document
And at the end projects that will be done by persons in a third document… (and this is because data access restriction of some data in some tables and department organization, because without that the trick could be put all this information in different sections in the same document)
As you can see in projects the column seniority is telling me that that table does not exists, that means also that I canno write any expression with that information or access the rest of data of that rows on that table.
The only solution that I have is to link again the table parameters in projects but comming not from parameters but from persons… I don’t like this because breaks all all I mean, the data restriction and also the order and the idea to have only one place in all the organization with the entity “Sr”…
As far as I can see when playing around, the Seniortiy level comes along and works as expected, the only change I made is the lookup to be a single select, but this has nothing to do with your concern, at least I think so.
Not sure, but I notices that like in my browser “Brave” the best is to switch off ALL the shields, like linked sites. Maybe you should check in your browser too.
Let’s see also the experience / advice form other users
When you’re using Cross-doc, there is an original doc and then a table is synced to a new doc. The table in this new doc is treated more like a new table than a wired extension of the original table. With a three doc setup, you end up with an original doc with the original table, then for each of the two new docs, they will essentially have their own copy of the original, but will not know that they are both from the same original.
If you have variables you need to link into other docs and you need to keep them linked together, you need to keep all starting variables in the same doc. I wouldn’t suggest “chaining” cross-doc tables.
the problem with that is that depending on how crossed you have the docs (my model is more complex than only three chained… I’m using the people table for projects, for licences, for salaries,etc, etc, etc) you need to start doing copies of each one in each document… and the worst thing on that is that they values are not comparable or at least I didn’t find how to threat them as the same entitie… when I compare in projects people.seniority with other table that has the link to a “copied” table to mantain the new original from the second ones values are not the same and the result of the formulas are false…
Probably the answer to my question is “wrong design” and my schema is not ok.
is there a way to have access permisions for sections ? that could be a solution to my problem of data access between departments… I granted permisions into the CRM only to people that is working on sales, but there I have a column country which is comming from the document parameters… If I can grant permisions by sections I don’t need all the documents schema…
You’re correct in how things do not work. Cross-doc is not designed to be used this way.
Right now, locking and permissions can prevent people from easily seeing data, but they are not absolute secure solutions as data can be seen through other means. Possibly by writing a formula that uses the data or by using the API. Someone that the doc is shared with could also copy the doc to see the information.
I would work on simplifying your schema where variables and sensitive info is in one doc for Admins and only sync over what you need to the other doc.
Not happy with the answer I received from supoport and 5’ before giving up using Coda (that I love but this issue was a heart break) I found a very simple way to minimize the impact of the limitation to sync a table with a synced row without losing the original entities. why I don’t want to loose the entity because I wanna have access to their attributes in the last table I’m syncing in…
SOLUTION: In place of simple using the related column to add the row from the synced table using the “Add row” buttons I’m making a filter of the related table. And with that I have access to the attributes of seniority (the parameters table on one single point in one document) in the third table projects.
here you have the example. Look at the formula in seniority in this table and in the Document with the issue (two columns seniority and years)
This will be a kind of kickstart for the user that might have an idea to solve your schema
all I mean, the data restriction and also the order and the idea to have only one place in all the organization with the entity “Sr”…
