Restructuring my Apps - any easyish way to accomplish this?

Question

We are expanding in a way that makes me need to restructure my app, so that as it grows it makes sense. The best example of what I need to do is with an employees table. I have an employees Table in App A. It has many relationships, both in App A and some cross app relationships (to App AB and AC).

I am going to be creating a number of other Apps for other sister companies. They will share a few things, such as employees. Everything else will be separate.

I would like to make a Global App, with the Employees table in it (and a few other global items). Then I would like to use table syncs to get the employees to each 'cluster' of apps (each sister company will be using a cluster of apps for themselves). I have chosen to sync, so that I don't end up with 15+ apps all related to each other in some way. However, I am open to suggestions on this.

This leads me to my question. Ideally, I would move the Employee table to a global app, then in the original table A, convert the employee table to a sync table. This isnt possible, so I would have to create a new employee synced table, then recreate all relationships (and pipelines/automations) until it works, and then delete the old employee table. I am not a fan of this solution, I think it is too intertwined for me to succeed.

Any thoughts on changing an existing table to instead be synced to another? Or perhaps I am coming at this from the entire wrong direction.

------------------------------
Michael Tamoush
------------------------------

markshnier__you · Answer

You are absolutely correct that the last thing you want to contaminate your ecosystem by binding 15 apps all together into one monster app. That basically would deny you the power and speed of using 15 different servers and let QuickBase serve you with just one server.

So one way is the somewhat painful method you described to rebuild all the relationships.

but assuming that the key field to your employees table is some kind of employee ID number which is unique or perhaps even an email address or a user ID which would be unique, then there is a Plan B.

That would be to preserve your existing employees table in this one app and bring in a connected Sync table for the global employee list. Or at least the employees for that company the app serves on the global employee list.

Then you would set up a table to table import run regularly by an Automation or Pipeline automation to copy across from the global employee list into your local employee list.

And the last thing you need to sort out if there is a possibility that an employee may be deleted from the global employee list. If that is the case then we need to make a relationship between the two employee tables and based on that relationship figure out if the employee got deleted from the global list and if so run a nightly automation or pipeline to delete those employees. But maybe old employees never die, they just become inactive.

Mark

------------------------------
Mark Shnier (YQC)
mark.shnier@gmail.com
------------------------------

michaeltamoush · Answer

That's sort of what I was thinking. That my app will forever be updated via table to table import or a pipeline etc, while the new app clusters can utilize a sync table. And my OCD will just deal with it until some day that I decide to make the leap and rebuild each table that moves to the global app, one by one. So that eventually my app is also synced and everything is consistent and clean.

------------------------------
Michael Tamoush
------------------------------

Forum Discussion

Restructuring my Apps - any easyish way to accomplish this?