Recording Preferences

Calendar meetings do not get recorded by default.

The auto-recording behavior for synced calendar meetings can be configured based configured recording preferences, which can be updated via the Update Recording Preferences endpoint.

Recording Prerequisites

Regardless of meeting preferences or manual recording overrides, a meeting must pass the following criteria in order to be recorded:

1. Must contain a valid meeting link.
2. Must have a both a start and end time (whole day events in are not supported).
3. Must not be cancelled and cannot have already ended.

Manual Overrides

If a meeting passes Recording Prerequisites, the following conditions are applicable based on its override_should_record field value.

1. null: This is the default value. In this case, this field is ignored and Recording Preferences apply.
2. true: The calendar meeting will be recorded, regardless of other preferences being applicable or not.
3. false: The calendar meeting will not be recorded, regardless of other preferences being applicable or not.

Recording Preferences

A recording preference is applicable to a meeting only if:

1. Meeting passes Recording Prerequisites.
2. Meeting has override_should_record field value as null.
3. Preference value is true. (Note: Incase of false the preference is ignored rather than its negative being applicable)

📘

Recording preferences behavior

Only recording preference that are set to true will be evaluated. If all evaluated conditions are met, the meeting will be recorded.

Below is a list of supported preferences:

1. record_non_host: Meeting will be recorded only if the connected account is not the host of the meeting.
2. record_external: Meeting will be recorded only if it has at least 1 external attendee.
3. record_internal: Meeting will be recorded only if it has no external attendee.
4. record_recurring: Meeting will be recorded only if it is a recurring meeting.

An external attendee is defined as a participant having a different email domain than the email domain of the meeting host.

Additional preference filters(Note: These settings act as additional filters on meetings that pass the above preference rules):

1. record_confirmed: Meeting will only be recorded if the calendar account has "accepted" it.
2. record_only_host: Meeting will only be recorded if the calendar account is the host of the meeting.

Common use cases and recording preference combinations

As the recording preferences build on top of each other, we recommend to avoid exposing these as direct options to your end users. Based on the use-cases your application needs to support, keep a map of preference object and apply it to the user.

We have listed few common use cases below along with preference object value. For preference keys missing in the object, their value should be set to false

Record all meetings

{
  record_non_host: false,
  record_recurring: false,
  record_external: true,
  record_internal: true,
  record_confirmed: false,
  record_only_host: false
}

Record only internal meetings

{
  record_non_host: false,
  record_recurring: false,
  record_external: false,
  record_internal: true,
  record_confirmed: false,
  record_only_host: false,
}

Record only external meetings

{
  record_non_host: false,
  record_recurring: false,
  record_external: true,
  record_internal: false,
  record_confirmed: false,
  record_only_host: false,
}

Record only meetings where connected account is the host (both internal + external)

{
  record_non_host: false,
  record_recurring: false,
  record_external: true,
  record_internal: true,
  record_confirmed: false,
  record_only_host: true,
}

Record only meetings where connected account has accepted the invite (both internal + external)

{
  record_non_host: false,
  record_recurring: false,
  record_external: true,
  record_internal: true,
  record_confirmed: true,
  record_only_host: false,
}

Incase of a missing use case, please reach out to us in the Slack to confirm the preference object combination.

Customizing Name for Calendar Bots

Calendar bot name can be configured for each user by updating the bot_name preference field. The changes can take few minutes to reflect for all the scheduled bots of the user.

Bot Deduplication

By default Recall will automatically de-duplicate bots(i.e send only 1 bot) for connected calendars scoped to a single Recall workspace. This would be better explained by example below:

Let’s say we have:

• Users U1 & U2 [email protected] & [email protected]
• Apps A1 & A2 using Recall’s calendar integration via their accounts [email protected] & [email protected] (both have de-duplication turned on their accounts)
• Both U1 & U2 connect their calendars in A1 & A2, and have a shared meeting M1 which needs to be auto-recorded.

How many bots should join the meeting M1 ?
1 - ❌ (This would mean both A1 & A2 have access to shared bot data which is incorrect)
2 - ✅ (One accessible to A1, One accessible to A2)
4 - ❌ (If de-duplication was turned off there would be 4 bots joining the call, U1A1, U1A2, U2A1, U2A2)

Incase a bot is de-duplicated across multiple meetings, the calendar_meetings array will contain reference to each of the calendar meeting.

Opting out of de-deduplication
If your application's business logic requires you to have 1 bot per connected calendar (i.e no deduplication). Please reach out to us and we can turn this off for your account.

Custom de-deduplication
The Calendar V1 APIs do not support supplying a custom de-deduplication logic. If you require this functionality, we recommend to integrate with Calendar V2 APIs.