Business Central AL Background Processing: Job Queue & Task Scheduler

Business Central applications often need to process work without making the user wait. Large synchronizations, recurring integrations, scheduled calculations, notifications and maintenance tasks are good candidates for asynchronous processing.

1. Why background processing matters

Running a long process directly from a page action can keep the user's session busy and make the application feel slow. Microsoft recommends asynchronous patterns when work can be moved away from the UI thread, including Job Queue, Task Scheduler, StartSession and Page Background Tasks.

For example, a Shopify synchronization that processes thousands of records should generally not require the user to keep a page open while every record is processed.

Microsoft Learn — Performance article for developers

2. The four common async choices

Need recurring user-managed work?
        │
        ├── Yes → Job Queue
        │
Need AL-controlled scheduled execution?
        │
        ├── Yes → Task Scheduler
        │
Need a background session immediately?
        │
        ├── Yes → StartSession
        │
Need read-only page computation?
        │
        └── Yes → Page Background Task

Job Queue

Job Queue provides an application-level way for users to view, create and modify recurring background jobs. It is a strong choice for recurring business processes such as synchronization, imports, exports and scheduled calculations.

Microsoft describes Job Queue as an abstraction built on the platform Task Scheduler.

Microsoft Learn — Job Queue

Task Scheduler

Task Scheduler lets AL code schedule a codeunit to run at a specified date and time. It can also use a failure codeunit and optionally specify a company, earliest execution time and record context.

TaskId := TaskScheduler.CreateTask(
    CodeUnit::"My Background Worker",
    CodeUnit::"My Task Failure Handler",
    true,
    CompanyName,
    CurrentDateTime + 60000);

Microsoft Learn — Task Scheduler

StartSession

StartSession starts code in a separate background session. It can be useful when the application needs to launch work without waiting for the called code to finish in the current user session. It is less controlled than a page background task and is not a replacement for recurring Job Queue scheduling.

Page Background Task

Page Background Tasks are designed for read-only computations associated with a page. They run in a child session and return results to the parent page session. They cannot write to or lock the database.

Microsoft Learn — Page Background Tasks

3. Job Queue architecture

User / Admin
     │
     ▼
Job Queue Entry
     │
     ▼
Task Scheduler
     │
     ▼
Background Session
     │
     ▼
Processing Codeunit
     │
 ┌───┴────┐
 ▼        ▼
Success  Error / Retry
     │
     ▼
Telemetry / Logs

The Job Queue entry contains scheduling information and identifies the object to run. The platform executes the work in a background session and the job queue lifecycle can be observed through status and telemetry.

4. Design a Job Queue codeunit correctly

A job queue codeunit should be focused on one background process. Avoid putting unrelated business processes into a single codeunit simply because the Job Queue can execute it.

codeunit 50100 "Customer Sync Job"
{
    trigger OnRun()
    var
        SyncService: Codeunit "Customer Sync Service";
    begin
        SyncService.Run();
    end;
}

The orchestration codeunit can delegate the actual business work to a reusable service. This keeps the same business logic available to a page action, API or test where appropriate.

5. Never assume a background session has UI

A scheduled task runs without a user interface. Code that works from a page can fail in a background session if it expects dialogs, confirmations or other UI interaction.

if GuiAllowed() then
    Message('Synchronization completed.');

For background processing, prefer logging, notifications through appropriate application patterns, job queue status, telemetry or stored processing results rather than interactive messages.

Microsoft specifically documents GuiAllowed() as useful when the same code can run in the UI, background tasks or web service calls.

6. Permissions in background processing

Background execution does not automatically bypass Business Central security. The task runs using the permissions associated with the user or execution context that scheduled or invoked the operation.

Therefore, a job that works for an administrator can still fail for a normal operational user because the background codeunit or its related table operations require permissions that user does not have.

Microsoft Learn — Task Scheduler: task sessions and permissions

7. Error handling and retries

Background processing needs a deliberate failure strategy. A useful design distinguishes between transient failures and permanent business errors.

• Transient: temporary database/network/service failure that may succeed on retry.
• Permanent: invalid setup, missing configuration or invalid business data that requires correction.
• Business rejection: the external system or Business Central business rule explicitly rejects the operation.

The Task Scheduler has retriable exception behavior, and Job Queue provides failure and retry behavior through its background processing lifecycle. Do not blindly retry an operation that is not idempotent.

8. Idempotency is critical

Suppose a job sends an order to an external system and the network connection fails after the external system has already accepted the order. A retry could create a duplicate unless the integration has an idempotency strategy.

Order
  │
  ▼
Create unique external request key
  │
  ▼
Send request
  │
  ├── Success → store external ID
  │
  └── Timeout → retry safely using same key

For integrations, store an external reference or unique request identifier where appropriate. A background job should be designed with the possibility that the previous attempt may have completed even when the local session did not receive a successful response.

9. Avoid overlapping jobs

A recurring job can start again while a previous execution is still processing if the schedule and workload are not designed carefully. This can create duplicate work, locking and unnecessary API traffic.

