Create task objects with different columns depending on "team" column

[Shaina_Nacion]

Hi all! New Coda user here, so I apologize if this has already been addressed elsewhere in the community, but I couldn’t find it when doing a search.

I’ve created a master database of tasks for my company; each entry includes a column for “name,” “start date,” “due date,” “assignee,” etc… But my question is whether there is a recommended method for creating different types of tasks that include different columns depending on the type.

For example, I have tasks for “client work” which require a lookup column that connects to our client/contact database. Then I have tasks for “product development” which require a column for “price”. The client work tasks don’t require the price column, and the product development tasks don’t require the client/contact column.

Is it better to create one master task database that includes every column required for every type of task, then hide the columns as appropriate within each view? Or is it better to create separate task tables for each type of task?

I’m leaning toward creating one master task database so that I can more easily create task views that show all tasks regardless of type. But it seems like there should be a simpler way to do this.

Thank you in advance!

[Quentin_Morel]

Hi @Shaina_Nacion

First of all, welcome to our amazing community !
As you mentionned, in coda this is often better to reduce the number of database, and to use the different available tools to manage this.

Here is my suggestion for your needs, please do not hesitate to make any comments so that we can find the best way to answer your questions.

As you mentionned, I created a unique database, with different teams : Client rows have a “client lookup” column filled, and “product” have a price (this is a short example, this is the same if you have more data related to client, product, or any new category you may wish).

This view is the master view

Here is my suggestion : If i had to deal with that myself I would

• Create a master view, with all teams, but only the common columns + A button that will open a modal view, with a different layout according to team. If you have a lot of commun columns it’s really better to have a single database
• Create separate view for each category, with relevant data

For separate views, this is easy, just show/hide columns like this, and filter by teams

For the master table, I show in my case only start/due date (that are the same for both categories)

Create a button column to open the row from the master view with relevant information. Depending on team, you will open not the master table, but the view you want

Opening a row with this button will show you relevant information, and of course you can edit 2 layouts. In this example, I chose on purpose two very different layout, showing you you can customize the display even if you click with buttons from the same columns.

And of course, if you want to see directly data, use the direct view.

Anyway, if you deal with 1 only database the function SwitchIf() will be very useful. You’ll see I use it to change button’s name, to change the action of the button. And you can discriminate every action you want on your main master table using SwitchIf()

Find this little embed doc and let me know what you think

Cheers
Quentin

[Piet_Strydom]

HI Shaina,

Welcome to the community and to Coda! I hope you find it as useful as I do.

I completely agree Quentin - fewer tables, fewer docs, are generally better.

But I always caution people to be prepared to redo their first big docs. At least once - It is just such a different way of thinking. Fortunately changing is easy.

Happy making!
Rambling Pete

[Shaina_Nacion]

Thanks so much, @Quentin_Morel ! That was super helpful. I was leaning towards handling it that way, so seeing your example helped solidify that direction. Looking forward to fleshing this whole thing out!

[Shaina_Nacion]

Thank you @Piet_Strydom ! I’m loving Coda so far – its flexible capabilities are perfect for just about any application we’ve come up with.

And yes, believe me, I’ve rebuilt and redesigned this doc so many times over the past month that I’ve lost track I’ve decided to embrace the iterative nature of this process and just enjoy the ride.

[Quentin_Morel]

@Shaina_Nacion

Thanks so much, @Quentin_Morel ! That was super helpful. I was leaning towards handling it that way, so seeing your example helped solidify that direction. Looking forward to fleshing this whole thing out!

Please be my guest @Shaina_Nacion , always happy to help