Skip to main content
Use the Outlook Calendar destination to write records from your ETL pipeline to a Microsoft Outlook calendar. The component creates one event per input record. When a record includes an event id, the component updates that event instead.
Mapping attendees sends real meeting invitations to every address on every record that succeeds. Test on a small sample and a test calendar before running against a full dataset.

​
When to use it

  • Put campaign, project, or booking dates from a CRM or database on a shared calendar.
  • Keep calendar events in sync with a source system by updating events you created earlier.
  • Copy events from one calendar to another together with the Outlook source.

​
Connection

Select an Outlook connection. The connection uses delegated OAuth, so the destination writes events as the Microsoft user who signed in. The mailbox is part of the connection: the signed-in user’s own, or a shared mailbox whose address is set on the connection. A token that expires during a job is refreshed automatically. See the Outlook source for more about the connection.

​
Destination properties

  • Calendar. Select the calendar by name. Only calendars the signed-in user can edit are listed. If the user can’t edit the mailbox’s default calendar, it is shown as (default calendar, read-only) and can’t be selected. If the selected calendar is removed from the mailbox, or the user loses access to it, the editor won’t save until you pick another calendar.
  • Time zone. Required. All-day events, and start and end values without a UTC offset such as 2026-10-01 09:00, are placed in this zone. Values with an offset keep it. A mapped timeZone field overrides it for that record.
  • Requests per second. Each record is one request to Microsoft Graph. Greater than 0 and at most 15. Defaults to 4.

​
Field mapping

Map each input field to an Outlook event field. Auto-fill maps input fields whose names match event fields, and also maps the Outlook source’s start_time, end_time, is_all_day, and show_as to start, end, isAllDay, and showAs. Auto-fill never maps id or attendees, so you have to map those yourself. A blank or null value is left out of the request, so an update never clears a field you didn’t supply.

​
Create or update

  • A record without id creates a new event.
  • A record with id updates that event. Only id is required for an update. Any other mapped fields are changed.
The editor won’t save the component until subject and start are mapped. If id is mapped, no other field is required. To update events later, read their id with the Outlook source. Both components use immutable IDs, so the IDs match.

​
Fields

Enum values are case-insensitive. A value that isn’t valid fails the record instead of being written with missing fields.

​
Dates and all-day events

  • A date-time with an offset, such as 2026-10-01T15:00:00Z, or a datetime field is written as that exact instant.
  • A date-time without an offset, such as 2026-10-01 15:00, is read in the record’s timeZone or the component’s time zone.
  • A text date without a time, such as 2026-10-01, creates an all-day event unless isAllDay is mapped to false.
  • A datetime field at midnight UTC, such as a Salesforce date field, creates an all-day event on that day only when isAllDay is mapped to true. Otherwise it creates a timed event at 00:00 UTC.
  • The end of an all-day event is inclusive. A start of 2026-10-01 and an end of 2026-10-02 creates an event that covers both days.
  • On an update, the event switches between all-day and timed only when isAllDay is mapped.

​
Attendees

attendees accepts any of these:
  • Addresses separated by commas or semicolons, such as ana@example.com; ben@example.com.
  • The JSON array that the Outlook source returns in its attendees field.
  • A bag or tuple of addresses.

​
Errors and retries

  • Requests throttled by Microsoft Graph (HTTP 429), and HTTP 503 and 504 responses, are retried after the wait time Graph returns. Other 5xx responses are retried with a growing delay. A request is retried up to 5 times.
  • If a create gets no confirmation after its retries, the record fails with a message that the event may exist. Check the calendar before you rerun so you don’t create it twice.
  • If the signed-in user can’t write to the calendar (HTTP 403), a create stops the job. On an update, that record fails.
  • An update for an event that no longer exists (HTTP 404) fails that record.
A failed record fails the job. Events written before the failure stay in the calendar, so check which records were written before you rerun.

​
Example: Salesforce campaigns to a shared calendar

Read Salesforce Campaign records. Add a Select component that passes the fields through and adds a field isAllDay with the value true. Then map: Salesforce date fields arrive as datetimes at midnight UTC. Because isAllDay is true, each campaign becomes an all-day event covering its first through last day.
Last modified on October 7, 2026