How the mobile and desktop apps choose a bot at sign-in
In a browser or in Microsoft Teams, the link or the Teams app already identifies the assistant (bot) an employee is signing in to. The Leena AI mobile and desktop apps only get what the employee types — an email address or a phone number — so before sign-in can start, Leena AI has to work out which bot that person belongs to.
With a single bot, this is invisible. With several bots in one company — typically a UAT bot and a production bot — the setup decides whether employees land on the right one, and whether they get in at all.
How a bot is chosen
There are two steps. The second runs only if the first doesn't sign the person in.
Step 1 — by email domain. Leena AI looks for the bot that lists the email's domain under Add allowed domains on Apps authentication. If that bot's access rules let the person in, they're signed in to it. Only work email addresses take this step — personal addresses, such as Gmail, and phone numbers go straight to step 2.
Step 2 — by existing employee record. Leena AI finds every bot where the person already exists as a user, matched on their email address or, for phone sign-in, their phone number. Email domains play no part here. Leena AI tries those bots in turn and signs the person in to the first one whose access rules let them in. If none does, sign-in fails with an access-denied message.
The order bots are tried in step 2
| Situation | Order |
|---|---|
| Prefer production bot is on for the company | Only the person's records on production bots are tried, if they have any. Records on UAT and other non-production bots are skipped entirely |
| Prefer production bot is off (the default) | Records are tried in the order they're stored — usually the oldest first. For an organisation that ran UAT before going live, that's normally the UAT record |
| A personal email address, with records on several bots | Unless Prefer production bot has already narrowed the list, a bot with Route personal emails via SSO on is tried first, so its sign-in method is used |
Prefer production bot is a company-level setting with no Admin Console control. Ask your Leena AI team to switch it on.
When step 2 refuses outright
- The same email address or phone number exists on bots in different companies.
- The person has more than one record on the same bot — for example after an employee ID change.
- The person is signing in with a phone number and Allow login via mobile number is off on the bot.
What decides access on each bot
Every bot Leena AI tries applies its own access rules — the same ones it applies in the browser:
- Restrict login to directory users and Channel authorization expression, on Other auth settings.
- Add allowed domains on Web authentication, when no channel authorization expression is set.
Once a bot accepts the person, they sign in with the method set on that bot's Apps authentication page — OTP, SSO or OAuth. On SSO and OAuth bots with Allow OTP login for unregistered email addresses on, employees whose domain isn't one of the registered SSO domains get an OTP instead.
Two settings called "Add allowed domains"
The Apps authentication and Web authentication pages both have a field with this name, and they do opposite jobs.
| Page | What it does |
|---|---|
| Apps authentication | Routing only. It sends work emails on that domain to this bot in step 1. It doesn't block anyone — people on other domains can still sign in through step 2. Leaving it empty doesn't restrict anything either; the bot just can't be found by domain |
| Web authentication | An allowlist. People whose email isn't on one of these domains are refused, unless a channel authorization expression is set |
A domain can belong to only one bot in Apps authentication. Saving it on a second bot is refused while another bot holds it, so remove it from the old bot first.
A UAT bot and a production bot
After go-live, most organisations have a UAT bot and a production bot in the same company, and most employees have a record on both from the UAT phase. Here's how each setup behaves:
| Setup | What employees experience |
|---|---|
| Domain on the production bot | Everyone production accepts signs in to it in step 1. Anyone it refuses goes to step 2 — where, with Prefer production bot off, they can still land on UAT if UAT accepts them |
| Domain on the UAT bot only | Everyone UAT accepts signs in to UAT. It looks like a normal sign-in, so nobody reports it. Everyone else goes to step 2 |
| Domain on neither bot | Everyone goes through step 2. With Prefer production bot off, the older UAT record is usually tried first, so anyone UAT accepts lands on UAT |
Recommended setupRegister the domain on the production bot only, and ask your Leena AI team to switch on Prefer production bot for your company. Employees then land on production, and the UAT bot stays reachable in the browser through its own link.
Before go-live
- Is your work email domain listed under Add allowed domains on the Apps authentication page of the bot employees should land on — usually production?
- Is it still listed on any other bot? Remove it there first; only one bot can hold a domain.
- Do employees have records on more than one bot? If so, ask your Leena AI team to switch on Prefer production bot.
- Test with at least three people: someone the UAT bot accepts, someone only valid on production, and someone who exists only on production. Check which bot each one lands on — a successful sign-in on its own doesn't prove it's the right bot.
The order of bots in the bot switcher doesn't affect which bot the apps choose at sign-in.
Updated 34 minutes ago