v1.12.1
Publiée le 11 août 2026 — contrôle des dates de Touchpoint, champ unique Nom complet à l'inscription, et une seule méthode de connexion par utilisateur Studio.
Publiée le 11 août 2026.
À vérifier avant votre prochaine publication
Les surcharges de dates d'un Touchpoint sont désormais contrôlées par rapport aux dates de la campagne au moment de la publication. Un Touchpoint dont la fenêtre personnalisée sort de la campagne — ce qu'OmniLab acceptait auparavant — bloque maintenant la publication tant que vous ne l'avez pas corrigé. Si des campagnes attendent d'être mises en ligne, validez-les en amont plutôt que le jour du lancement.
À vérifier sur les activités déjà en cours
Les limites de réservation par participant s'appliquent désormais aux activités Réservation + Check-in. Elles ne fonctionnaient jusqu'ici que sur les activités sans réservation (check-in uniquement) : une limite définie sur une activité réservable était enregistrée et publiée, mais n'arrêtait personne. Toute limite de ce type devient active dès maintenant, y compris celles définies il y a des mois et oubliées depuis. Ouvrez l'onglet Créneaux de chaque activité en cours ou sur le point de démarrer et vérifiez que les nombres correspondent toujours à ce que vous voulez.
Plateforme
Les dates d'un Touchpoint sont contrôlées par rapport à la campagne. Lorsque vous donnez à un Touchpoint ses propres dates de début et de fin, la publication vérifie désormais que cette fenêtre tient dans la campagne et que la date de fin est postérieure à la date de début. Chaque problème est signalé nommément : vous savez quel Touchpoint sort de la plage et dans quelles dates il doit tenir — une erreur apparaît donc comme un message clair, au lieu d'un Touchpoint qui ne s'ouvre jamais en silence. Les champs de date, eux, acceptent n'importe quelle date saisie : le contrôle a donc lieu à la publication et non pendant que vous éditez.
Voir Surcharge des dates d'un Touchpoint et Dates de campagne.
Collecter un champ Nom complet au lieu du prénom et du nom. Les formulaires d'inscription peuvent maintenant demander un seul champ Nom complet plutôt que Prénom et Nom de famille séparés. Cela convient aux audiences dont les noms ne se découpent pas nettement en deux parties, et cela raccourcit le formulaire. Votre administrateur l'active campagne par campagne, et vous pouvez modifier le libellé du champ et son message d'erreur comme n'importe quel autre texte de formulaire. Les participants collectés ainsi apparaissent dans une colonne Nom complet de votre tableau des participants et de vos exports.
Voir Référence du formulaire d'acquisition.
Un nouveau champ contact_fullname pour les modèles de notification. Comme le nom d'un contact est désormais stocké de deux façons possibles, une salutation construite à partir du prénom et du nom s'affiche vide pour toute personne inscrite via une campagne Nom complet. Le nouveau champ se résout correctement pour chaque contact, quelle que soit la façon dont son nom a été collecté : c'est celui à utiliser dans vos nouveaux modèles.
Voir Variables des modèles Liquid.
La date de naissance n'est plus forcément obligatoire, ni réservée aux plus de 18 ans. Une campagne qui demande une date de naissance peut désormais laisser le champ facultatif, retirer le contrôle « plus de 18 ans », ou les deux — ce sont deux réglages distincts : vous pouvez donc exiger la date sans limite d'âge, ou ne contrôler l'âge que des participants qui choisissent de répondre. Les campagnes qui collectent déjà une date de naissance ne changent pas : le champ reste obligatoire et soumis au contrôle d'âge tant que votre administrateur n'en décide pas autrement.
Voir Référence du formulaire d'acquisition.
L'opt-in marketing peut devenir une condition d'inscription. Lorsque le choix marketing s'affiche sous forme de case à cocher, votre administrateur peut désormais le rendre obligatoire : un participant qui laisse la case décochée ne peut pas terminer son inscription. Les campagnes qui affichent des boutons d'acceptation et de refus ne changent pas — ils imposent déjà une réponse dans un sens ou dans l'autre. Rendre un consentement obligatoire relève autant du juridique que du réglage de formulaire : lisez l'avertissement avant d'en faire la demande.
Voir Référence du formulaire d'acquisition.
L'email contenant le code de vérification est envoyé dans la langue de votre campagne. Le code court envoyé par email à l'inscription arrivait jusqu'ici en anglais, quelle que soit la langue de la campagne. Il suit désormais la langue de la campagne, traduit en anglais, français, allemand et italien, l'anglais servant aux campagnes dans toute autre langue. Il suit la langue par défaut de la campagne et non celle qu'un visiteur choisit avec le sélecteur de langue : une campagne proposant plusieurs langues écrit donc à tout le monde dans sa langue par défaut.
Voir Référence du formulaire d'acquisition.
Événements
Les limites de réservation par participant fonctionnent enfin sur les activités réservables. Une limite par participant — plafond total, quotidien ou hebdomadaire — n'était appliquée que sur les activités sans réservation (check-in uniquement). Sur une activité Réservation + Check-in, vous pouviez en définir une, l'enregistrer et publier : les participants réservaient sans en tenir compte. La limite s'applique maintenant au moment de la réservation, et seules les réservations confirmées y comptent — une annulation rend donc son quota au participant.
Comme des réglages jusqu'ici inertes deviennent actifs, vérifiez les nombres sur les activités que vous avez déjà en cours.
Voir Configurer les restrictions de réservation.
Admin & accès
Chaque utilisateur Studio se connecte d'une seule façon. Un compte utilisateur est désormais rattaché à une seule méthode de connexion, définie sur le compte par un administrateur via le champ Fournisseur d'authentification. Si votre organisation utilise la connexion unique d'entreprise, les personnes qui y sont rattachées ne peuvent plus se connecter par lien email à la place — ce que votre système d'identité impose, comme l'authentification multifacteur, s'applique donc réellement à OmniLab. La page de connexion explique aussi les refus en termes clairs, notamment lorsque quelqu'un tente la mauvaise méthode.
Le déploiement se fait utilisateur par utilisateur plutôt qu'en une seule bascule globale, et il n'existe pas de repli individuel une fois une personne migrée.
Voir Utilisateurs et authentification et Connexion d'entreprise (SSO).
Intégrations
L'écran de vérification email parle la langue de vos participants. Quand le double opt-in est activé, l'écran demandant de confirmer son adresse — ainsi que la page d'arrivée après le clic sur le lien — suivent désormais la langue de la campagne au lieu de s'afficher systématiquement en anglais. Les textes sont livrés traduits, et vous pouvez tous les réécrire dans les textes de formulaire de votre campagne.
Voir Configurer la vérification d'e-mail par double opt-in.
Une erreur de publication qu'on vous signalait sans vous la montrer. Quand le double opt-in est activé pour une organisation et que rien n'est en place pour envoyer l'e-mail de confirmation, aucune campagne de cette organisation ne peut être publiée. Cette erreur était comptée dans le total des problèmes de la campagne mais absente de la liste derrière View Details : on vous demandait donc de corriger quelque chose que l'écran ne nommait jamais. Elle apparaît désormais avec tous les autres problèmes, sous Auth, et ses instructions nomment les écrans exacts à ouvrir — dont les deux conditions pour qu'une association compte : elle doit être active, et elle doit couvrir l'organisation de cette campagne.
Voir Configurer la vérification d'e-mail par double opt-in et Validation et publication.
Développeurs
Les hooks de contact reçoivent l'intégralité du contact soumis. Les entrées de hook comportent désormais le consentement marketing donné par le visiteur, son numéro de téléphone et les réponses complémentaires du formulaire — de quoi personnaliser un e-mail de vérification ou une règle de validation sans second appel. Chaque invocation de hook porte également la campagne et l'organisation dont elle provient : une même function peut donc servir plusieurs campagnes au lieu d'une par campagne.
Le nom d'un contact arrive maintenant sous l'une des deux formes : construisez donc toute salutation avec la fonction utilitaire du SDK plutôt qu'en lisant directement le prénom.
Voir la Référence du SDK des functions et Functions de type hook.