Very stuck - Managing tasks across multiple docs for a team of 6 - Maybe use a Todoist pack?

1

Hi community,

Please activate your hive mind and send it my way!

I would like to be able to set up a way to manage tasks across multiple docs, for a team of 6.
In addition to the task management system being set up to work across multiple docs, there is the complicating fact that we are a small retailer and are often sharing computers. Those shared terminals are logged into shared Coda accounts, rather than the Coda account of the person currently using that terminal.

I tried a couple of different ways to do it within only Coda but got stuck. This might very well be due to lack of knowledge.
For context, Iā€™m a regular user of Codaā€™s CrossDoc pack. Iā€™ve experimented with @Paul_Danyliukā€™s Sync Tables Pro, and @Scott_Collier-Weirā€™s 2WaySync and Webhook.

In order to solve for the shared terminal/shared coda account situation, I tried to set something up to be used on a mobile app as everyone in our team has their phone on them.
I found the Coda mobile experience a bit clunky. This led me to wonder if there would be a way to use the Todoist pack. Iā€™m guessing the pack can do what Iā€™m hoping it to do. For the life of me, I canā€™t make sense of how to build a set up with it for our team to use.

I guess I have two questions, both couched in a big request for help:

  1. Can anyone please advise on how to manage tasks within Coda across multiple Docs?
  2. Has anyone had success building a team task management set-up with a Todist pack?

Thank you very much for taking the time to read this :slight_smile:

1 Like
2

Depending on the kinds of things that need to be done, I find that if you set up a page with the mobile experience in mind, it isnā€™t too clunky. I havenā€™t used the ToDo list pack though.

Could you explain why it needs to work across multiple docs? If you had all your base tables in one doc, you could share a sync page across the multiple terminals.

3

Thanks for your reply @Samuel_Langford,

Iā€™m reassured by your positive experience with the mobile app. To be fair, it was a while ago that I initially had a go setting up a Doc with the intention of it being accessed via mobile. I came to Coda with no coding/IT background. My skill level has improved a huge amount since then. As well, I saw a recent post from Coda announcing updates to mobile. From your response, it might be time I had another go at it.

Bit of a long shot, but do you have any go-to guides or maybe post threads in this community that youā€™ve referred to when learning to create a Doc tailored to mobile?

To your question about why multiple Docs, Iā€™ll have a go at articulating a simplified example of what Iā€™m hoping to achieve. Iā€™m not clear on what type of overall database design will suit.

Doc A: ā€œEvents & promotionsā€
Table A.1: Events database
Table A.2 Content calendar database

Doc B: ā€œReturnsā€
Table B.1: Returns database
Table B.2: Ongoing projects.
Table B.3: Meetings

Doc C: Buying
Table C.1: Annual buying calendar
Table C.2: Ongoing projects
Table C.3: Meetings