For high-volume synchronization, consider a processing status, checkpoint, batch identifier or other concurrency-control mechanism that matches the business process.

10. Keep transactions and external calls separate

Background execution does not make transaction design irrelevant. A background job that holds database locks while waiting for an external API can still create contention.

Read / prepare
      ↓
Build request
      ↓
External API call
      ↓
Validate response
      ↓
Focused database update
      ↓
Commit

The exact order depends on the business requirement, but the goal is to avoid holding database resources during unnecessary network latency.

11. Task Scheduler example

Task Scheduler can schedule a codeunit to run after a specified point in time.

var
    TaskId: Guid;
begin
    TaskId := TaskScheduler.CreateTask(
        CodeUnit::"AI Analysis Worker",
        CodeUnit::"AI Analysis Failure",
        true,
        CompanyName,
        CurrentDateTime + 60000);
end;

The platform documentation shows that CreateTask accepts the codeunit ID, optional failure codeunit, readiness flag, company, earliest execution time and optional record ID depending on the overload.

Microsoft Learn — TaskScheduler.CreateTask()

12. Page Background Task example

When a page needs a read-only calculation that should not block the user, a page background task can enqueue a codeunit and return results through a dictionary.

var
    TaskId: Integer;
    Parameters: Dictionary of [Text, Text];
begin
    Parameters.Add('CustomerNo', Rec."No.");

    CurrPage.EnqueueBackgroundTask(
        TaskId,
        CodeUnit::"Customer Analysis Task",
        Parameters,
        60000,
        PageBackgroundTaskErrorLevel::Warning);
end;

The background codeunit can read data and return a result with SetBackgroundTaskResult. The parent page can handle the result in OnPageBackgroundTaskCompleted.

Because page background tasks are read-only, they are not suitable for posting documents or modifying application data.

13. Background tasks and page lifecycle

Page background tasks are tied to the parent page and current record. Microsoft documents that the task can be canceled if the page closes or the current record changes. This makes them different from a Job Queue process, which is independent of a user's open page.

For list pages, enqueueing a task from OnAfterGetRecord requires special care because that trigger executes for multiple records and the current record can change.

14. Performance considerations

Asynchronous processing is not automatically faster. It moves work away from the foreground session, but background workloads still consume database, CPU, memory and external-service capacity.

• Do not schedule polling more frequently than the business need requires.
• Split very large workloads into safe batches.
• Avoid multiple jobs processing the same records.
• Run heavy recurring jobs outside peak user hours when appropriate.
• Measure query and processing time instead of guessing.
• Use telemetry to understand failures and execution duration.

Microsoft notes that frequently recurring or heavy jobs can affect Business Central performance and can contribute to locking and deadlock issues.

15. Monitoring and telemetry

Production background processing should be observable. Job Queue lifecycle telemetry includes events for enqueueing, starting, finishing, failures and other state changes. Task Scheduler can also be monitored through telemetry and session events.

This gives operations teams evidence about whether a job actually ran, how it ended and whether failures are recurring.

Microsoft Learn — Analyzing Job Queue Lifecycle Trace Telemetry

16. AI + Business Central example

For an AI-enabled Business Central application, background processing can separate the user experience from expensive analysis.

User selects Customer Analysis
          │
          ▼
Create analysis request
          │
          ▼
Background worker
          │
    ┌─────┴─────┐
    ▼           ▼
Build context  Read BC data
    │           │
    └─────┬─────┘
          ▼
      AI service
          │
          ▼
Validate response
          │
          ▼
Store analysis result
          │
          ▼
User reviews result

This pattern can be useful for non-interactive AI analysis, provided the application controls the data sent to the model, validates returned content and keeps transaction-changing actions under explicit business rules.

17. Job Queue vs Task Scheduler vs Page Background Task

18. Interview-ready answer

19. Production checklist

• Is the work really suitable for asynchronous execution?
• Should users control the schedule?
• Can the process safely run more than once?
• Is it idempotent if an external call times out?
• Could two workers process the same records?
• Does the code assume a UI exists?
• Does the execution context have the required permissions?
• Are external calls separated from critical database locks?
• Are failures observable and actionable?
• Is the schedule frequent enough for the business need without creating unnecessary load?

Conclusion

Background processing is a core Business Central architecture skill. The right choice is not simply “run it in a Job Queue.” Experienced AL development means selecting the mechanism that matches scheduling, UI dependency, write requirements, concurrency, retry behavior and operational needs.

For interview preparation, remember the distinction: Job Queue for scheduled business jobs, Task Scheduler for AL-controlled scheduling, StartSession for background sessions, and Page Background Tasks for read-only page-bound work.

Sources & references

• Microsoft Learn — Job Queue
• Microsoft Learn — Task Scheduler
• Microsoft Learn — Page Background Tasks
• Microsoft Learn — Performance article for developers
• Microsoft Learn — Job Queue Lifecycle Trace Telemetry