How would you implement a hub-and-spoke set of documents, such that each employee has a private time tracking doc, and the data is aggregated into a management doc?
@Paul_Danyliuk 's Sync Tables Pro seems like a reasonable basis (I haven’t really done any hub-and-spoke stuff yet but my understanding is this is the best way to implement that pattern).
I see how I can push data out from the hub to the spokes.
I see how I could have a Time Tracking Transactions table in the hub, and use row-level permissions to show each employee only their own transactions in their spoke docs.
But how could I let employees add transactions from within their private docs? Some kind of support table in the spoke template that pushes to the hub via webhooks…? (Only thing is I would want fairly quick UI response in the spoke doc…) Is this the dream for the upcoming “merge tables” feature referenced in the Pack description (where each spoke would have its own Transactions table, all of which get aggregated to a single one in the hub doc)?
1 Like
Hi @Nick_HE . Do you need a separate doc for each person? You could have a single doc and page where you filter the view of the time tracking table based on the current user. This requires you include a column for the coda user name (so you can filter based on that). When I have used this approach,
I have setup a welcome page the user to press a button to notify the admin that they have logged in for the first time so that they can be added to user list (a separate table / view that is used as a column in the main table). When they add new rows to your time tracking table, it should default to their Coda user name. In the use case where I have done this, the admin has pre-created the table entries for the user using automations so that when I add their Coda User Name to the user table, they will be able to see their assigned rows (they do not see anything until the admin takes that action). So, this approach may not apply perfectly to your use case.
If you do need or want a separate doc, you could probably achieve a similar result using Cross Doc. It is definitely more set up for each doc, but it should work in a similar fashion.
1 Like
Thanks @Jim_Holincheck !
Yeah I need data privacy between the users unfortunately.
One other tip (that I think I learned from Paul too haha) is to have a button that shows up for new users. Clicking it adds User() to the user table and then disables the button (to avoid the admin having to add them).
Best way to do this (without wacky workarounds like my two way sync pack or 3rd party software) is likely going to be using sync pages (when their next iteration comes out)
And then automating the creation of sync pages and their container docs via buttons for all the employees.
This process can be fully automated aside from setting the filters on the source tables that will act as a users sync page/table, that’s its only downfall
But if you want a solution now that’s what I’ve built the two way sync pack for. I’ve used it to successfully build out these hub-spoke model docs.
Everything is instant (row adds, etc) because it’s all native coda tables.
Ooh interesting @Scott_Collier-Weir !
I haven’t tried this Pack yet. Would I still need to manually create a filtered view per employee in the hub doc? (So that each person only sees their own records in the spoke)
Nope!
Not at all. Confident you could set it up - it would allow for a fully automated set up.
You simply have a helper table defining WHERE (aka url) the spoke docs are. BUT there’s also an easy process to create your spoke docs with the coda doc pack so all that is auto logged.
So if a task is assigned to person A, there is a lookup to the helper table that defines where person A’s doc is.
Then, when the two way sync pack runs it sends the tasks back and forth between person As doc and the hub
If you need a quick loom let me know.
Hey @Scott_Collier-Weir a loom would be useful as I tried myself using your pack before without success.