v1.12.3
Released 25 August 2026 — the on-site staff apps renamed and moved into touchpoint sharing, plus two tighter checks on luck-based games.
Released 25 August 2026.
Check this before your next publication
Two checks on luck-based games (Wheel of Fortune, Scratch Card, Reveal Card, Simple / Instant Win, 3D Selection) are stricter than they were. A game needs at least one winning option — previously enforced on the Wheel of Fortune alone — and can have at most one losing option, which nothing used to stop. Both configurations have always broken the game when a player tried to play it; publishing simply allowed them through. A game built before this release can therefore be refused at publication today even though it published before. Validate anything you have waiting to go live, and pay particular attention to games duplicated from older Campaigns.
Events
The check-in scanner is now the Event Host App, and it lives with the Activity you share. The staff app hosts use to scan attendees in has a name of its own, and it appears wherever you go to share the Activity: open Build, go to Touchpoints, and open an Activity's share options — Event Host App sits there as a tab, next to the share link and QR code. It shows for every Activity, whichever check-in method you chose.
The card on the Bookings tab has not gone anywhere. It sits where it always did, above the tabs, and now shows the same panel as the share tab — so the URL, the password and the instructions sheet can no longer drift apart between the two places.
Nothing you have configured changes, and no link or password is invalidated by the rename. If your internal runbooks say "Check-in Scanner App", that is the wording to update.
See Set up the Event Host App.
The instructions sheet was redesigned around the person holding it. The PDF you hand to staff now names the app at the top, carries the Scanner URL as a QR code to scan as well as text, and prints the password with a line explaining that hosts are asked for it the first time they open the app on a device — the question that generated most of the day-one confusion.
The footer names the app and the Campaign and carries the Campaign's internal reference, so a printed sheet can be traced back to the event it belongs to. It deliberately names no Activity: one URL and one password serve every Activity in the Campaign, and hosts pick the Activity after signing in, so a single sheet covers the whole event.
See Set up the Event Host App.
Games
A luck-based game can no longer be published without a winning option. This check existed, but only ran on the Wheel of Fortune. It now runs on all five luck-based games. A game with no winning option has nothing to award: under Random Chance a player who tries to play gets an error instead of a result, and under Scheduled Rewards the game runs but never awards anything. Either way the failure used to reach the player rather than you.
See Configure outcomes.
A luck-based game can no longer be published with two losing options. One losing option is allowed, and so is none — a game everyone wins is a valid setup. Two is not, and this is the change most likely to stop a Campaign that published before.
It is worth knowing why the configuration existed at all: the game editor only ever displays the first losing option, so a second one was invisible in Studio while still breaking the game when a player reached it. Publishing now names it instead of letting it through. Scheduled Rewards is the one mode that needs exactly one losing option rather than at most one, because a player who plays outside a scheduled winning moment has to land on it.
Transactions
The receipt review tool is now the Receipt Host App, with its own share tab. The tool your staff validate receipts in is named, and you no longer have to hunt for its address: open Build, go to Touchpoints, and open the receipt game's share options — Receipt Host App is a tab there, holding the Scanner URL, the password, and a printable instructions sheet, exactly as the Event Host App does for an Activity.
One thing worth planning around: the password belongs to the Campaign, not to the receipt game. If the same Campaign also runs a bookable Activity, both apps share that password — changing it in one place changes it in both, and saving it republishes the Campaign, so staff already signed in are asked for the new one.
Receipt-game validation messages name the option instead of an identifier. A blocking message about a winning option used to quote an internal identifier, which told you what was wrong but not which row of the editor to open. Messages now name the option — by its Display Name, or by the reward it grants if it has no name yet, or by its position (#2) as a last resort — and count attribution slots from 1 in the order they appear on screen. Sixteen messages were affected, including two that reported the first slot as "slot 0".