Recurring Calendar Events: Issues and Proposed Solutions

Dear Knack Users,

We want to address the recurring events issues you may have been experiencing in our calendar views and provide transparency about the challenges we’re working to resolve. Your feedback has been extremely helpful in helping us understand these pain points, and we want to be transparent about the problems and potential solutions. The specific bugs below are seen in Next-Gen, however, many of the same issues occur in Classic.

Current Issues

1. Limited Editing Capabilities in Monthly View

The Problem: In monthly calendar views, you can only edit the original recurring event, not individual instances. While weekly and daily views allow individual event editing, this inconsistency creates confusion and workflow disruptions.

Impact: Users cannot modify specific occurrences of recurring events when viewing their calendar by month, forcing them to switch views or recreate events entirely.

2. Yearly Recurring Events Display Issues

The Problem: Events set to repeat yearly for a specific number of occurrences often don’t display correctly, appearing inconsistently or not at all after the first year.

Impact: Important annual events like anniversaries, renewals, or yearly meetings may not appear as expected, leading to missed appointments and poor user experience.

3. Incorrect Occurrence Count for Weekly Events

The Problem: When creating weekly recurring events set to repeat 5 times, only 4 occurrences appear (including the original event), resulting in one missing occurrence.

Impact: Users expecting 5 total occurrences only receive 4, disrupting their scheduling and planning.

4. Recurring Events Don’t Create Actual Records

The Problem: This is perhaps our most significant issue in both Classic and Next-Gen. Recurring events only display in calendar views but don’t create individual database records for each occurrence. This means:

  • You cannot count recurring events in reports or calculations

  • Filters don’t recognize recurring event instances

  • Recurring events are invisible to all data operations outside of calendar display

  • Users asking “How many times did this task happen this week?” get zero results, even when recurring events are clearly visible in the calendar

Impact: This fundamentally breaks the data integrity of any application relying on recurring events for tracking, reporting, or business logic. Users cannot build meaningful workflows around recurring events, making this feature essentially decorative rather than functional.

How Other Calendar Applications Handle These Challenges

The industry standard is to allow editing individual occurrences while maintaining the original recurring series.

Google Calendar Approach

  • Single Instance Editing: Modify one occurrence without affecting others

  • This and Following Events: Edit the selected occurrence and all future ones

  • All Events: Modify the entire recurring series

Microsoft Outlook Approach

  • Just This One: Edit only the selected occurrence

  • The Entire Series: Modify all occurrences in the series

  • This and All Following Events: Change the current and future occurrences while preserving past events

Apple Calendar

Same pattern - explicit choice between editing one or all instances.

General No Code/Low Code Standards:

Most other apps with calendars use one of two models:

  1. Single Record with Exceptions: One master record with individual modifications stored as exceptions

  2. Split Series Model: When editing “this and following events,” the original series is trimmed and a new series is created

Proposed Solutions for Knack

Option 1: Implement Three-Choice Model

Allow users to edit any event (not just original event). When editing a recurring event, users would see:

  • Edit This Event Only: Modify just the selected occurrence. This would result in a new record.

  • Edit This and Following Events: Change this occurrence and all future ones. This would result in a new record.

  • Edit All Events: Modify the entire recurring series. This would NOT result in a new record.

Pros:

  • Matches user expectations from Classic

  • Provides maximum flexibility

  • Preserves historical data when editing future events

Cons:

  • More complex to implement

  • May create multiple records for tracking

Option 2: Simplified Exception Model

Allow users to edit any event (not just original event). Offer users:

  • Edit This Event Only: Modify just the selected occurrence. This would result in a new record.

  • Edit All Events: Modify the entire recurring series. This would NOT result in a new record.

Pros:

  • Simpler implementation

  • Reduces user decision complexity

Cons:

  • Less flexible than industry standards

  • Cannot edit “this and following” events

  • May require recreating series for partial changes

Option 3: All-or-Nothing Model

Only allow editing the entire series, not individual occurrences. Remove the “Never End” option to prevent infinite series issues.

Pros: Simplest implementation, avoids counting issues. This would NOT result in a new record.

Cons: Very limiting for users, doesn’t match expectations set by other calendar apps.

Option 4: Hybrid Approach - User Choice for Record Creation

Allow users to choose whether recurring events should create individual records or remain as display-only calendar entries.

Implementation:

  • Display-Only Mode: Current behavior for simple calendar visualization

  • Record Creation Mode: Generate individual records for each occurrence, enabling full data operations

Pros:

  • Addresses the fundamental record creation issue

  • Gives users control based on their specific needs

  • Enables proper counting, filtering, and reporting

Cons:

  • Requires careful record limit management

  • More complex user interface

  • Potential performance impact for long-running series

Safeguards for Record Creation Mode:

  • Limit maximum occurrences (ex: 365 for daily events)

  • Warning system for high-volume recurring events

Addressing the “Never End” Option

We’re considering whether to retain the “Never End” option for recurring events. Here are the considerations:

Arguments for Keeping “Never End”

  • Users may expect this functionality from other calendar applications

  • Useful for ongoing events like weekly team meetings

  • Provides maximum scheduling flexibility

Arguments for Removing “Never End”

  • Simplifies data management and reduces edge cases

  • Prevents infinite series that may cause performance issues

  • Users will set realistic end dates for better organization

We Need Your Input

Before we proceed, we’d love to hear from you:

  • How do you currently use recurring events in your workflows?

  • Have the current bugs caused specific problems for your use cases?

  • Which proposed solution would best meet your needs?

  • Do you rely on the “Never End” option for recurring events?

Please reply with your thoughts, questions, or concerns. We want to get this right!

Cheers,

Kara

1 Like

Hi Kara

Thank you very much for addressing what I consider Knack’s biggest weakness being the Calendar and recurring events.

I would vote for Option 1.

Dean

Option 4 :man_raising_hand:

Option 4 @Kara is my vote.

Appreciate you sharing the details on this.