Skip to main content
With our Salesforce integration you can sync data between Cal.com and your instance of Salesforce.

​
Basic functionality

  • On booking, we create an event record under a lead/contact record
  • On reschedule, we adjust the event record’s dates
  • On cancellation, we delete the event record

​
Event Type Options

​
On booking, add events on and new attendees as

Choose which record to create Salesforce events under or if the attendee does not exist in Salesforce as the selected record create a new record of the chosen type. We search for records based on the attendee email. Options
  • Contact
  • Lead
  • Contact under an account

​
Do not create new records for guests added to the booking

If this option is enabled, we will only handle creating events under the main attendee of the event and not additional guests

​
Skip creating contacts if they do not exist in Salesforce

This option is available when adding events on contacts. If the option is enabled, skip creating new contacts if they do not exist in Salesforce already.

​
Create event on contact, if it exists. Else fallback to lead

This option is available when adding events on leads. If this option is enabled, we check if a contact already exists with the attendee’s email. If it does, create the event on the contact record. If it does not exist, then we create the event on an existing lead record or create a new lead

​
Create a new contact under an account based on email domain of attendee and existing contacts

This option is available when adding events on leads or a contact under an account. If this option is enabled, we create a new contact under an account if it does not already exist then create an event under that new contact. Determining which account an attendee belongs to

​
If the contact does not exist under an account, create new lead from attendee

This option is available when adding events on contacts under an account. If a contact under an account does not exist, then create a new lead record.

​
On booking, write to event object

When a booking is created, you can write to specific fields on the event record. To write to a field you need the following:

​
On booking, write to a custom field on the attendee record

This option writes to fields on the type of record that is set to create events on. To write to a field you need the following:
  • The API field name ex. Custom_Field__c
  • The field type in Salesforce. We current support the following types:
    • Text (text, textarea )
    • Date (date, datetime)
    • Phone
    • Checkbox
    • Picklist
    • Custom (ignores field validations)
  • The value that you want to pass to the field (Mapping data from Cal.com to Salesforce)
    • For checkbox fields, you can choose whether to pass true or false
    • For picklist fields, the value passed needs to match the value of a picklist option
  • When to write to the field
    • When the field is empty
    • On every booking, overwriting the previous values

​
Change record owner on booking

If you have an integration account that is creating records in Salesforce, you can pass the integration account name and Cal.com will change the owner of the attendee record to the organizer of the booking.

​
If attendee exists in Salesforce, book directly with the owner

This option is available for round robin events. When this option is enabled, you can pass ?email as a URL param in the round robin booking link, Cal.com searches Salesforce for the record owner. If the record owner is a host of the round robin event, then only that owner’s availability is presented and the attendee books directly with the owner. Options to search ownership against

​
Field rules for round robin skip

When the round robin ownership check is enabled, you can add field rules to control when the ownership check applies. Each rule has a field name, a value, and an action:
  • Ignore — if the Salesforce record’s field matches this value, the ownership check is skipped and normal round robin logic is used instead.
  • Must include — only route directly to the owner if the record’s field matches this value.
For example, you could add a rule with Field Name Industry, Value Technology, and Action Must include to only skip round robin when the account is in the Technology industry.

​
If attendee has a free email domain, skip the ownership check and round robin as normal

If this option is enabled, if the attendee has a free email domain (ex. gmail.com) then ignore any Salesforce ownership checks.

​
On cancelled booking, write to event record instead of deleting event

When this option is enabled, instead of deleting the event record we write to specific fields. To write to a field you need the following:
  • The API field name ex. Custom_Field__c
  • The field type in Salesforce. We current support the following types:
    • Text (text, textarea )
    • Date (date, datetime)
    • Phone
    • Checkbox
    • Picklist
    • Custom (ignores field validations)
  • The value that you want to pass to the field (Mapping data from Cal.com to Salesforce)
    • For checkbox fields, you can choose whether to pass true or false
    • For picklist fields, the value passed needs to match the value of a picklist option
  • When to write to the field
    • When the field is empty
    • On every booking, overwriting the previous values

​
On cancelled booking, write to a custom field on the attendee record