Doc D: ā€œRoutinesā€
Table D.1: Routines database (a summary of routine/repeating tasks, built using @Paul_Danyliukā€™s strategy/switch-if tutorial https://www.youtube.com/watch?v=m6xq7VrH6mg&t=460s)

Doc E: Account orders
Table E.1: Account orders (we work a lot with schools, they order and pay on invoice, rather than in store, their orders can be quite large and complex. In time, I plan to build this Doc out to a more fully fledged CRM).
Table E.2: Ongoing projects.
Table E.3: Meetings

We have many more Docs, but this collection is illustrative of where Iā€™m stuck.

In Doc A, Table A.1, each row is an single event.

  • There are broadly 4 types of events we run, each type has some standard tasks/workflows.
  • Often, an event will have additional tasks arise that are not able to be included in a template task list.

In Doc D: ā€˜Rountinesā€™, is a work in progress Doc. I am building out a database containing repeating units of work. Some are allocated to a specific person, a lot are more general i.e. ā€˜Store openā€™ contains a checklist of things we do to open the store, whomever is rostered to open is the person who does the checklistā€¦

Notes:

  • In some way, I would like to be able to add a task management system into each Doc.
  • I would like it to be centralised in some way, so that a person who works across multiple Docs can see all of their active tasks in one view.
  • Ultimately, it would be great to be able to centralise ā€˜Meetingsā€™, and ā€˜Ongoing projectsā€™ as well, rather than have the data siloed in each Doc.

I have often considered the idea of sync pages as a way to centralise ā€˜Meetingsā€™ and ā€˜Ongoing projectsā€™. It seems less important for these tables to have a relation to other databases.
Where tasks differ a little, is that I would like tasks to be able to relate them with multiple databases across multiple Docs.

4

Hi,
Have you tried looking into @Paul_Danyliuk Formula Table pack? (See below). What Iā€™m thinking (and I havenā€™t tested its limitations) is to create another doc that syncs the task tables from other docs into it. Then create a formula table that combines all the task tables into one.

As for task management setup (in general), I am first building a ticket management system that mimics how an IT department handles incoming request/issues. What this allows me to do is handle anything that comes into the inbox quickly. For instance say an invoice comes in via email.

The ticket system will extract To:, From:, Subject:, Summary of Email Body, Priority and either automation, AI, or a person can assign the appropriate ticket type (invoice ticket), which will have a corresponding workflow and set of tasks in place. The guide I use for setting up workflows/tasks is loosely based on how cookbook recipes are structured while taking into account triggers and dependencies.

What Iā€™ve learned is not to ā€œreinvent the wheelā€ and use the frameworks that already exist out there because you are essentially building your own custom software using Coda tools.

Regards,
CS

1 Like
5

Rambling Peteā€™s rules of thumb:

  1. Only create a new table if absolutely necessary.
  2. Only create a new doc if absolutely necessary.

Virtually every day we have a question on the community asking along the lines of this ā€œHow do I combineā€¦ā€

Very, very seldom is there a question on ā€œHow do I split thisā€¦ā€ And 90% of those questions have to do with restricting access to sensitive information.

But itā€™s just a ramble,
Rambling Pete

2 Likes
6

Thank you very much to @Piet_Strydom, @Coda_Solutions and @Samuel_Langford for your thoughtful responses. I am very grateful for your input.

Your responses are helping to bring structure to my thinking. Two days ago, I felt totally stuck - verging on a bit despondent - about the project. Today, my enthusiasm and curiosity have perked right back up.

@Piet_Strydom I take your point about pausing to seriously consider the reasons why a new doc or table is being considered. As someone without a computer science/data base/programing background, it is really helpful to be instructed on (and reminded about) these first principles.

On this point, @Paul_Danyliukā€™s initial Coda course was perhaps the greatest piece of Coda training I have come across to-date. For all of Codaā€™s fantastic efforts (and marketing) to make Coda approachable to the general public, to use it effectively seems to require a decent level of technical knowledge. He started the course by taking us through some CS and database 101. If he runs another one, I canā€™t recommend it highly enough for anyone just starting out.

My initial takeaway from your response is to restrict myself to creating one ā€˜Tasksā€™ table, then think carefully about where to locate it.

@Coda_Solutions Iā€™m currently employing Paulā€™s Formula table pack in an Events & promotions Doc (E&P). Iā€™m using it to create a timeline view of two databases, one database contains all events and promotional activity within the store. The other database contains all content creation activity. The tables are related 1-to-many, where multiple Content rows can relate to a single E&P row. Iā€™m quite proud of how the Doc is turning out. Hopefully, Iā€™ll ā€˜launchā€™ it tomorrow by introducing it to our team.

I am very intrigued by your suggestion of an IT department style ticket management system!
Does anyone in this thread have a suggestion for resources I can access to learn how to build a ticketing system?

I wonder, does my interpretation of your suggestion (below) make sense?

  • Create a Work Management Doc. In it are (1) a Task/Ticket/Project management system, and (2) a Meetings database.
  • In the existing E&P Doc and database (DB_eventsAndPromotions), add a CrossDoc-AddRow button column.
  • When pressed, it triggers an action in the Work management Doc. A preset ā€˜Recipeā€™ gets added to the Ticketing system.
    (this is where my idea gets pretty hazy)
  • The URL of thisrow.DB_eventsAndPromotinos is sent across the to the Ticketing system, along with a couple of other key details i.e. row name.
  • From the URL, we extract the DocID and TableID.
  • Staying in the Work Management Doc, use some combination of the Docā€™s pack and the Scottā€™s Doc Explorer pack to create a SyncPage view that displays only the Ticketing data that corresponds to the E&P Doc.
  • Back in the E&P Doc, add a SyncPage of the filtered and formatted ā€œE&P viewā€.

The capacity to extract tickets/tasks from emails is already something I was hoping to explore at some point in the future. Iā€™m excited at the possibility that it could be part of the Task/Ticket Doc.
Related to task/workflow creation from emails - we get most orders from our school customers via email. It would be incredible to be able to turn these into rows in our existing ā€˜school ordersā€™ database.
My gosh, Coda is very, very awesome. Itā€™s changed my life for the better in so many ways.

Thanks again for your imput!

1 Like