I'll preface by saying that this isn't a direct solution to your question. Instead, it's a proposed tweak to your database design that created your predicament in the first place.
Within an Airtable base, you have tables. A table contains records.
When planning and designing a data(base) and it's tables, you want each table to contain records for a specific type of thing.
A table called Contacts will contain an individual record for each contact in the database, and so on.
In your use case, you appear to be dealing with a single type of thing: Events (or appointments, etc.)
So, instead of having four separate tables for the same type of thing, you should instead only have a single table that contains all your events (for a lack of a more specific word).
This accomplishes two things. Firstly, it falls in line with clean data design and best practices. Secondly, you eliminate the need to incur an uncomfortable amount of technical debt by creating (and maintaining) automations that are prone to issues. This is on top of the fact that automations like the one you described almost never scale as intended and require an ever growing collection of band-aid solution fields, accessory automations, etc. to keep them going as time goes on and your dataset continues to grow.
The fundamental problem with keeping four or five separate places where similar data can be found is that you have duplicate records and information flying around. This is the biggest problem.
By consolidating your records into a cleaner structure, you can then leverage views and Interfaces (preferred) to create a tailored, refined, and easy-to-manage user experience that bolsters your user adoption rates and in turn increases the overall success of your use case and implementation.
If you're utilizing the synced table Google Calendar (pseudo) integration, you can sync multiple calendars into a single table using the Add records from another source feature found in the Synced table settings of the table you're working in.