A daily editorial queue needs a clear answer to a small question: which item is eligible next? Answering that question before connecting a scheduler makes the behavior easier to inspect and test.

This walkthrough uses the Daily Queue Selector, WF11 v0.1.0, publicly released on 30 September 2026 and reviewed at main commit 1bff1a65. Workflow code is MIT licensed; its separate notice preserves image, supplied-content, third-party and premium rights. The template remains manual, inactive and credential-free. Selection returns an advisory result; public availability does not activate production scheduling, reserve an item or permit generation.

The starting point is a small fictional queue. You can reason about its priority, dates and blocking conditions without contacting a model, publishing an article or changing a live editorial record.

Make the queue contract explicit

Each candidate has a content_id, status, integer priority, planned_date, three readiness booleans and reserved_by. The booleans are topic_approved, sources_ready and images_ready. A free reservation is represented by null; an absent field is invalid, rather than silently treated as available.

Only ready_for_brief items can be selected. The planned date must be on or before the current editorial date, all three readiness flags must be true and reserved_by must be null. Other recognized lifecycle states include briefing review, drafting, article review, delivery, awaiting merge and publication, but they do not enter the eligible set.

Use these states to describe actual progress. A proposed topic with missing source evidence should stay blocked from briefing selection. Do not mark images ready because an image might be found later. The flags summarize evidence supplied by your review process; the selector cannot authenticate that process.

The selector rejects duplicate identifiers and malformed records across the entire input, even when a malformed record would otherwise be ineligible. That fail-closed rule makes bad queue data visible instead of quietly omitting it and continuing with a misleading partial view.

For the earlier content gate, see Validate Content Ideas in n8n Before Calling AI. For evidence preparation, read Turn Verified Sources into a Content Brief with n8n. This queue consumes readiness decisions; it does not repeat those reviews.

Use an editorial date, not an ambiguous clock

The selector requires timezone Africa/Luanda, max_items equal to 1 and a timestamp with an explicit offset. The timestamp includes seconds; supported calendar years are 2000 through 2099. Invalid dates and unknown offsets are rejected.

Within its bounded implementation contract, the Luanda editorial date is calculated at UTC plus one hour. That makes the boundary test useful: 29 September at 22:59:59 UTC is still 29 September in Luanda, while 23:00:00 UTC begins the next editorial day.

Provide the timestamp deliberately during offline testing. Letting an example depend on the reader's current clock makes tomorrow's output different from today's without any change in the queue. In production, the source of current time and the freshness of the queue snapshot need their own checks.

The proposed daily dispatch time for this project is 17:00 Luanda. It is not enabled by the selector. n8n's Schedule Trigger documentation says scheduling uses the workflow timezone when set, otherwise the instance timezone, and requires saving and publishing the workflow. Keep that activation decision separate from this manual demonstration.

Run a deterministic selection

Create three fictional records: demo-C, demo-B and demo-A. Give all three priority 1, planned_date 2026-09-30, status ready_for_brief, true readiness flags and a null reservation. Use now equal to 2026-09-30T17:00:00+01:00.

The result selects demo-A. Smaller numeric priorities win first, then older planned dates, then case-sensitive ASCII content IDs. Reversing the input order should not change the selected result. This provides a simple way to catch an accidental dependency on table row order.

The result includes the selected identifier, editorial date, eligible count and reasons for excluded entries. Eligible items that lose the ranking receive lower_ranked_eligible. Blocked entries can have multiple reasons, which helps an editor distinguish missing images from an existing reservation.

Every successful result retains generation_allowed as false and reservation_required as true. It also records that the supplied approval records are not authenticated. A selected item remains a candidate until the downstream controls establish authority to proceed.

Now set every topic_approved flag to false. The expected result is no_work with topic_not_approved reasons. Restore the original input and demo-A returns. An empty queue also returns no_work, with an empty_queue reason, so an ordinary quiet day can be handled without pretending that generation failed.

Reserve before anyone generates

Two workers reading the same snapshot can both select demo-A. The selector neither writes state nor excludes the other execution. Calling it once per scheduled run also does not enforce once-per-day processing: an extra manual or overlapping run could select the same candidate again.

Production needs a trusted, atomic reservation. Define a unique content identity and editorial period, acquire the reservation in durable storage, and continue only when ownership is confirmed. Record the request identity and reservation outcome. Budget reservation must also happen before a paid call.

A read followed by an upsert is not sufficient evidence of mutual exclusion. n8n's Data tables documentation describes persistent tabular storage and duplicate-run markers, but this article does not infer an atomic locking guarantee from those features. Verify the precise concurrency contract of the chosen storage operation.

If a worker's outcome is unknown, keep the reservation unresolved until reconciliation. Automatically clearing it can let another run spend money while the first run is still completing. Recovery should determine ownership and completed effects before allowing further work.

Map existing queues deliberately

The project also has an editorial briefing document with its own schema. The selector's separate read-only adapter maps its identifiers, statuses and evidence fields into selector input. It requires explicit planned dates and a reservation snapshot for every item; those values are not invented from missing data.

If that source queue has execution_enabled set to false, the adapter blocks every mapped item. Topic approval with the expected approval scope does not override the disabled queue. Neither a final-article field nor a convenient default grants permission to generate.

This separation is useful when adopting the pattern elsewhere. Write down your real states and the evidence behind each field, then test the mapping. Do not rename every pending item ready_for_brief just to produce a selected result.

Verify imports before adding private data

The isolated n8n tests recorded before release on 30 September passed valid, unapproved and restored-input cases. The import flow nevertheless retained default UTC and default execution-saving settings instead of the export's proposed settings. Review timezone and retention explicitly after importing; JSON settings alone do not prove the imported configuration.

The WF11 runtime version before a workspace restart was not authoritatively captured. About later showed n8n 2.41.4, but that does not retrospectively establish the version of earlier WF11 runs. A full post-save runtime export was unavailable. The September 30 offline regression checks add reproducible selection evidence without claiming a fresh cloud execution.

Keep the rollout manual until concurrency, budget controls, approvals and failure recovery are verified. The selector itself calls no model and performs no network request. Hosting, execution quotas, storage and future generation may still cost money. Once a candidate is safely reserved, prepare the brief and stop for its review, keeping article approval and publication as later decisions.

Verification evidence

Daily queue selection. offline candidate execution / fictional inputs.

Daily queue selection; observed 30 September 2026. Offline pre-release candidate execution with fictional inputs, preserved as historical evidence. Rendered report, not a product UI screenshot. The original image retains its private-review label; the owner approved this historical report for publication on October 1, 2026.

Image provenance and reuse limits: publication asset manifest.