We are building out a CRM like table in Coda. We often have contacts who play different roles on different projects. They might propose on one project (in which case, we want them to be listed as a someone we requested a proposal from) but they might only be hired for a few. How would I do this in a Coda table?
One way I can think of is through creating multiple relation columns from “Projects” to “Contacts”. In “Projects”, you can name each relation column with the dedicated role of the contact. So, you can have one relation column called “Proposal from”, and one relation column called “Collaborators”, for example
Thank you, Simone. I understand what you are proposing. You are essentially saying I would need a unique column for each distinct “role”. I’ll certainly give that a shot. My only concern is that the example I gave was convenient but doesn’t perfectly reflect reality. The more common case is that we have many contacts who may need to be tagged with an indefinite number of unique “roles”. I’m a bit worried about how that would grow the list of columns… But again, appreciate your help.
The closest thing I found to what I was looking for in the Community was this thread about Supertags in Tana…
It is not necessary to create a new column for each relation - you can have a single column which is a select list, that contains all the roles, and then you select from that list.
The next step could then be to say a person can only play certain roles. In that case you would create a table from that select list, and then add people to each role. In the main table you would then have a role column where you enter the role. You would have a person column which is a lookup to the new table, and where you filter on the role to find the people that can play the role.
As far as the super tags go, below is a doc that is a slimmed down version that I use to manage my work. (Personally and professionally.)
At the heart of it is a dbThoughts table. This table contains two cross reference columns, which cross-references to the table itself, using the Relation column type. You can use those Zettlekasten-style, or to implement hierarchies, or just to cross reference any thought to any other thought.
For a more structured approach, there are also three Tag columns, which can be used to tag information. It is structured in such a way that Tag 2 entries are limited by what was selected in Tag 1, and similarly Tag 3 entries are limited by the entry in Tag 2.
There is a property for Date created, and another for Date modified, if needed.
Finally, there is always the search boxes that you can use to search either the current view, or the whole current document, or all of your documents.
Hope that gives you some ideas.
You can also have a look at this:
Thank you Piet! This is very helpful
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.