Hours Distribution Bulkification Trigger

[edunzer]

Problem

Creating 20+ records in a single transaction causes per-record Flow automation to hit governor limits.
The Flow logic cannot be bulkified and must continue to run per record.
This issue occurs regardless of creation source (UI, API, data load, or other automation).

---

Goal

• Preserve existing per-record Flow logic
• Prevent governor limit failures on bulk record creation
• Support all creation sources
• Run processing immediately (no schedulers)
• Avoid duplicate processing and cross-user interference

---

Proposed Solution

Introduce an async bulk-handling pattern that splits large inserts into smaller processing batches while still triggering the same per-record Flow.

This update removes the kickoff flag and instead uses a status transition to trigger processing.

Key components:

• Transaction-scoped HoursDistro_Sync_RunKey (Text)
• Pending → Processing → Done status model using HoursDistro_Sync_Status
• Queueable Apex worker processing records in small chunks (e.g. 20)
• Existing per-record Flow triggered by status change

---

High-Level Design

1. Before Insert

   • Assign a single HoursDistro_Sync_RunKey per transaction
   • Set:
     • HoursDistro_Sync_Status = 'Pending'

2. After Insert

   • Enqueue one Queueable job per transaction (static guard)
   • Pass HoursDistro_Sync_RunKey to the worker

3. Queueable Worker

   • Query up to 20 records with:
     • HoursDistro_Sync_RunKey = <run key>
     • HoursDistro_Sync_Status = 'Pending'
     • FOR UPDATE
   • Update records to:
     • HoursDistro_Sync_Status = 'Processing'
   • This update triggers the existing per-record Flow
   • Chain another Queueable if Pending records remain

4. Existing Flow (unchanged logic)

   • Runs only when HoursDistro_Sync_Status changes to Processing
   • Executes current per-record logic
   • Sets HoursDistro_Sync_Status = 'Done' on completion

---

Benefits

• Bulk-safe without bulkifying Flow logic
• Near-immediate execution after commit
• Source-agnostic (UI, API, data load, automation)
• Concurrency-safe and idempotent
• Clear, debuggable processing state
• No schedulers or per-record async jobs

[edunzer]

Handled through other means