This page explains the robots that use Curator’s queue. It is written for the person who designs the process — analyst, coordinator, business owner. You do not need to know how to program. Whenever an English name appears, it is translated right there. The animations play on their own: hover to pause and click to watch again.
The conveyor is the queue: a central list of cases. Each case is a ticket — identity, data, status and history. On that conveyor there are three roles. They are not three different technologies. They are three ways to use the same list.
| Name in Curator | In plain language |
|---|---|
| Dispatcher | Builds the stack of tickets. It does not post in the destination system. |
| Performer | Takes the next ticket, resolves the case and returns the stamped ticket. |
| Disperformer | The same person photocopies the tickets in the morning and then posts them. One project, two phases. |
Before the roles, the skeleton. Curator does not generate a “run everything and, if one breaks, stop everything” script. It generates a cycle: start, take the next case, work that one, write the result, take again. When there is no case left, it stops.
| Step | What it does |
|---|---|
| Start | Reads the settings, signs in to the queue, opens the browser if needed. |
| Take | Finds the next case for this robot — a spreadsheet row, or a queue ticket. |
| Work | Does the work for that case: enqueue, or post in the system, depending on the role. |
| Write down | Records success, a business failure or a technical failure. Decides whether to retry. |
| Stop | When there is no case left: closes what it opened and cleans up. |
On failures: the practical question is if I retry now, with the same data, is there a chance it will work? If not, it is a business failure — stop retrying. If yes, it is a technical failure — you may retry, with a limit. The detail is in Queues.
Dispatcher and Performer do not talk to each other directly. They meet at the queue item. That is why they need to agree on what is written — the ticket agreement.
PED-88421. Do not use “row 2”.
Its question: which cases need to enter the queue now? It does not register in the ERP, does not finish downloading the invoice, does not confirm the protocol. It prepares the work.
Where it usually takes cases from:
In the Dispatcher cycle, the “case” is the next row (or the next source record). Work = transform that row and put it on the queue. When the source ends, it stops. It does not loop forever — the usual pattern is a time trigger: every 15 minutes, once a day, at the start of the shift.
Analogy. It is who stacks the case files on the desk. It does not post each case in the system.
Its question: what is the next item I can process safely? It does not read the source spreadsheet. It only sees the queue. It takes the next one, reserves it (another PC does not take the same), runs the business rule, tells the queue: success, business failure or technical failure. Empty queue → stop.
The ticket states (New, In progress, Success, Failed) are in Queues. For continuous operation, the team starts it again on schedule — or leaves more than one PC on.
A queue can have several Performers at the same time. You do not need three queues to have three PCs. Curator hands out different tickets — like a ticket board with three clerks.
Analogy. It is who takes the next ticket from the stack, resolves that case in the system, returns the stamped ticket and takes the next one.
In one sentence: a single agent that, in each run, first dumps the spreadsheet onto the queue and then consumes that same queue as a Performer. Not two robots. One project, one folder, the same queue name, two phases in the same run.
Phase 1 (once per run). It reads the whole spreadsheet, builds the tickets and puts them all on the queue at once. That is not posting in the system — only the spreadsheet → stack copy.
Phase 2. Same as the Performer: take the next from the queue, work, write down, next. When the queue is empty, it stops.
Analogy. It is the same person who, in the morning, photocopies every ticket onto the stack and then posts ticket by ticket. It does not call a colleague for the second half.
| Dispatcher | Performer | Disperformer | |
|---|---|---|---|
| Question | What enters the queue now? | What is the next safe case? | Both, in that order, in the same run |
| Case source | Spreadsheet row (or another source) | Item already on the queue | 1st time: whole spreadsheet; then: the queue |
| Destination | Curator queue | Business system | Spreadsheet → queue → system |
| Required pair | Needs Performer(s) | Needs someone who feeds | No |
| Parallel | One is usually enough | Several on the same queue | One agent only |
| Typical trigger | Clock | Clock or “queue has N new” | Clock (one run does both phases) |
Classic flow: source → Dispatcher → queue → Performer(s) → destination. Combined flow: spreadsheet → [Disperformer phase 1] → queue → [Disperformer phase 2] → destination.
Order matters. First the list, then the project type, then the work. Everything points to the same queue name.
inbound-orders, not queue1.In the test, try to see these three outcomes:
On the queues screen, five questions are enough to know whether the operation is healthy.
If the list grows and the PCs are free, run more Performers. If failures repeat with the same message, stop the batch and fix the source — do not mass-retry in the dark.