Open Automations in the left sidebar and pick the Code Pools tab. The page says what a pool is for in one line: "Pre-supplied codes the Issue Code automation node hands out one-per-contact, until the pool runs dry." This is the surface behind promises like the first 200 people who comment get a code — the pool holds the 200, and the workflow decides what happens to person 201.
What a pool actually is
A pool is a named list of code strings and nothing more. IcloneU does not create the codes' meaning, does not know what they are worth, and never redeems them — it only tracks which ones have gone out and to whom. Redemption happens wherever the codes came from: your store, your ticketing system, your licence server.
- A pool belongs to your team, not to one workflow and not to one connected platform account. A code redeems the same whether the conversation happened on Instagram or WhatsApp, so one promotion can run across several posts and several workflows drawing from the same pool.
- The pool's size is the cap. There is no separate "limit" setting anywhere — if you want a promotion to stop after 200 people, put 200 codes in the pool.
- Codes are unique within a pool. Adding one that is already there is silently skipped rather than treated as an error, so re-pasting an overlapping list is safe.
- Issued codes are never deleted. Once a code has gone out, its row stays, showing who received it and when — that record is the reason the tab exists rather than a text file.
The tab is the main door. The other one is inside a workflow: an Issue Code node with no pools to choose from shows "No code pools yet — create one first." and an Open Code Pools link that opens this page in a new tab, so you can create the pool without losing your place in the editor.
Creating a pool
Click New pool
Top right of the tab. The New code pool dialog opens with a name field, a generator panel and a paste box.
Name it
Pool name is the only required field — Create stays disabled until it has something in it. The placeholder suggests the useful shape: "e.g. Black Friday 2026 — first 100". Put the campaign and the size in the name, because the grid shows counts but not intent.
Bring the codes, or generate them
Codes (one per line, optional) is where you paste codes you already have — usually exported from the system that will redeem them. If you need codes that mean nothing until you connect them to something, use the generator panel above it instead.
Click Create
The pool is created and any codes you supplied are seeded into it. The confirmation counts what actually landed: "Code pool created with {0} code(s)", where the number is the new rows only — anything that was a duplicate is not in it.
One code per line. Each line is trimmed, blank lines are dropped, and duplicates within what you pasted are collapsed without regard to case. Whatever survives is inserted exactly as typed — pasted codes never pass through the generator and are never reformatted. The dialog says as much: "You can add more codes later. Duplicates within a pool are skipped silently, so re-pasting an overlapping list is safe."
Generating codes instead of supplying them
The Generate random codes panel sits above the paste box in both dialogs and fills that box for you. Use it when the code only has to be unique and unguessable — a raffle number, an access code you will check against this list — rather than something an external system already knows about.
- How many, and how long. The two number boxes read as a sentence: N codes of L characters. Up to 10,000 codes at a time, each between 4 and 32 characters — the length counts the random body only, not the prefix or the checksum.
- Prefix (optional) — a human-readable head such as BF26-. It is not checked against the alphabet, so any characters you like are fine.
- Add checksum — "Appends a check character so a redemption endpoint can reject typos without a database lookup". Worth ticking if something of yours will validate the code before looking it up. The check character covers the random body only, so whatever validates it must strip the prefix first.
- Generate — fills the box. Note the verb: it replaces whatever is in the box, it does not append. Generate before you paste, never after.
Generated codes use digits and capitals with I, L, O and U left out — so there is no I that might be a 1 and no O that might be a 0. That matters because these codes get photographed off a QR, spelled out over the phone and typed at a checkout. Codes you paste yourself are kept verbatim, so this protection is yours to lose.
The grid, and managing one pool's codes
The list shows Name, Available, Issued, Total and Created, newest pool first. The three counts are computed from the codes themselves every time the page loads, so they cannot drift out of step with reality.
Select a pool and the toolbar offers Manage codes, Rename and Remove; double-clicking a row opens Manage codes directly. Inside that dialog, a summary line reads "{0} of {1} codes remaining", followed by the same generator panel, an Add more codes (one per line) box with an Add codes button, and the code list itself.
- Code is the string exactly as it will be sent.
- Status is Available or Issued. Available codes are listed first.
- Issued at is when the code went out, or a dash while it is still waiting.
- A remove button appears on Available rows only, and it takes effect immediately with no confirmation. Issued rows have no remove button at all — deliberately, so the record of who received which code cannot be edited away.
There is no paging and no search inside Manage codes, so a pool of several thousand codes is a long scroll and a slow dialog. If you are working at that scale, keep the pool for issuing and keep your own copy of the list for looking things up.
Handing codes out from a workflow
A pool does nothing until a workflow draws from it. In the Workflows editor, add an Issue Code node and pick the pool in its drawer. The node picker describes it this way: "Hand out one unique code from a finite pool, then branch to "exhausted" once empty." Until you pick a pool the node is flagged as incomplete and its summary reads "Pick a code pool".
The drawer explains the pool choice in the same terms this guide does: "Which team-scoped pool to draw from. The pool's size is the cap on how many contacts can be issued a code; once empty, the node routes to its "exhausted" port." It also shows the same remaining count as the tab, so you can see the pool draining without leaving the canvas.
The node has two output ports, and wiring both is the whole point of using a pool instead of a fixed message.
| Port | Taken when |
|---|---|
| Issued | A code was claimed for this contact. Wire your delivery message here. |
| Exhausted | The pool is empty — or no pool was picked at all. Wire the honest fallback here: a waiting list, an apology, a different offer. |
On the Issued branch the code is available to every node downstream as {{rv_issued_code}}. A QR image of the same code is rendered and uploaded at the same moment, and its address lands in {{rv_issued_code_qr_url}} — so an Image element can send the QR and the text of the code together. The drawer states the usual shape: "The issued code is exposed to downstream nodes as {{rv_issued_code}} — typically referenced by a Send Message that builds a QR image URL from it."
If a contact who already holds a code from this pool reaches the node again — a double comment, a retried webhook, a second run of the same flow — they are handed the same code back, not a new one. The pool does not shrink. That is what keeps a burst of duplicate events from burning through a promotion. Note what a contact means here: identity is per platform account, so the same person writing from Instagram and from WhatsApp is two contacts and will receive two different codes.
The code is claimed before the QR is made. If rendering or uploading the image fails, the failure is logged and the workflow carries on down the Issued branch with {{rv_issued_code}} set and {{rv_issued_code_qr_url}} empty. A message built only from the QR URL would go out with a hole in it, so send the code as text too.
Testing a flow, and deleting a pool
The Test button in the workflow toolbar runs the flow through the real engine without doing anything real: "Run this workflow through the real engine with a sample payload. Nothing is sent — every action is intercepted and traced." Issue Code is intercepted like everything else.
In a test run nothing is claimed and the counts do not move. The node still takes the Issued branch so you can follow the rest of the flow, and {{rv_issued_code}} is filled with the placeholder DRYRUN-CODE so the downstream message renders. Seeing that placeholder in a trace means the test worked, not that something is misconfigured. A node with no pool selected takes Exhausted in a test, which is the cheapest way to check your fallback branch.
Rename changes the pool's name and nothing else — no workflow needs re-pointing, because nodes refer to the pool itself rather than to its name.
Remove deletes the pool and every code in it, issued rows included, and the confirmation names the consequence that catches people out: "This cannot be undone, and any automation referencing this pool will start hitting its exhausted branch." A live workflow does not break — it quietly starts sending your fallback message to everyone. Point the node at a new pool in the same pass, or pause the workflow first.
Frequently asked
Yes, and that is the intended way to extend one. Open Manage codes, paste or generate more, and click Add codes. New codes are Available immediately, so a workflow that had started taking the Exhausted branch goes back to issuing on its very next run.
No. A pool records issuance only — which code went to which contact and when. Whether that code was used at your checkout is knowledge that lives in the system that honours it. If you need the two joined up, export the issued list and match it against your own redemption records.
Yes. Pools belong to the team, so several workflows across several posts and platforms can point at the same one and draw from a single shared count. That is how you cap a whole promotion rather than each entry point separately.
They get the same code they already had, and the pool does not shrink. This holds even when the two attempts arrive at the same instant, which is exactly the case a comment storm produces.
Because deleting it would erase the record of who received it. Only Available rows carry a remove button. If a batch was wrong, remove the unissued ones and add the corrected batch — the issued history stays intact.
Last updated August 25, 2026 · Automations
