Async Job Group Overview

Async Job Group provides a way to manage and organize background operations within the org. The Async Job Group offers several key advantages for robust and auditable asynchronous processing:

  • Consolidate related jobs together for clearer organization and management.
  • Maintain a comprehensive history of all jobs executed within a group, making it easy to track progress and troubleshoot issues.
  • Efficiently signal the cancellation of all jobs belonging to a specific group, providing a clean way to stop ongoing processes.
  • Establish sophisticated dependency chains, ensuring jobs execute in a predefined order.

Every job record is automatically assigned to a job group. This can happen explicitly by the administrator or implicitly by the framework. When a job is implicitly assigned, it will either:

  • Inherit the job's group if another job initiated the current job.
  • A new default group will be created and assigned if no existing group can be adopted.
Warning:

While adopting job groups can be beneficial, you need to be aware of their impact on dependency chains.

For example, if Job 2 depends on Group 2, and new jobs are added to Group 1 without specifying a job group, these will also join Group 1. This prevents Group 1 from completing and delays Group 2 until all new jobs finish.

This behavior ensures related work is finished. However, for independent or perpetual jobs, set its group explicitly to prevent it from becoming dependent and blocking other processes.

User Mode and Delegated System Mode

Depending on the requirement, you can run the async job groups in the User Mode and the Delegated System Mode.

By default, async jobs run in user mode. This mode is typically used for processes directly submitted by the current user, such as those triggered by a user interface interaction.

  • Immediate Resource Check: If insufficient resources are available to enqueue the job immediately, an exception is thrown.
  • No Dependent Jobs: You cannot create or utilize job dependencies in the user mode.
Notes:
  • You must avoid enqueueing user mode jobs from triggers. If the job cannot be enqueued due to resource constraints, it can unexpectedly cause the batch or async job that invoked your trigger to fail.
  • We recommend that you always use the Delegated System Mode when enqueuing jobs from within triggers to ensure the stability of your system's consumers.
  • In the user mode, a user's job is expected to run promptly. Therefore, if there aren't enough resources to enqueue it immediately, an error is thrown. You must handle this error appropriately.
  • If a user's job fails to enqueue, it indicates either a bug or that the process should have been a system job.

The Delegated System Mode offers elevated benefits and is designed for more complex, robust background processes.

  • If a job cannot be enqueued immediately due to insufficient resources, no error is thrown. Instead, the async job remains in an Enqueued state until the Job Monitor can process it.
  • The Job Monitor and other workers automatically run if resources are available and they are not already active.
  • You can create and manage job dependencies, enabling complex workflow orchestration.
Note:

A system job should be executable regardless of the running user's permissions. Therefore, we recommend that you do not add FLS checks to your System Jobs, and pay close attention to the sharing modifier of your Apex classes to ensure they run with appropriate access.

For more information, see Running Asynchronous Jobs in Delegated System Mode.