Tips for identifying tasks?

Developers Central
#1

Hey everyone - my startup is about to launch a new feature that is the intersection tasks / todos and your calendar:

We’ve been in beta for a couple months and we soft launches yesterday. We’ve started to get a lot more inbound interest for adding support for pulling in tasks from Coda, which we’re really excited to do.

Probably the biggest question I’m wrestling with is how to best connect a table that represents some tasks to Reclaim for integration. Given how general purpose Coda is, the tasks could be in many locations and many shapes. In first first glance through the API and in playing with the product, it doesn’t appear there is any first class object that represents a task – they are really just rows in a table.

So right now I’m thinking the best approach is to have the user point us to a page that contains the table and then require a certain convention (ex: columns of at least string, boolean, and date) to do the mapping. But I’d love to hear alternative ideas on how we might do this type integration and easily identify tasks from within a larger Coda deployment.

Thanks!

#2

Hey @Patrick_Lightbody, welcome to the Community!

You’re right, Coda is freeform in that regard. You can make a table with a name that tell you it’s a tasks table, and add whatever columns that you think characterize a task in your bespoke system, and that’s it. It’s you who knows that each entry of that table is a task. What Coda knows is that you have a table/view with an ID like grid-F8j3pX12u5, rows with IDs like i-BlN48XcEz1, and columns with IDs like c-p923z6eF2Q.

So in the very least you’ll need some interface where the user would be able to select a doc, a table, and manually map four columns (task name, done status, start time, end time, or whatever) to these properties in your system. Something like Zapier has. Or something like Coda itself does when you set up a calendar view of your table.

I guess at some point you’ll want to onboard e.g. Airtable, Notion, Google Sheets etc — since those also don’t have any standardized schema tasks, for them you’ll have to do the same. Perhaps you’ll reuse the same column-mapping UI for these too.

Another approach is not doing a direct integration but opening up your API to tools like Zapier, Integromat etc. This way whoever’s interested would map all the stuff through a 3rd party tool. Pro: not your trouble anymore. Con: it’s a 3rd party tool.

Enforcing a certain schema convention on Coda (i.e. telling people to make a table with these specific columns if they want that integration) is generally a bad idea. If one would want to use a tool where conventions are enforced, they would pick something box-ready like Jira. People choose Coda exactly for the reason of willing to do unconventional things, where conventional tools fall short.

P.S. Also pages don’t matter. Pages are but a way to present and visually organize the doc’s data. The data itself rests in tables. You should let people select a specific table or a specific view, not a page.

#3

Paul,

Thank so much for the thoughtful reply. We will circle back here and share our progress when it’s ready. Take care.

Patrick