Skip to main content

I need to manage multiple deadlines for multiple projects & clients more efficiently. I don’t want to update deadlines in multiple places, but that’s where I am. This isn’t efficient and will not work for the long term. Here is the current setup:

  • I have a Primary Base I use to manage grant research, tasks, and profiles for all of my Clients. This includes 2 key tables: a Research Table and a Task Table.
  • The Research Table is filtered into views that are specific to each client. Each of those views are synced to a Table within a Separate Client Base. That Separate Client Base also includes a second Submissions Table that is manually updated with specific due dates and other requirements that are unique to that Client (although some research may be relevant to multiple Clients, specific details will be unique to each client). This Separate Client Base is shared with each Client.
  • The Task Table (in the Primary Base) is manually updated with a wide range of tasks that is grouped by Client. This is not synced anywhere. These tasks are internal and include a wide range of items that do not need to be shared with each Client. 

I have several ideas but I’m unclear what is most efficient. The end result I want is two-fold:

  1. I want a Comprehensive Task List that includes 1) all deadlines from the Submission Table in each Separate Client Base PLUS 2) any tasks that need to be added for that Client. 
  2. I want this final Comprehensive Task List to sync with Google Calendar. I don’t want to sync multiple calendars if I can avoid it.

Any suggestions? Is this an automation issue? A sync issue? A formula? A base design? A combo of all these? Thank you!

Hmm, lots of thoughts here. Overall I think your issue is with workflow design, as segregating the data into multiple bases makes it harder to sync. There are three general options I’d look at and then explore deeper on whichever appeals…

  • Business Tier: Are you on business or enterprise tier (or willing to go up to those)? Those tiers allow for two-way synced tables across bases, so then it’s a matter of structuring the data to flow up from the Separate Client bases into your Primary base.
  • Client Interfaces instead of Bases: If you’re attached to a Teams plan, then another option might be sharing individual interface pages with your clients, instead of entire bases. This would need a fair bit of restructuring but it’d get all your data in your primary base.
  • Utilizing 3rd party automations: If A or B won’t work for you, then you could create a bigger picture scheme with Make or n8n to connect your bases together outside Airtable, so Airtable updates to a client base trigger automations copying the data to your primary base. 

Yeah, as ​@DisraeliGears01 mentioned above, it it actually NOT recommended to split up all of your data into separate bases for each client.

What you’d ideally want to do is combine everything into ONE base, and then you only need to create ONE interface page that is automatically filtered by whichever client is currently logged into your base.

When a client is logged into your base, they will only see THEIR OWN records — they won’t see any other clients’ records.

You can do this with the Teams plan, but it’s more secure if you do it on the Business plan.

- ScottWorld, Expert Airtable Consultant

Terms & Conditions