Hi friends - I’m in the weeds with Cross-Doc and up against a time crunch, and would appreciate any advice.
I have a master doc for our school dept that has been collecting form responses for various teacher evaluations, all into a master DB table.
I have rosters for all user types - students, faculty, staff. I found that I could automate the creation of new docs for each student and share them formulaically using the Doc Explorer pack (thanks, @Scott_Collier-Weir !).
I’m working on a template for all of those student docs to bring in all of the evaluation rows that apply to them. The students would have view-only access, so they wouldn’t need a coda account to access.
What is the best way to push that data to each student’s doc?
As I weed through Cross-Doc documentation and videos, is the secure way really to make an individual table vlew inside of the master doc for each student? Is there a way to do that formulaically? We have 150+ students, and the roster changes each term. Is that really how businesses do it - manually creating a view for each client and THEN dragging that into Cross-Doc?
I watched @Scott_Collier-Weir 's archive doc with Coda Webhooks, which does have an additional cost to it. But in the tutorial, all rows went to the same doc - not sure if it’s possible to pull in the individual student doc’s url to make sure right row gets to the right place, since the table url will also be different for each student doc.
Or is the best way some method with the API? I didn’t see a way to create views of a table in the API docs.
I appreciate the Sync Tables Pro functionality but am not in love with the required table name nomenclature and so much complexity in the execution. I just need to distribute the information from one to many docs securely and consistently.
If I was in your case, I would likely write in a script in google apps script that completes these tasks for you, but if you’re not familiar with JavaScript it’s not going to be a fun process
You COULD do the Coda Webhook pack that I created, but you’d have to individually copy over each unique automation link and port it back into your first doc. It would work but it’d be some Setup for sure
What if you, alternatively, used the password method I shared with you. But with these caveats:
cross doc just the evaluation table to a separate doc. DOC 2
cross doc it in with no names, but instead unique and arbitrary passwords connected to each row
Then distribute the passwords to the students (via gmail pack!) and have them access their evaluation via the password portal.
Even if they could hack in and find the other information, it would be mostly useless because there’s no identifying information attached to those rows?
Just sounds like a huge headache to do the 150 individual docs
Sorry to hear that but you cannot do it otherwise. The name nomenclature is largely for your own good (and there’s not much to it — like, make one view and call it OUT? or make a __read column for rules?) and there shouldn’t be any complexity really to do what you need — just give each student a token and set it up in each of the individual docs. It may just seem like it because I never found time to make simple documentation for it. With webhooks there would be much more complexity, to be honest.
Happy to assist you with setting it up if you’re interested — DM me or write at paul@codatricks.com
If you absolutely don’t want my pack, here’s the least painful way to do it with Cross-doc
— but yes, you’ll still need 150 individual views for each student’s export. You can generate those with DuplicatePage now. The downside is that now that you’ll have 150 views, that’s gonna be 150x the recalculation time on filters on any row addition/removal/change.
Then there’s always external solutions like app scripts, Integromat, Zapier to read rows from the main doc and push them into individual docs. But at that point it would be more viable to just do webhooks.
P.S. Actually they are not. When you clone docs from one common templates, all object IDs (e.g. automation/webhook IDs, table/view/column IDs, even row IDs for already existing rows) will be the same in those copied docs. Only the doc ID will be different. This is a staple of making template distribution systems.
If your heart is set on pushing data through webhooks, you won’t have to store 150 different automation IDs for each of the doc — that’ll be the same automation ID. You’ll still have to nicely write your actions to then process those webhooks and create rows in proper places (maybe employ some iterator tables for that), link together reference, break down the data into chunks (because Coda only allows payloads under 4MB — if you have hundreds of rows to push through webhooks you’ll have to split them down and send in batches) etc. I’d say at that point it would simply be easier to use Sync Tables Pro — the scenario like yours is what I had in mind when I designed it.
It doesn’t have to be. The pack is there ready to use for your convenience, but you can totally code it yourself in 20 minutes (15 of which you’ll study the SDK documentation) and some 20 lines of code.
