v1.12.3
Publiée le 25 août 2026 — les applications terrain renommées et déplacées dans le partage des touchpoints, et deux contrôles resserrés sur les jeux.
Publiée le 25 août 2026.
À vérifier avant votre prochaine publication
Deux contrôles sur les jeux basés sur la chance (Wheel of Fortune, Scratch Card, Reveal Card, Simple / Instant Win, 3D Selection) sont plus stricts qu'avant. Un jeu doit avoir au moins une option gagnante — ce qui n'était vérifié que sur le Wheel of Fortune — et ne peut avoir au plus qu'une option perdante, ce que rien n'empêchait auparavant. Ces deux configurations ont toujours cassé le jeu au moment où un joueur tentait d'y jouer ; la publication les laissait simplement passer. Un jeu construit avant cette version peut donc être refusé à la publication aujourd'hui alors qu'il se publiait avant. Validez ce que vous avez en attente de mise en ligne, et surveillez particulièrement les jeux dupliqués depuis des campagnes plus anciennes.
Events
Le scanner de check-in devient l'Event Host App, et se trouve là où vous partagez l'activité. L'application que le personnel utilise pour enregistrer les participants porte désormais son propre nom, et elle apparaît là où vous allez pour partager l'activité : ouvrez Build, allez dans Touchpoints, puis ouvrez les options de partage d'une activité — Event Host App y figure comme onglet, à côté du lien de partage et du QR code. Elle s'affiche pour toutes les activités, quelle que soit la méthode de check-in choisie.
La carte de l'onglet Réservations n'a pas disparu. Elle se trouve là où elle a toujours été, au-dessus des onglets, et affiche maintenant le même panneau que l'onglet de partage — l'URL, le mot de passe et la fiche d'instructions ne peuvent donc plus diverger entre les deux endroits.
Rien de ce que vous avez configuré ne change, et ce renommage n'invalide aucun lien ni aucun mot de passe. Si vos procédures internes parlent d'« Application de scan d'enregistrement », c'est la formulation à mettre à jour.
Voir Configurer l'Event Host App.
La fiche d'instructions a été repensée pour la personne qui la tient en main. Le PDF que vous remettez au personnel nomme l'application en tête, porte l'URL du scanner sous forme de QR code à scanner autant qu'en texte, et imprime le mot de passe avec une ligne expliquant qu'il est demandé au personnel à la première ouverture de l'application sur un appareil — la question qui générait le plus de confusion le premier jour.
Le pied de page nomme l'application et la campagne, et porte la référence interne de la campagne : une fiche imprimée peut ainsi être rattachée à l'événement auquel elle appartient. Elle ne nomme volontairement aucune activité : une seule URL et un seul mot de passe servent toutes les activités de la campagne, et le personnel choisit l'activité après s'être connecté. Une seule fiche couvre donc tout l'événement.
Voir Configurer l'Event Host App.
Games
Un jeu basé sur la chance ne peut plus être publié sans option gagnante. Ce contrôle existait, mais ne portait que sur le Wheel of Fortune. Il s'applique désormais aux cinq jeux basés sur la chance. Un jeu sans option gagnante n'a rien à attribuer : en Chance aléatoire, un joueur qui tente de jouer obtient une erreur au lieu d'un résultat ; en Récompenses programmées, le jeu fonctionne mais n'attribue jamais rien. Dans les deux cas, l'échec arrivait jusqu'au joueur plutôt que jusqu'à vous.
Voir Configurer les issues du jeu.
Un jeu basé sur la chance ne peut plus être publié avec deux options perdantes. Une option perdante est autorisée, et zéro aussi — un jeu que tout le monde gagne est une configuration valide. Deux ne l'est pas, et c'est le changement le plus susceptible de bloquer une campagne qui se publiait auparavant.
Il vaut la peine de comprendre pourquoi cette configuration existait : l'éditeur de jeu n'affiche jamais que la première option perdante, une deuxième était donc invisible dans Studio tout en cassant le jeu dès qu'un joueur l'atteignait. La publication la signale désormais au lieu de la laisser passer. Récompenses programmées est le seul mode qui exige exactement une option perdante plutôt qu'au plus une, car un joueur qui joue en dehors d'un moment gagnant planifié doit tomber dessus.
Voir Erreurs de validation des jeux.
Transactions
L'outil de revue des tickets devient la Receipt Host App, avec son propre onglet de partage. L'outil dans lequel votre personnel valide les tickets porte désormais un nom, et vous n'avez plus à chercher son adresse : ouvrez Build, allez dans Touchpoints, puis ouvrez les options de partage du jeu de reçus — Receipt Host App y figure comme onglet, avec l'URL du scanner, le mot de passe et une fiche d'instructions imprimable, exactement comme l'Event Host App le fait pour une activité.
Un point à anticiper : le mot de passe appartient à la campagne, pas au jeu de reçus. Si la même campagne comporte aussi une activité réservable, les deux applications partagent ce mot de passe — le changer d'un côté le change des deux, et l'enregistrer republie la campagne, si bien que le personnel déjà connecté se le voit redemander.
Voir File de validation manuelle.
Les messages de validation des jeux de reçus nomment l'option au lieu d'un identifiant. Un message bloquant portant sur une winning option citait auparavant un identifiant interne, qui indiquait le problème mais pas la ligne de l'éditeur à ouvrir. Les messages nomment maintenant l'option — par son Display Name, ou par la récompense qu'elle accorde si elle n'a pas encore de nom, ou par sa position (#2) en dernier recours — et numérotent les créneaux d'attribution à partir de 1, dans leur ordre d'affichage. Seize messages étaient concernés, dont deux qui annonçaient le premier créneau comme « créneau 0 ».
Historique des notes de version
Toutes les versions d'OmniLab, la plus récente en premier, avec ce qui a changé et ce qui requiert votre attention.
v1.12.2
Publiée le 19 août 2026 — un attribution slot obligatoire par winning option de jeu de reçus, les anciennes activités refusées, et des correctifs d'embed.