# Bc Job Queue

> >

- **Type:** Skill
- **Install:** `agentstack add skill-fernandoartalf-al-copilot-skills-collection-bc-job-queue`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [fernandoartalf](https://agentstack.voostack.com/s/fernandoartalf)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [fernandoartalf](https://github.com/fernandoartalf)
- **Source:** https://github.com/fernandoartalf/AL-Copilot-Skills-Collection/tree/main/skills/bc-job-queue
- **Website:** https://alcopilotskills.com/

## Install

```sh
agentstack add skill-fernandoartalf-al-copilot-skills-collection-bc-job-queue
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Business Central Job Queue Skill

## Purpose

Use this skill to design or troubleshoot Job Queue solutions in Business Central
with a development-first focus. Prefer official platform and Base Application
APIs, keep generated code safe for background sessions, and inspect target
runtime symbols before relying on method signatures or event contracts.

## Scope Boundaries

- In scope: AL design, enqueueing, parameter contracts, retry strategy, recovery, telemetry, and diagnostics.
- Out of scope: tenant administration runbooks, infrastructure-only monitoring, and customer-specific operational data.
- Always verify the target runtime symbols for `Job Queue Entry`, `Job Queue - Enqueue`, and `Job Queue Management` before generating final AL.

## Decision Rule

Choose the async primitive before writing code.

| Need | Prefer |
| --- | --- |
| User-managed schedule, recurrence, Business Central logs, admin UI | Job Queue |
| One-shot queued background task without Business Central admin UI | Task Scheduler |
| Immediate background execution from current flow | StartSession |
| Read-only work bound to an open page | Page Background Task |

Use Job Queue when the user must be able to inspect entries, change scheduling,
re-run jobs, or review logs in Business Central.

## Working Sequence

1. Confirm that Job Queue is the right primitive.
2. Choose the creation pattern.
3. Define the parameter contract.
4. Make the runnable object background-safe and retry-safe.
5. Add recovery and diagnostics before considering the work complete.

## Knowledge Block 1: Create / Enqueue

Use this block when the user asks to create a new background process, schedule it,
or expose configuration that results in a Job Queue Entry.

### Core Rules

1. Prefer Job Queue over raw `TaskScheduler.CreateTask` when end users need to see or modify the schedule.
2. If the runtime exposes a suitable helper, prefer table methods such as `ScheduleJobQueueEntry`, `ScheduleJobQueueEntryWithParameters`, `ScheduleJobQueueEntryForLater`, or recurrent scheduling helpers.
3. If you need full control over the entry, initialize `Job Queue Entry` explicitly and enqueue it through `Codeunit::"Job Queue - Enqueue"`.
4. Set the minimum viable fields for manual creation: object type, object id, description, earliest start, retry policy, and parameter payload.
5. Use category codes only when serialized execution is intentional.
6. Reports can be scheduled as Job Queue objects, but report execution paths must still avoid UI-only behavior and should use report parameter helpers for request page payloads.

### Creation Checklist

- Is the target object a codeunit or report that can run without UI?
- Does the request need one-shot, delayed, or recurrent execution?
- Will the execution user have permissions for all called objects?
- Are retry settings explicit instead of implicit defaults?
- Is the description stable enough for operations and support?

### Red Flags

- Polling too frequently instead of using a better trigger.
- Creating many near-duplicate entries that should be one parameterized job.
- Encoding business meaning only in `Description`.

## Knowledge Block 2: Parameterize

Use this block when the background code needs business context.

### Core Rules

1. Prefer `TableNo = "Job Queue Entry"` on the runnable codeunit when the job consumes `Parameter String`, `Record ID to Process`, or report parameter payloads.
2. Keep `Parameter String` deterministic, culture-neutral, and compact.
3. Use `Record ID to Process` when the job acts on one specific record and identity matters more than text parsing.
4. For richer report payloads, use XML or report parameter helpers instead of overloading `Parameter String`.
5. Parse and validate parameters at the entry point before doing business work.

### Parameter Design Heuristics

- Prefer machine formats such as `YYYYMMDD`.
- Prefer stable identifiers over captions.
- Keep parsing local and fail fast.
- If the payload is larger than the field limit, persist the payload elsewhere and pass a lookup key.

### Anti-Patterns

- Locale-dependent parsing based on user language.
- Free-form text payloads that are not contract-based.
- Searching for the current in-process entry when `Rec` can be bound directly.

## Knowledge Block 3: Execute / Retry

Use this block when the request involves foreground testing, retry policies,
restarts, stale jobs, or stability hardening.

### Core Rules

1. Runnable objects must be background-safe.
2. Treat `Confirm`, `Page.Run`, `Page.RunModal`, `Report.Run`, `Report.RunModal`, `Hyperlink`, `File.Upload`, and `File.Download` as invalid when called from background execution code. This does not prohibit scheduling a report itself through `Job Queue Entry`.
3. Use `GuiAllowed()` only to isolate optional UI behavior that may also run in foreground.
4. Use `Job Queue Management.RunJobQueueEntryOnce` for foreground testing when the user wants to validate a configured entry interactively.
5. Choose retry settings intentionally, especially for integrations and transient dependencies.

### Retry Guidance

- If the job depends on transient external services, favor several attempts with a meaningful delay window.
- If the job posts data or performs irreversible writes, make retry safety explicit before increasing attempts.
- If a job can become stale because of restarts, upgrades, or category serialization, add a recovery path and observability.

### Recovery Checklist

- Can the job be rerun safely?
- Is the failure transient, configuration-related, or business-data-related?
- Is a manual restart enough, or is data repair needed first?
- Are stale entries detectable through platform helpers or telemetry?

## Knowledge Block 4: Monitor / Diagnose

Use this block when the user asks how to observe, debug, or stabilize Job Queue behavior.

### Core Rules

1. Always give the user at least one in-client diagnosis path and one telemetry path.
2. In-client tools: `Job Queue Entries`, `Log Entries`, `Scheduled Tasks`, and `Session Event` table `2000000111`.
3. Distinguish enqueue failures from execution failures and final-stop failures.
4. Surface the official lifecycle event IDs and explain what each one proves.
5. If custom notifications are needed, prefer supported extensibility points such as enqueue events or validated status transitions.

### Lifecycle Events to Watch

- `AL0000E24`: enqueued successfully.
- `AL0000FNY`: failed to enqueue.
- `AL0000E25`: started.
- `AL0000E26`: finished.
- `AL0000HE7`: failed but may retry.
- `AL0000I49`: rescheduled on login.
- `AL0000FMG`: run once by a user.
- `AL0000JRG`: failed for the last time and needs intervention.

### Diagnostic Questions

1. Did the entry enqueue at all?
2. Did a scheduled task exist behind the entry?
3. Did the job enter `In Process`, `Error`, or final stopped state?
4. Is the failure due to UI callbacks, permissions, stale scheduling, bad parameters, or business data?
5. Is the job safe to restart, or does it need repair first?

## Expected Deliverables

When this skill is used well, the output should usually contain:

- An explicit Job Queue versus other async primitive decision.
- A creation or enqueue pattern.
- A parameter contract.
- A background-safe execution scaffold.
- A retry and recovery strategy.
- A monitoring and telemetry plan.

## References

- `references/code-patterns.md`
- `references/official-sources.md`
- `references/release-plan-entry.md`

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [fernandoartalf](https://github.com/fernandoartalf)
- **Source:** [fernandoartalf/AL-Copilot-Skills-Collection](https://github.com/fernandoartalf/AL-Copilot-Skills-Collection)
- **License:** MIT
- **Homepage:** https://alcopilotskills.com/

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-fernandoartalf-al-copilot-skills-collection-bc-job-queue
- Seller: https://agentstack.voostack.com/s/fernandoartalf
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.