When your event is added to someone else’s calendar, you have no ability to affect their event notifications. That’s inherent in Google Calendar and cannot be changed.
In addition to what @Steve had stated, basically you cannot add any event to someone’s calendar. You can only add a user as an event sharer via the user’s email, and the event can be added to that user’s calendar if and only if the user responds as YES to the invitation. You can notify users for any changes via scripting only as @Aleksi had already stated.
Hmm… what do you mean by "someone elses calendar?
To manage the targeted GC I have to log in to it. So it is kind of “my calendar”.
I understand, that changing data does not trigger a notification to an non-googlecalendar user, as the google web interface does.
Do you mean by “some scripting” a workflow sending a AppSheet notification? Then yes, that’s what I am doing now. Or do you mean a script to trigger that google-surface event?
@quittean
If you want to send email notifications to your calendar event attendees, you explicitly need to make a doPost(e) call to Google Calendar API via AppSheet Webhook Workflow. To accomplish this, you need to create a Google Apps Script, deploy it as a webapp and then use its URL as a webhook endpoint URL with passing required parameters in the JSON payload.
@aeastham
At the moment, to be able to use the Calendar API, you need to construct a Google Apps Script, deploy it as a webapp and use its published URL as a webhook endpoint in your AppSheet Webhook Workflow.
I believe that AppSheet uses this API under the hood when you have the calendar as an AppSheet “table”. If this is the case, they could expose this parameter to us which would hugely simplify this.
I will investigate this and see if there is something we can do in the Calendar Data Source for this on our roadmap.
Meanwhile, AppScript is the best way to get this kind of fine grained control over APIs, as was discussed earlier in this thread. Probably the easiest way to call an Apps Script, so that you don’t have to jump through a bunch of steps to configure API Keys and Secrets in GCP (Google Cloud Platform) Console (as you would if you use a webhook), would be to use a helper sheet.
When you want to create a Calendar event, record that in a Google Sheet that has all the details in it (ie: via a workflow rule action) (you may need a relationship to a child table with all the invitees), and then set up your Apps Script to be triggered when any new row is added to the sheet. The Apps Script can then get all of the event details from the sheet and call the appropriate Calendar or Gmail APIs to do what you want. Apps Script can also call your AppSheet App’s API if it is necessary to update something back in the AppSheet App, or it can just modify data in your App’s sheet as well (or both depending on your use case).
Sorry, we took this up directly with support and I’ve only just seen your reply. Thanks for taking the time.
We use an Azure Sql database for this App so I don’t think App Script will work in this case unfortunately. However, we are looking at using the API and a webhook.
My only concern is the additional bits of string involved and the scope for failure eg when IP addresses change and firewalls suddenly start blocking things that were working.
@aeastham - makes sense completely…and the best solution is to just get this working in the data source, of course, but it will take some time on our side. Maybe you only have to support the API work around temporarily.
To add a little bit more detail around this subject:
It appears that there is a mismatch between the Google Calendar API and the implementation of that API in Google Apps Script. Apps script contains no method for API param “sendUpdates”.
I see this from time to time between the Workspace API’s and the implementation of those API’s in Apps Script.
For now, the best approach would be to run an Appsheet report that triggers an Appsheet Webhook to call the various calendar events and updates sendUpdates accordingly (I have not tried this out personally).