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:
-
Single Record with Exceptions: One master record with individual modifications stored as exceptions
-
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