+20Hi,
My company has reached its max limits of automation configurations on one base and has decided to move on of the tables in our base to a secondary base for better scalability. What would be the best course of action to begin this process, provided that there are multiple tables that are already linked in the original base. My thoughts are that taking advantage of Enterprise 2-way sync should make this feasible, but I am wondering if anyone else has attempted this and has any tips.
Drew
Best answer by dariot
+15Hi Drew,
Great question! How many automation do you have in your primary base? I'm happy to see if there is a possibility of increasing before making any changes!
+20Hi Drew,
Great question! How many automation do you have in your primary base? I'm happy to see if there is a possibility of increasing before making any changes!
Right now 46. But the idea is that scalability is important and we are expecting to have more automations related to webhooks and Twilio messaging as a result of advances in our work processes. I just don't want to be limited by the number. I know that migration and re-integration through syncing tables can be painstakingly tedious.
+15I hear you on that! 😅
I just sent you a private DM with a few more questions specific to your team's base information. 🙂
+22This touches on a really good point though – I would love Airtable to build features that support relocating tables to new bases, syncing them back etc. This type of work is incredibly hard to do manually (and reliably), but could definitely be supported programmatically and with clever design.
+9This touches on a really good point though – I would love Airtable to build features that support relocating tables to new bases, syncing them back etc. This type of work is incredibly hard to do manually (and reliably), but could definitely be supported programmatically and with clever design.
One thing I've done here at FOX Weather is I have one base that I use for alot of API Sync, and then I sync with the Two Way Sync feature to our "Main" base. From there, it helps me manage automations a little better, as I have most of my backend automations in the "data" base, whereas the "Main" base is more of the front end automations. Hope this helps!
+20Hi Russell,
It sounds like what you're looking for is two way sync! Have you tried this out?
2-way sync is very useful but there are also the hassle where you are a company that build bases with Pro level and didn’t have access to the feature, and now want to take advantage of it because you want to clean up a cluttered base. Thank goodness for Interface designer because my company would find our most used base quite messy.
Also in terms of two-way sync, it is sometimes a challenge when dealing with related tables.
for instance I have a work process that I am trying to build in AirTable where one department is processing tenant moves for our relocation department. We are an affordable housing company, and I want to send a request for inspections to our inspections department in another base. Two way sync can help with mimicking the type of need we have, but it is tricky.
essentially, the inspections base has a table of all inspections, we want to feed new inspections into an existing database. And also have the outcomes of the inspections communicate and link back to the relocation base. However, this is not easily done, and I have found ways with two way syncs of both tables on both ends with automations. it would be easy if I knew how to make one base look up the status of a related work process in another department without so many configuration steps. The best I can do is create generated ticket id that an automation would look up and connect through multi-level 2 way sync tables.
+222-way sync is very useful but there are also the hassle where you are a company that build bases with Pro level and didn’t have access to the feature, and now want to take advantage of it because you want to clean up a cluttered base. Thank goodness for Interface designer because my company would find our most used base quite messy.
Also in terms of two-way sync, it is sometimes a challenge when dealing with related tables.
for instance I have a work process that I am trying to build in AirTable where one department is processing tenant moves for our relocation department. We are an affordable housing company, and I want to send a request for inspections to our inspections department in another base. Two way sync can help with mimicking the type of need we have, but it is tricky.
essentially, the inspections base has a table of all inspections, we want to feed new inspections into an existing database. And also have the outcomes of the inspections communicate and link back to the relocation base. However, this is not easily done, and I have found ways with two way syncs of both tables on both ends with automations. it would be easy if I knew how to make one base look up the status of a related work process in another department without so many configuration steps. The best I can do is create generated ticket id that an automation would look up and connect through multi-level 2 way sync tables.
Drew is absolutely right. You can't swap in data when tables are linked with one or more other tables - and those tables have lookups and roll ups etc
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.