v1.12.1
Released 11 August 2026 — touchpoint date validation, a single Full Name sign-up field, and one sign-in method per Studio user.
Released 11 August 2026.
Check this before your next publication
Touchpoint date overrides are now checked against the Campaign's own dates when you publish. A Touchpoint whose custom window falls outside the Campaign — something OmniLab previously accepted — now stops publication until you correct it. If you have Campaigns waiting to go live, validate them early rather than on launch day.
Check this on Activities you already have running
Per-participant booking limits now apply to Booking + Check-in Activities. They previously worked only on Check-in Only Activities, so a limit set on a bookable Activity was saved and published but never actually stopped anyone. Any such limit is live from now on, including ones set months ago and forgotten. Open the Slots tab of any Activity running or about to run and confirm the numbers still reflect what you want.
Platform
Touchpoint dates are checked against the Campaign. When you give a Touchpoint its own start and end dates, publishing now confirms that window sits inside the Campaign and that the end date comes after the start date. Each problem is reported by name, telling you which Touchpoint is out of range and which dates it has to fit inside — so a mistake surfaces as a clear message instead of a Touchpoint that silently never opens. The date fields themselves accept any date you type, which means the check happens at publication rather than as you edit.
See Touchpoint dates override and Campaign dates.
Collect one Full Name field instead of first and last. Sign-up forms can now ask for a single Full Name rather than separate First Name and Last Name fields. It suits audiences whose names don't split neatly into two parts, and it makes the form shorter. Your administrator turns it on per Campaign, and you can edit the field's label and its error message like any other form copy. Participants collected this way appear under a Full Name column in your participants table and exports.
See Acquisition form reference.
A new contact_fullname field for notification templates. Because a contact's name is now stored one of two ways, a greeting built from first and last name renders empty for anyone who signed up through a Full Name Campaign. The new field resolves correctly for every contact whichever way their name was collected, and is the one to use in new templates.
Date of birth no longer has to be required, or restricted to over-18s. A Campaign that asks participants for a date of birth can now leave the field optional, drop the "must be over 18" check, or both — they are two separate choices, so you can require the date without an age limit, or check the age only of those who choose to answer. Campaigns already collecting a date of birth are unaffected: it stays required and age-checked until your administrator says otherwise.
See Acquisition form reference.
The marketing opt-in can be made a condition of signing up. Where the marketing choice appears as a checkbox, your administrator can now require it, so a participant who leaves it unticked cannot finish signing up. Campaigns that show accept and decline buttons are unaffected — those already force an answer either way. Requiring consent is a legal decision as much as a form setting, so read the caution before asking for it.
See Acquisition form reference.
The verification code email is sent in your Campaign's language. The short code emailed at sign-up used to arrive in English whatever language the Campaign ran in. It now follows the Campaign's language, translated into English, French, German, and Italian, with English for Campaigns in any other language. It follows the Campaign's default language rather than the one a visitor picks with the language switcher, so a Campaign offering several languages emails everyone in its default one.
See Acquisition form reference.
Events
Booking limits per participant now work on bookable Activities. A per-participant limit — a total cap, or a daily or weekly one — was only ever enforced on Check-in Only Activities. On a Booking + Check-in Activity you could set one, save it, and publish, and participants booked straight past it. The limit now applies when someone books, and only confirmed bookings count towards it, so a cancellation gives a participant their allowance back.
Because this makes previously inert settings live, check the numbers on any Activity you already have running.
See Configure booking restrictions.
Admin & Access
Each Studio user signs in one way. A user account is now tied to a single sign-in method, set on the account by an administrator through the Authentication Provider field. If your organisation uses company single sign-on, the people assigned to it can no longer sign in by email link instead — so whatever your identity system enforces, such as multi-factor authentication, now genuinely applies to OmniLab. The sign-in page also explains refusals in plain terms, including when someone tries the wrong method.
Rolling this out is a per-user migration rather than one environment-wide switch, and there is no per-user fallback once someone is moved.
See Users and authentication and Company sign-in (SSO).
Integrations
The email verification screen speaks your participants' language. When double opt-in is on, the screen asking someone to confirm their address — and the page they land on after clicking the link — now follow the Campaign's language instead of always appearing in English. The wording ships translated, and you can rewrite any of it in your Campaign's form copy.
See Set up double opt-in email verification.
A publish error you were told about but couldn't see. When double opt-in is switched on for an organisation and nothing is set up to send the confirmation email, no campaign in that organisation can be published. That error was counted in the campaign's issue total but was left out of the list behind View Details, so you were told to fix something the screen never named. It now appears alongside every other issue, under Auth, and its instructions name the exact screens to open — including the two things that make a binding count: it has to be active, and it has to cover this campaign's organisation.
See Set up double opt-in email verification and Validation & publishing.
Developers
Contact hooks receive the full submitted contact. Hook inputs now include the marketing consent the visitor gave, their phone number, and the form's additional answers — enough to tailor a verification email or a validation rule without a second lookup. Every hook invocation also carries the Campaign and organisation it came from, so one function can serve many Campaigns instead of one per Campaign.
A contact's name now arrives in one of two shapes, so build any greeting with the SDK's name helper rather than reading the first name directly.
See the Function SDK reference and Hook functions.