When this option is enabled, cancelling a booking updates fields on the attendee’s contact or lead record in Salesforce. This is useful when you want to track cancellation status directly on the person’s record rather than (or in addition to) the event record. To configure, provide:
  • The API field name ex. Custom_Field__c
  • The field type in Salesforce. We current support the following types:
    • Text (text, textarea )
    • Date (date, datetime)
    • Phone
    • Checkbox
    • Picklist
    • Custom (ignores field validations)
  • The value that you want to pass to the field (Mapping data from Cal.com to Salesforce)
    • For checkbox fields, you can choose whether to pass true or false
    • For picklist fields, the value passed needs to match the value of a picklist option
  • When to write to the field
    • When the field is empty
    • On every cancellation, overwriting the previous values
You can use both the “write to event record” and “write to attendee record” options together. For example, you might mark the event as cancelled while also updating a status field on the contact or lead.

​
Send no show attendee data to event object

When this option is enabled, we set the specific checkbox field to true when an attendee is marked as no-show in Cal.com

​
Appendix

​
Determining if an attendee belongs under an account

We determine if an attendee belongs under an account in the following order:
  1. If there is a contact that matches the attendee’s email that belongs to an account, use that account.
  2. If there is an account where the Website field matches the email domain of the attendee. Cal.com checks common URL formats first (e.g. acme.com, https://www.acme.com). If no exact match is found, Cal.com normalizes the Website values by stripping protocols, paths, ports, and trailing slashes before comparing. This means accounts with website values like https://www.acme.com/about/ or HTTP://ACME.COM:443/en/ still match an attendee with an @acme.com email.
  3. If no account is found by website, Cal.com looks at contacts that share the same email domain as the attendee and selects the account that the majority of those contacts belong to.
  4. If fuzzy domain matching is enabled, Cal.com extracts the base domain from the attendee’s email (for example, acme from acme.co.uk) and matches it against account website values across different top-level domains. This means an attendee with an @acme.co.uk email can match an account with acme.com as its website. Free email domains like gmail.com are automatically excluded from fuzzy matching.
If multiple accounts match at any step, Cal.com uses a tiebreaker waterfall to pick the best match. Accounts are compared in order by number of child accounts, number of opportunities, number of contacts, most recent activity, and earliest creation date.

​
Fuzzy domain matching

Fuzzy domain matching extends the account lookup to handle cases where the attendee’s email domain uses a different top-level domain (TLD) than the account’s website. For example, a prospect with an @acme.co.uk email address is matched to a Salesforce account with acme.com as the website. To enable fuzzy domain matching, toggle Match accounts by base domain across TLDs using fuzzy matching in the Salesforce event type settings. This option appears when “Add new attendees as” is set to Contact under an account or Lead.
Fuzzy domain matching is only available when the feature has been enabled for your organization. Contact support if you do not see this option.

​
Exclude account record types

You can exclude specific Salesforce account record types from being matched during the account lookup. This is useful when you have account types like “Partner” or “Vendor” that should not be used for routing or contact creation. Enter a comma-separated list of record type names in the Exclude account record types field. For example: Partner/Alliance, Vendor. Any account with a matching record type is filtered out during all account matching steps (website match, contact domain match, and fuzzy match).

​
Sync error notifications

If a Salesforce API write fails when creating or updating records, a notification banner appears at the top of the Salesforce event type settings. The banner shows the error code, error message, and any fields that were dropped from the payload to allow the remaining data to sync. You can dismiss the notification after reviewing the error.

​
Mapping data from Cal.com to Salesforce

When writing to fields in Salesforce, you can pass data from different sources in Cal.com
  • To pass a static value, input the value in the Value field
  • To pass a value from a booking question, wrap the identifier of the booking question in {} brackets. For example, if you have a booking question with the identifier productInterest you would input {productInterest} in the Value field
  • To pass a value from a routing form, wrap the identifier of the field of you want to pass in {} and add the form: prefix. For example, if the field identifier is productInterest you would input {form:productInterest} in the Value field
  • To pass a utm_parameter, pass the parameter name as {utm:parameter} in the value field. We currently support the following:
    • utm_source as {utm:source}
    • utm_medium as {utm:medium}
    • utm_campaign as {utm:campaign}
    • utm_term as {utm:term}
    • utm_content as {utm:content}