Pass a known customer into an experience
Open an experience as a specific customer you already recognise, so they play immediately with no sign-in screen.
Open an experience as someone you already know, so they go straight in without a form or a sign-in screen. This is what turns a scanned loyalty card, or a tap inside your app, into an instant start.
It works by adding one parameter to the experience address: fci, carrying the identifier your own system uses for that customer.
When to use it
- A kiosk in-store. A member scans their loyalty card; the kiosk adds the scanned value and opens the experience as them.
- Your mobile app. The app already knows who is signed in and passes them through, so they never sign in twice.
- A personalised email or link. A message sent to a known contact can open the experience as that contact.
The alternative — letting them sign in inside the experience — is covered in About customer accounts. Use that when you do not already know who they are.
The address
https://experience.example.com/<campaign-public-link>?fci=<your-identifier-for-the-customer>The value is whatever your own system uses to identify that person — the number on a loyalty card, a member id, a CRM contact id. It is the same value your identity system will be asked about.
Two things have to be true
Your customer identity system is connected to OmniLab. Without it, OmniLab has nothing to check the identifier against. See About customer accounts.
The value matches what your system holds. If it does not resolve to a known customer, the visitor sees a message telling them the account could not be found, and cannot continue.
Test the unrecognised case deliberately
The check is strict by design — an unrecognised value blocks the session rather than falling back to an anonymous one. Scan a card that should not work, or pass a made-up identifier, so you know exactly what a customer sees when their card is mistyped, expired, or from a different programme. On a kiosk this is the difference between a clear message and a dead screen.
For your developer
The presence of fci forces an authenticated session: OmniLab redirects through your configured identity flow rather than loading the experience anonymously, carrying the original query string through the redirect. If the identifier resolves, the visitor lands already signed in and their participation is attributed to that contact. If it does not, a blocking dialog appears and there is no anonymous fallback.
The dialog's wording is overridable through the experience's custom labels, so you can replace the default text with something that tells the visitor what to do in your context — retry at the kiosk, or ask a staff member.
fci is also read from the referring page on the experience's own API calls, so it keeps applying after the initial page load.