Bulk Action Framework

Overview

Starting from the 2026.04 release, the BHHV framework has been enhanced to support chained queueables as an alternative processing mechanism for bulk actions. This change preserves user context throughout processing, enabling correct audit trails, field-level security (FLS) enforcement, and sharing rule application — while avoiding the platform event publication limits that would be introduced by platform event triggered flows.

Background

Previously, the BHHV framework processed bulk actions via platform events only. This approach presented a significant challenge:

  • Loss of user context — the originating user's identity (UserId) was not preserved during high-volume event processing, causing issues with audit trails, FLS enforcement, and subsequent work assignment.

The new chained queueable mechanism addresses precisely this issue.

More on Chained Queueable Processing

With Chained Queueable Processing, bulk actions can be processed using a chained queueable pattern, where each chunk is executed in an isolated transaction. This ensures:

  • The originating user's context is preserved throughout processing, maintaining correct audit trail entries, FLS enforcement, and sharing rule application.

  • Failures in one chunk do not prevent other chunks from being processed.

Retry Logic with Back-off

Consider the following: Platform Events are processed serially across all BHHV jobs. Every chunk from every job is in that queue. Chained Queueables on the other hand are processed serially within the same BHHV job. This means chunks from different jobs can be processed in parallel, and the risk of row locking is increased. This is why a Retry Logic with Back-off is needed now that Chained Queueables is leveraged.

If a chunk encounters a transient error (such as row locking), it will be automatically retried using back-off logic to reduce contention. Once a chunk has exhausted all retry attempts, the failure is recorded using the existing BHRC logging mechanism.

Technical Considerations

The following Salesforce platform limits are relevant to this implementation and have been accounted for in the design:

  • Maximum 50 queueable jobs enqueued per transaction.

  • Maximum queue depth of 5 for chained queueables in synchronous contexts; effectively unlimited in asynchronous contexts.

  • Only 1 queueable may be enqueued per queueable execution (no fan-out within a single job).

  • 250,000 async Apex executions per 24 hours (or the number of user licences × 200, whichever is greater), shared across all async types.

Related Components