This page explains Curator queues for the person who designs the process — analyst, coordinator, business owner. You do not need to know how to program. Whenever a technical name appears, it is explained right there, with an everyday analogy. The animations play on their own: hover to pause and click to watch again.
Think of a shop counter with a ticket list. Each ticket is a case to handle. Whoever arrives takes a number. Whoever serves takes the next free number. Two people never take the same ticket.
In Curator that list is called a queue. Each number is called an item — a work ticket. The ticket says what needs to be done, what state it is in, and what happened at the end.
Why not send the robot to read the spreadsheet directly? Because two robots can take the same row, a failed row disappears among the others, and nobody can see clearly what is done, what is left and what went wrong. The queue becomes the central list: one case, one ticket, one story.
On the real screen you see the same idea as the animation: each row is a case, with priority, attempts and the time it started and ended.
The queue by itself does not do the work. Two kinds of robot use the list, each with a single job. Analogy: in a warehouse, a stock clerk puts orders on the conveyor; several operators each take one order and pick it.
| Name in Curator | In plain language |
|---|---|
| Dispatcher | The robot that puts items on the list. It reads the spreadsheet, the system or the inbox and creates one ticket per case. |
| Performer | The robot that picks and works. It reserves one ticket, runs the process and writes down the result. |
You can have several Performers at the same time, each on a Windows PC in the company. The queue makes sure two PCs never hold the same ticket. There is also the Disperformer: the same project that, in one run, first builds the stack and then posts. The three roles are detailed in Dispatcher and Performer.
A queue item is the smallest unit Curator controls. An invoice, a registration, a memo, a bill — each one becomes a ticket. If the batch has 800 invoices, the queue has 800 tickets. If one fails, you handle only that one.
You do not need to store the whole spreadsheet inside the ticket. Keep only what the robot uses to work and what the team needs to audit later.
NF-2026-000123 or PED-88421. Do not use row2 or test.
cliente_id: C-1024pedido: P-9981arquivo: documentos/NF-8831.pdfThe status is the ticket’s badge: where it is on the path. Four badges cover almost everything you see day to day.
| Badge | What it means | What you do |
|---|---|---|
| New | It is on the list, waiting its turn. | Nothing. The Performer takes it when its turn comes. |
| In progress | A PC reserved it and is working. | Wait. If it stays like this too long, the PC may have frozen. |
| Success | It finished correctly. | Do not put it back on the queue unless the process rule asks to repeat the case. |
| Failed | It ended with an error. | Read the reason. Only then decide whether to retry or have someone fix the data. |
Three badges show up less often, but they are worth knowing. Abandoned: the case should not be retried, but the record stays visible. Retried: this ticket was replaced by a new attempt; the original stays in the history. Deleted: it left active operation — use with care if the company needs to trace the case.
On the list, the two red tickets look the same. The question that changes the decision is: if I retry now, with the same data, is there a chance it will work?
The case does not meet a rule. Retrying with the same data fails again.
What to do: stop retrying. Fix the data or handle it by hand.
Something on the path failed. Waiting or switching PC can fix it.
What to do: you may retry, with a limit on how many times.
Priority says whom the Performer should take first. Use critical for real: month-end close, a customer with a short deadline. If almost everything is marked urgent, the queue loses its meaning — it becomes a list with no order again.
Two extra controls show up on the ticket when the calendar matters. The deadline is “by when this should be done” — due date, bank window, end of day. Postponement is “do not take it before this time”: for example, only after 8 a.m., or on the next business day, when the supplier’s system opens.
Retry (the word on the screen) means a new attempt. The ticket that failed is not erased: it stays in the history. Curator creates a new ticket, linked to the previous one, and only that one returns to the list. You do not reread the whole spreadsheet.
There are two ways. A manual retry is the analyst looking at the ticket and asking again — the site is back, the data was fixed, the screen changed. An automatic retry is Curator itself trying again on short-lived technical failures, with a small limit. Never let it retry forever: that hides the problem and delays healthy tickets.
A healthy queue answers five questions quickly. If the team can answer them by looking at the screen, the design is sound.
Every morning: open the failures, split business from technical, and only ask for a new attempt on what you understood. Every week: look at the reasons that repeat most — often the fix is in the source spreadsheet, not in the robot. If volume grows: plug in another PC with the same Performer; do not mix three different processes in the same queue.
Name the queue after the process, not a number. Good: invoices-inbound, customer-registration. Avoid: queue1, final-test-now-it-works.
| What you see | What it usually is |
|---|---|
| The Dispatcher ran and the queue is still empty | The source had no new row, the reference already existed, or validation blocked the batch. |
| The Performer stops without taking a ticket | There is no New ticket, or they are all postponed. |
| The ticket stays “in progress” too long | The PC froze, the system screen did not open, or the reservation was not released. |
| Many tickets fail with the same message | Stop the batch. Fix the source or the robot. Do not mass-retry in the dark. |
| Duplicate tickets appear | The reference is not unique, or the Dispatcher ran twice on the same spreadsheet. |
| Priority seems not to apply | Almost everything is marked urgent, or the critical tickets are postponed. |