v1.12.2
Released 19 August 2026 — an attribution slot required on every receipt-game winning option, legacy Activities refused at publication, and embedding fixes.
Released 19 August 2026.
Check this before your next publication
Every winning option in a receipt game now needs at least one attribution slot, whatever its Total Quantity. OmniLab used to accept an option with no slots and only warn about it, so a receipt game that published happily last month may now stop at publication. Validate any receipt game you have waiting to go live rather than finding out on launch day.
Check this if you have long-running Activities
An Activity built on OmniLab's older internal shape can no longer be published, and has to be rebuilt as a new Activity. Anything you have created recently is unaffected — the older kind hasn't been buildable for some time. What this catches is a campaign that has been around a while, or one duplicated from it. Because a rebuild is a new Touchpoint with its own links and QR codes, find out now whether you have one rather than on the morning of your event.
Transactions
Every receipt-game winning option needs an attribution slot. An attribution slot is where you say when a reward can be won, and a winning option with none was never actually winnable: a participant who earned it was turned away at the last step, because there was no open window to unlock it in. Publishing used to allow this with a warning and now refuses it, so the problem surfaces in your build instead of in front of a participant.
This has a consequence worth planning around: a receipt-game winning option can no longer have unlimited stock. Every slot carries a quantity above zero, and Total Quantity has to equal the sum of the slots, so "leave the quantity at 0 for unlimited" is no longer a valid setup. If that is what you were relying on, decide the number you are willing to give away and put it in a slot covering the campaign.
See Winning options and attribution slots.
Attribution slots have to fit the window the game runs in. Publishing now also checks each slot against the period the receipt game is actually playable in — the Campaign dates, or the Touchpoint's own dates when it overrides them. A slot that starts before that window or ends after it stops publication, and the message names the dates it has to fit inside. Quantity sitting outside the playable window could never be won, so it was quietly shrinking the prize pool you thought you had scheduled. Watch for this after you shorten a Campaign, or turn a date override on for a receipt game whose slots were laid out against the old dates.
See Winning options and attribution slots and Attribution slots.
Events
Activities built on the older internal shape are refused at publication. OmniLab's checks on Activities are written for the way Activities are built today. An Activity from before that change could pass validation with pieces missing and then break in front of an attendee trying to book — so publication now names it and stops, rather than letting the failure reach your event day.
The fix is to rebuild the Touchpoint as a new Activity with the same details, schedule, tickets, and check-in settings, then remove the old one. Plan that switch: the new Activity has its own share link and QR codes, and bookings and check-ins already recorded stay with the Touchpoint you are replacing. If the event is live and taking bookings, talk to your Customer Success Manager before removing anything.
Integrations
Experiences embedded in your own pages behave better on the page around them. A run of fixes to how OmniLab sits inside an iframe: drawers and forms now open inside the part of the page a visitor is actually looking at rather than behind a sticky header or off-screen, the embed no longer creeps or jitters in height as content changes, and on a phone the page behind the embed stays still while a drawer is open. Scratching a scratch card no longer scrolls the host page with the gesture, and moving between steps inside the embed no longer loses the visitor's session.
Most of this needs nothing from you — OmniLab now works out where your header is on its own. If your header is unusual, your web team can point OmniLab straight at it. Worth a quick retest on mobile if you have an embed live.
See Embed OmniLab in a web page.
Developers
ready-to-open-modal was removed from the embedded integration. A modal inside an embedded experience now opens on its own rather than waiting for the parent page. If your wrapper sends ready-to-open-modal, remove it — nothing waits for it any more. The closing message, ready-to-close-modal, is unchanged.
Alongside that, drawers are now placed and sized to fit the space your page actually gives the embed, so they open where the visitor is looking rather than behind a sticky header or off-screen. The JavaScript player tag handles the parent side of this for you; if your experience uses drawers and you currently hand-write the parent page, the player tag is now the better choice.
See Embedding and WebView integration.
Player tag options take effect, and three were added. The presentation options for the JavaScript player tag — width, height, and the iframe attributes — apply from this version. If you had styled the embed with CSS overrides on #omnilab-iframe, check that those and your options agree.
The three new options are stickyHeaderSelector, to name your sticky header so drawers open below it; topOffset, to keep a fixed number of pixels clear at the top instead; and scrollIntoViewOnNavigate, to stop OmniLab scrolling the embed into view when a visitor moves between steps.
See Player tag options.