## Key Outcomes

The meeting resolved critical issues with disappearing tasks and established a comprehensive solution for handling client renewal dates. All tasks prior to April 1, 2026 will be marked complete to clear historical backlog, and a new client-level renewal date field will be implemented to ensure consistent task generation across different renewal group configurations. 
## Decisions Made

### Task Visibility and Historical Data

- **Mark all tasks before April 1, 2026 as complete** to eliminate the backlog of 599+ overdue tasks that were causing confusion across user dashboards 
- **Standardize overdue task definition** across all system views (tasks page, manager page, and workload page) to mean: past the due date, not marked as N/A or completed, with no lower bound restriction 

### Client Renewal Date Logic

- **Add a "Client Renewal" date field** at the client level that will be editable by managers and serve as the source of truth for client-level tasks 
- **Implement automatic date suggestion logic** using the following priority: (1) default/starred group renewal date, (2) if only one group exists, use that group's date, (3) if only individual policies exist, use policy date 
- **Allow manual override** of the suggested client renewal date during client setup to accommodate complex scenarios like transportation clients with multiple renewal groups 

### Meeting Cadence

- **Establish weekly or bi-weekly recurring meetings** short-term to ensure system issues are addressed promptly 
- **Explore adding in-app functionality** for submitting change requests or bug reports that can be quickly triaged as either bugs for immediate fixes or design issues requiring meetings 

## Issues Resolved

### Disappearing Tasks Problem

- **Root cause identified**: Original 7-day visibility window was removed to address initial backlog, but this caused legitimate overdue tasks to accumulate without being hidden 
- **Dashboard inconsistencies**: Task counts differed between primary dashboard and task dashboard due to three different overdue definitions being applied across different system views 
- **Example case**: Mimi showed 599 past due tasks in one view but only 2 in another view 

### JG Contracting Renewal Task Generation Failure

- **Problem**: Client with January 1, 2027 renewal wasn't generating expected claim review tasks in April and August 2026 
- **Root cause**: System was following the June 30 renewal date of a single unassigned policy instead of the January 1 date of the main renewal group containing the bulk of policies 
- **Why it happened**: System used "nearest to year start" logic (default date rule) which selected June 30 as closer to year start than January 1, applying this to client-level tasks 
- **Evidence**: Client-level tasks appeared at 275 days before June 30 (September 28) and 90 days before June 30 (April 1), confirming they followed the wrong renewal date 

### Group Numbering Confusion

- **Issue**: JG Contracting's single renewal group was labeled "Group 2" instead of "Group 1" 
- **Explanation**: Group functionality and UI were built on different days, causing inconsistent labeling logic 

## Technical Implementation Details

### Task Status Update Execution

- **Bulk update completed**: 3,292 tasks with due date before April 1, 2026 and status "not started" were marked as completed 
- **Logging implemented**: Bulk changes are now logged to track why large numbers of tasks changed status 
- **Potential issue identified**: Some tasks that were previously marked complete after April 1 may have been reset to "not started" - requires investigation 

### Task Source Tracking

- **New icon added**: Small settings icon appears next to policies on the right side of the screen to show where tasks originated from 
- **Helps debugging**: Allows users to trace which renewal date or policy group generated specific tasks

### Client Renewal Date Field Implementation

- **Location**: Will appear in the client setup screen alongside existing renewal group configuration 
- **Label**: "Client Renewal" to allow future reuse for other purposes beyond just tasking 
- **Behavior**: Auto-populated by logic on client creation but editable by managers at any time 
- **No automatic overwriting**: Once set, the date won't change automatically unless a specific triggering action occurs 

## Complex Scenarios Addressed

### Transportation Clients with Multiple Renewal Groups

- **Use case**: Clients with auto and motor truck cargo renewing 1/1, but AUCAC and truck broker liability renewing 3/1 
- **Challenge**: System must allow selection of which group's renewal date should drive client-level tasks 
- **Solution**: Manager can manually select the appropriate renewal date during setup, typically following the "big line" (highest premium policy) 

### Single Policy vs. Multiple Groups

- **Single policy scenario**: If client has only one policy with no groups, system will use that policy's renewal date 
- **Multiple groups scenario**: System will follow the starred/default group's renewal date 
- **Override capability**: Regardless of automatic selection, managers can change the client renewal date if business logic dictates otherwise 

## Pending Confirmation

- **Task reset investigation needed**: Verify whether tasks completed after April 1, 2026 were incorrectly reset to "not started" during the bulk update 
- **Sync date range behavior**: Confirm that policy syncs only capture policies within the specified date range (e.g., a policy starting 8/1/25 expiring 8/1/26 would be missed if sync runs for 1/1/26-12/31/26) 

## Technical Specifications

### Overdue Task Definition (Standardized)

- **Criteria**: Task is overdue if all of the following are true:
    - Due date is before today 
    - Status is NOT "N/A" 
    - Status is NOT "Completed" 
    - No lower bound date restriction (perpetual visibility) 

### Task Generation Logic Hierarchy

1. **Client-level tasks**: Follow the client renewal date field 
2. **Group-level tasks**: Follow their specific group's renewal date 
3. **Policy-level tasks**: Follow individual policy renewal dates 

### Default Date Rule Logic (Pre-Fix)

- **Original behavior**: Selected renewal date nearest to start of year across all policies and groups 
- **Problem**: Did not account for which policies/groups were primary or contained bulk of coverage 
- **New behavior**: Will populate suggested client renewal date but allow override 

## Action Items

- **Lawrence**: Implement client renewal date field in client setup screen with auto-population logic and manual override capability 
- **Lawrence**: Investigate and resolve task reset issue where completed tasks after 4/1 may have been changed to "not started" 
- **Lawrence**: Update sync date range to clearly indicate which policies will be captured based on effective/expiration dates 
- **Luke**: Set up weekly or bi-weekly recurring meeting with Lawrence to review ongoing system issues 
- **Luke**: Review task counts across all users to verify the April 1 bulk completion resolved dashboard inconsistencies 

## Open Questions

### Task Visibility After Bulk Update

- Why are some tasks showing different statuses than expected after the bulk completion of pre-April 1 tasks? 
- Are there any completed tasks from April 2026 onwards that were incorrectly reset? 

### Sync Functionality

- Does the sync date range need to be adjusted to capture policies with effective dates before the sync year but expiration dates within it? 
- Should sync default dates be modified to be more inclusive of cross-year policies? 

## System Behavior Notes

### Task Page vs. Dashboard Discrepancies (Pre-Fix)

- **Tasks page**: Counted all overdue tasks with no lower bound 
- **Manager page**: Used configurable overdue window (last 30 days only) 
- **Workload KPI**: Counted all tasks including unassigned ones 
- **Result**: Same user could see vastly different overdue counts depending on which view they accessed 

### Renewal Group Star Functionality

- **Purpose**: Star indicates the default renewal group that should drive client-level task generation 
- **Previous assumption**: System was following starred groups for client-level tasks 
- **Actual behavior**: System was using "nearest to year start" logic instead, ignoring the star designation 

### Policy Sync Date Range Default

- **Current behavior**: Sync defaults to current calendar year (1/1/26 - 12/31/26) 
- **Limitation**: Policies with effective dates in previous year but expiration in current year will be missed unless date range is manually adjusted 

## Next Meeting

- **Frequency**: Weekly or bi-weekly to be scheduled 
- **Topics**: Continue working through system functionality issues and enhancements
- **Participants**: Luke, Lawrence, potentially Dawn and Christy as needed