Event Series
An Event Series in Salesforce is a recurring calendar event defined once and expanded into many individual Event records, one per occurrence, on a schedule you set.
Definition
An Event Series in Salesforce is a recurring calendar event defined once and expanded into many individual Event records, one per occurrence, on a schedule you set. The series stores the repeat pattern (daily, weekly, monthly, or yearly, with an end date or an occurrence count), and Salesforce generates a separate Event row for each date in the run. Editing the series can update every future occurrence, while editing one occurrence detaches just that date so your change does not ripple across the rest.
Event Series live on the same Event object that holds one-off meetings. They power everyday calendar work like a weekly 1:1, a monthly team sync, or an annual review. The current model became generally available in Spring '19 and replaced the older recurring-events feature. It stores the schedule as an iCalendar RRULE string in the Recurrence2PatternText field, flagged by IsRecurrence2, which is a meaningful change for anyone who built reports or code against the original RecurrenceActivityId model.
How Event Series are built and behave
The series record and its occurrences
An Event Series uses a parent-and-occurrence shape. When you save a recurring event, Salesforce keeps a series definition that carries the repeat rule, then writes one Event record for each date the rule produces. In the current model, that definition is identified by IsRecurrence2 set to true, and the pattern itself sits in Recurrence2PatternText. Each visible occurrence is a normal Event you can open, reschedule, or relate to records like any single meeting. This is why a weekly standup that runs for a year shows up as roughly fifty calendar entries, not one. The design matches how Microsoft Outlook and Google Calendar represent repeating meetings, so users moving between tools find the behavior familiar. It also means occurrence-level work, such as logging notes on the specific date a meeting happened, attaches to that one Event and does not bleed onto sibling dates. Understanding this split is the first thing to get right, because reports, automation, and sync all read these records differently depending on whether they target the series rule or the generated occurrences.
Recurrence patterns and the RRULE format
Salesforce supports four repeat frequencies: daily, weekly, monthly, and yearly. Each frequency exposes detail options. Weekly lets you pick specific weekdays, monthly lets you choose a date (the 15th) or a relative position (the third Tuesday), and yearly anchors to a calendar date. Every pattern ends either on a chosen date or after a set number of occurrences. Under the hood, the current model encodes all of this as an iCalendar RRULE string stored in Recurrence2PatternText. A series that repeats every two weeks on Monday and Friday for ten meetings is written as RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=MO,FR;COUNT=10. The FREQ token sets the frequency, INTERVAL sets the gap between runs, BYDAY lists the weekdays, and COUNT caps the total. Companion fields hold the supporting context: Recurrence2PatternStartDate marks the first date, Recurrence2PatternTimeZone records the time zone the rule was authored in, and Recurrence2PatternVersion tracks the pattern format. If you create series programmatically, you build this RRULE text yourself rather than setting the older numeric recurrence fields.
Editing one occurrence versus the whole series
When you change a recurring event, Salesforce asks how far the edit should reach. Choosing to edit only this event detaches that single date from the series so it keeps your change and ignores later series-wide updates. Choosing to edit the whole series rewrites the pattern and pushes the change to every occurrence that has not already been detached. There is no safe undo for these choices, so it pays to pick deliberately. A common mistake is opening one occurrence, nudging the time, and saving across the entire series by accident, which shifts dozens of meetings at once. Detached occurrences are the trickiest side effect. Once an occurrence breaks off, it no longer responds to changes you make at the series level, and it can quietly drift from the pattern your reports assume. If a recurring meeting needs a permanent rename or reschedule going forward, change the series rather than each date. If only one date moves, detach that one. Train users on the prompt wording, because the difference between this event and the whole series is easy to skim past.
Reporting on series and detached occurrences
Reporting on Event Series means reporting on the generated Event records, since those are what hold the meeting data. The Activities and Events report types surface occurrences with their dates, owners, and related records, so you can build views like meetings this quarter or open events by owner. The catch is that occurrences in the current model do not carry the old RecurrenceActivityId series pointer, so you cannot simply group every occurrence back to one series Id the way the original model allowed. Teams that relied on that grouping for the legacy feature have to rethink the report. Detached occurrences add a second wrinkle. Because a detached date is a standalone Event, it still counts in volume reports, but it no longer reflects the live series pattern. If you are auditing how many times a meeting actually occurred, include those detached records or you will undercount. When accuracy matters, validate your report against the calendar for a known series before trusting the totals, especially for long-running weekly meetings that accumulate many edits over time.
API, Change Data Capture, and Data Loader
Event Series records and their occurrences all sit on the Event object in the API, but the current model handles them carefully. The series rule is identified by IsRecurrence2, and the RRULE lives in Recurrence2PatternText. Change Data Capture tracks the series definition in a single change event, while each occurrence in the run produces its own individual change event, so downstream listeners see both the rule and the dates it generated. Bulk operations need the right tools. IsRecurrence2 events can only be deleted with a current version of Data Loader, and older clients will fail on them. There is also a category of series-pattern records that the platform exposes only to Flow, not to the standard UI or API, which can surprise anyone expecting every recurrence artifact to be queryable. The practical takeaway for developers is to read and write the Recurrence2 pattern fields for current series, treat the legacy RecurrenceActivityId fields as the older model, and test bulk deletes and migrations on a sandbox first. Recurring data has more moving parts than a single Event, and assumptions carried over from one-off events often do not hold.
Syncing series with Outlook and Google
Recurring meetings rarely live only in Salesforce. Einstein Activity Capture syncs Event Series to and from Microsoft Outlook and Google Calendar, so a repeating meeting created in one place can appear in the other with its pattern intact. Salesforce shipped support for syncing repeating events with Outlook and later added syncing recurring events from Google to Salesforce, which extended the repeat model across both major calendar providers. Direction still matters. A series authored in Salesforce and pushed outward generally keeps its recurrence cleanly, while a series coming inbound from an external calendar depends on how that source represents the pattern, and edge cases like odd custom intervals or single-occurrence exceptions can translate imperfectly. The older Lightning Sync product, which Salesforce has retired in favor of Einstein Activity Capture, handled recurrence differently and is no longer the recommended path. For teams running hundreds of recurring meetings, leaning on Einstein Activity Capture reduces the duplicate-record noise that older or hand-rolled integrations tend to create when each occurrence is treated as an unrelated event.
Schedule an Event Series in Lightning Experience
Reps create an Event Series the same way they create any event, by adding the repeat options. The Repeat or recurrence control needs to be on the event layout, and the New Event action available wherever reps work. Here is the basic flow for scheduling a recurring meeting in Lightning Experience.
- Open a new event
From the calendar, a record's Activity timeline, or a global action, choose New Event. Enter the subject, the first date, and the start and end times for the meeting.
- Turn on recurrence
Select the Repeat option on the event. Pick a frequency of daily, weekly, monthly, or yearly, then set the detail, such as which weekdays a weekly meeting falls on.
- Set the end condition
Tell the series when to stop. Choose an end date or an occurrence count so Salesforce knows how many Event records to generate for the run.
- Relate and save
Add attendees and related records, then save. Salesforce creates the series and writes one Event for each scheduled date in the pattern.
The name of the meeting. It appears on every occurrence in the series.
The date and times of the first occurrence. The pattern repeats from this anchor.
The frequency and detail of the pattern: daily, weekly, monthly, or yearly, with weekday or date options.
When the series stops. One of these is required so Salesforce can bound the number of occurrences.
- The Repeat option only shows if recurrence is enabled and the field is on the event page layout.
- Editing one occurrence can detach it from the series; editing the series can move every future occurrence at once, so read the prompt before confirming.
- Very long daily or weekly series generate many Event records, which can trigger Apex triggers and automation once per occurrence at save time.
Prefer this walkthrough as its own page? How to Event Series in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Event Series.
Hands-on resources to go deeper on Event Series.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does a single Event Series configuration produce in Salesforce?
Q2. What happens when a user edits a single occurrence of an Event Series rather than the whole series?
Q3. Which field on the Event object marks a record as part of a recurring Event Series?
Discussion
Loading discussion…