Recording Preferences & Bot Deduplication

Configure which synced calendar meetings are recorded and prevent duplicate bots from joining the same meeting with Calendar V1.

📘

Calendar meetings do not get recorded by default

See more in the Recording Preferences section below

Recording Prerequisites

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

  • Must contain a valid meeting link.
  • Must have a both a start and end time (whole day events in are not supported).
  • 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.

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

Recording Preferences

Calendar meetings do not get recorded by default.

Auto-recording behavior for synced calendar meetings is determined by the configured recording preferences. These preferences can be modified using the Update Recording Preferences endpoint.

A recording preference is applicable to a meeting only if:

  • Meeting passes Recording Prerequisites.
  • Meeting has override_should_record field value as null.
  • Preference value is true. (Note: Incase offalse 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:

  • record_non_host: Meeting will be recorded only if the connected account is not the host of the meeting.
  • record_external: Meeting will be recorded only if it has at least 1 external attendee.
  • record_internal: Meeting will be recorded only if it has no external attendee.
  • 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):

  • record_confirmed: Meeting will only be recorded if the calendar account has "accepted" it.
  • 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

Because recording preferences build on top of each other, we recommend not exposing them directly to end users. Instead, define a set of preference objects for the use cases your application supports, then apply the appropriate object to each user.

Below are several common use cases and their corresponding preference objects. Any preference key you want omitted from an object 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,
}

For use cases not listed above, contact us in Slack to confirm the appropriate combination of recording preferences.

Customizing the Name of Your Calendar Bots

The calendar bot name can be configured for each user by updating the bot_name preference field. Changes may take a few minutes to propagate to all bots already scheduled for that user.


Bot Deduplication

By default, Recall automatically deduplicates bots across connected calendars within the same Recall workspace, ensuring that only one bot is sent to a meeting. The example below illustrates this behavior:

📘

Bot deduplication example

Let’s say we have:

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)

When a bot is deduplicated across multiple meetings, the calendar_meetings array includes a reference to each associated calendar meeting.

Custom de-deduplication

The Calendar V1 APIs do not support custom bot deduplication logic. To define your own deduplication behavior, we recommend integrating with the Calendar V2 APIs.

Deduplication Constraints

Deduplication only occurs when users’ connected calendars use the same calendar platform. Recall sends one bot per platform represented among the meeting participants.

For example:

  • If all participants use Google Calendar, Recall sends one bot.
  • If participants use both Google Calendar and Microsoft Outlook, Recall sends two bots—one for each platform.


Did this page help you?