Skip to main content

Since finding Airtable, we have been actively creating many apps to digitise our businesses. So far we pretty much have a base for each app. Some apps are for a specific company of ours, whilst some like HR and Tax/Assets are apps that apply to more than one of our companies. We use Stacker as the interface for most users.

We have come to realise that there are some data that might make sense to be thier own base(s). Contact (suppliers, customers, staff, everyone any company comes into a transaction with) is one example. Products is another (things that all companies buys, and in some cases, maintain as assets).

So, I would like some advice if it does make sense to create these two data sets as their own Bases and sync one-way to any destination base that needs/interacts with them. It would presumably mean that Contacts and Products become it’s own separate app, and anytime a new Contact or Product interacts with any of the other apps, a new record needs to first be created in the Contacts/Product app.

Is this the corect approach? Would it get too cumbersone in practise to have to add a new product to be purchased in any of the company(s) apps, first in the Contacts/Product App and then proceed in the operating apps? Or does a multi-sync base works better? Or that’s actually for other use cases altogether.

Any advise from all experinced developers in this community is greatly appreciated.

Hi @Khuned_Sachdev,

In my experience, there isn’t a correct or incorrect approach. From what you describe, what you have setup is a good start and adding an additional base to sync into a destination base isn’t cumbersome. In fact, in my opinion, there are times where the sync makes sense and is even essential. There are reasons for that too. Mostly, it will depend on how your collaborators (users) interface with the data, number of records you believe you will have, and what type of data integrity you are looking to implement.

For example, if you have a relatively small number of collaborators who all need to interface with all of the data and they are competent in doing so, then it may be easier to have all of your data in one base. On the other hand, if you have a larger number of collaborators or you need to implement more stringent security for some of the data, then I recommend parsing out the data you need to control into a separate base and only granting access to those you know need edit access to it. That way, when the data syncs into the destination base for everyone, there is no way that everyone can edit the data, they can only view it.

Also, multi-sync works the same way as single-sync. In a single-sync, a specific view from a table in the source base (base 1) is pulled into a newly created table in the destination base (base 2), and will only show the data that is shown in the specific view from the source base (base 1). In a multi-sync, data comes from a specific view in a table in a new source base (base 3) and is synced into the table in base 2 that was created in the single-sync. Ideally, the data in base 3 is very similar or identical in format to the data in base 1 but it doesn’t have to be. When a multi-sync is set up, you will be prompted to relate fields from base 3 to base 2 and will also have the chance to add fields that didn’t align or match.

An example of this is…
As a single-sync, pulling contacts from Office 1 (base 1) into a destination base for HQ (base 2).
As a multi-sync, pulling contacts from Office 1 (base 1) and Office 2 (base 3) into a destination base for HQ (base 2).

Hope this helps.
Chris

Hi @Khuned_Sachdev,

In my experience, there isn’t a correct or incorrect approach. From what you describe, what you have setup is a good start and adding an additional base to sync into a destination base isn’t cumbersome. In fact, in my opinion, there are times where the sync makes sense and is even essential. There are reasons for that too. Mostly, it will depend on how your collaborators (users) interface with the data, number of records you believe you will have, and what type of data integrity you are looking to implement.

For example, if you have a relatively small number of collaborators who all need to interface with all of the data and they are competent in doing so, then it may be easier to have all of your data in one base. On the other hand, if you have a larger number of collaborators or you need to implement more stringent security for some of the data, then I recommend parsing out the data you need to control into a separate base and only granting access to those you know need edit access to it. That way, when the data syncs into the destination base for everyone, there is no way that everyone can edit the data, they can only view it.

Also, multi-sync works the same way as single-sync. In a single-sync, a specific view from a table in the source base (base 1) is pulled into a newly created table in the destination base (base 2), and will only show the data that is shown in the specific view from the source base (base 1). In a multi-sync, data comes from a specific view in a table in a new source base (base 3) and is synced into the table in base 2 that was created in the single-sync. Ideally, the data in base 3 is very similar or identical in format to the data in base 1 but it doesn’t have to be. When a multi-sync is set up, you will be prompted to relate fields from base 3 to base 2 and will also have the chance to add fields that didn’t align or match.

An example of this is…
As a single-sync, pulling contacts from Office 1 (base 1) into a destination base for HQ (base 2).
As a multi-sync, pulling contacts from Office 1 (base 1) and Office 2 (base 3) into a destination base for HQ (base 2).

Hope this helps.
Chris


Hi Chris, thanks for this. Gives just the conceptual confirmation I needed. Will proceed with using sync in our designs from now onwards.

Cheers, Khuned

Terms & ConditionsAccessibility statement