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:

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

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

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!