How sign-in works

Employees reach the Leena AI Virtual Assistant through the Web App, the mobile app (iOS and Android) and the desktop app (Windows and Mac). All three sign in through the same platform. This page explains what happens between an employee entering their email and the assistant opening: how the sign-in method is chosen, how each method proves who the employee is, which checks decide whether they are allowed in, and how the session is kept alive afterwards.

Use it to plan a rollout, answer a security review, or work out why a particular employee can't get in. Step-by-step configuration lives on the Admin Console pages linked throughout.

---

Where it's configured

Open the Admin Console. Everything an employee meets while signing in is set on these pages:

Web authentication and Apps authentication are set separately, so the Web App and the apps can use different methods. Other auth settings apply to every channel.

---

The four steps of every sign-in

Whatever the method, every sign-in follows the same four steps.

flowchart LR
    A["Employee opens<br/>the assistant"] --> B["1. Identify<br/>email, phone or<br/>organization"]
    B --> C["2. Prove identity<br/>OTP, SSO, OAuth<br/>or Custom"]
    C -->|"Fails"| G["Sign-in error<br/>wrong code, IdP error"]
    C --> D{"3. Access checks<br/>allowed on this<br/>assistant?"}
    D -->|"No"| F["Access denied<br/>message"]
    D -->|"Yes"| E["4. Session starts<br/>renewed in the<br/>background"]

1. Identify. The employee enters a work email, a mobile number, or (on the mobile app) their organization name. This decides which assistant they are signing in to and which method applies.
2. Prove identity. The employee enters a one-time code, signs in with your identity provider, or is signed in by your own portal.
3. Access checks. Proving identity isn't enough on its own. The platform then checks that this person is allowed on this assistant: that they are in your employee directory, on an allowed domain, and match any access rule you've set.
4. Session. The employee is signed in, and the session is renewed quietly in the background until it reaches its limit.

---

How the sign-in method is chosen

Each channel has one selected method, but a few situations override it.

flowchart TD
    S["Employee enters an identifier"] --> P{"Mobile number?"}
    P -->|"Yes"| O1["OTP to that number"]
    P -->|"No, an email"| F{"Personal email?<br/>e.g. Gmail, Yahoo"}
    F -->|"Yes, on the Web App"| O2["OTP"]
    F -->|"Yes, on mobile or desktop"| R{"Route personal emails<br/>via SSO on?"}
    R -->|"No"| O2
    R -->|"Yes"| M
    F -->|"No, a work email"| U{"SSO or OAuth assistant,<br/>email domain not registered?"}
    U -->|"Yes, and Allow OTP login for<br/>unregistered email addresses is on"| O2
    U -->|"No"| M["The selected method<br/>OTP, SSO, OAuth or Custom"]
    M --> I{"Multiple IDP SSO?"}
    I -->|"Yes"| D["SAML app mapped to the email domain,<br/>or the default app"]
    I -->|"No"| X["Single SAML app or<br/>the selected method"]

These rules only change how someone proves their identity. Every employee still has to pass the access checks afterwards. For example, an employee who gets an OTP through the unregistered-domain option must still be in your synced directory.

---

Proving identity

OTP (one-time code)

The employee enters their email or mobile number and receives a 6-digit code by email or SMS. Where WhatsApp delivery is enabled, they can choose to receive it on WhatsApp instead.

• How long a code lasts. A code is valid for about 3 minutes. If the employee asks for another code straight away, the same code is sent again, so whichever message arrives first works. Any code sent in the last 3 minutes is accepted.
• Expired code. The employee sees "OTP has expired. Please resend the OTP." and requests a new one.
• Wrong code. The employee sees how many attempts remain: "Incorrect OTP, you still have 2 attempts left."

Limits protect against guessing and abuse:

A person who hits a limit sees "You've reached the maximum attempts. Please try again after some time." The fix is to wait, not to keep retrying.

Undeliverable email addresses. If an employee's email address is on the email Blacklist, usually because earlier emails to it bounced, no code is sent. The employee sees "We can't deliver an OTP to your registered email address. Please contact your IT or HR Admin to update your email." Correct the address in your HR system; requesting more codes won't help. An employee who signs in with a mobile number gets the code by SMS instead.

Checking delivery before go-live. Send test OTP on Web authentication and Apps authentication sends a real code to a mobile number or email you type in. It tests delivery only and doesn't change any settings. If the test code doesn't arrive, check SMS and email delivery in Email logs.

SSO (SAML 2.0)

With SSO, employees sign in with their company account through your identity provider (IdP), such as Microsoft Entra ID, Okta, ADFS, Google or OneLogin. Leena AI never sees their password. Each IdP connection is a SAML app, which you then select on Web authentication or Apps authentication.

Single or multiple identity providers

For Multiple IDP SSO, you don't need a default if every row lists domains. If any row has no domains, exactly one row must be the default, and the default row can't have domains of its own.

What happens during an SSO sign-in

sequenceDiagram
    autonumber
    actor E as Employee
    participant L as Leena AI
    participant I as Your IdP
    E->>L: Opens the assistant and enters a work email if asked
    L->>L: Picks the SAML app by email domain or default
    L->>I: Sends a sign-in request with the email pre-filled
    I->>E: Shows your company sign-in and MFA
    E->>I: Signs in
    I->>L: Returns a signed SAML response with claims
    L->>L: Verifies the signature and reads email and employee ID
    L->>L: Runs the access checks
    L->>E: Returns a single-use link to the assistant
    E->>L: The link is exchanged for a session

• Starting from your IdP. Employees can also start from a tile in your IdP's portal, such as the Okta dashboard or My Apps. Leena AI then finds the assistant from the SAML app's Entity ID. If two assistants use the same Entity ID, this kind of sign-in fails, so give each assistant its own SAML app.
• Embedded widget and desktop app. Inside an embedded widget, or the desktop app, the employee sees a Sign in button. It opens your IdP in a separate window, and the session is handed back to the assistant when they finish.
• Mobile app. Your IdP's page opens inside the app in a private browser session, so nothing from it stays on the device after sign-out.
• Back where they started. If the employee opened the assistant from a link, such as an approval task, they land back on that task after SSO.
• Regions. If your IdP sends its response to a different Leena AI region from the one hosting your assistant, it is forwarded to the right region automatically.

What Leena AI reads from the SAML response

Three SSO options on Web authentication and Apps authentication change how these attributes are used:

• Save SAML profile stores selected attributes, such as department or location, on the employee's profile at every sign-in.
• Login field mappers identify employees by a SAML attribute other than email, for example when your IdP sends a unique ID or employee number.
• Successful login message shows employees a short message, up to 200 characters, after they sign in.

Certificate expiry. When an IdP certificate on a SAML app is close to expiring, users with the System Admin or Channel & Authentication Setup Manager role for the assistant get reminders 15 days and 7 days before expiry. Add the new certificate alongside the old one before your IdP switches over.

OAuth

OAuth gives employees a Sign in with button for their Microsoft or Google account, chosen in OAuth provider. For Microsoft, the employee's email is passed to Microsoft as a sign-in hint. If the assistant has a single allowed domain, that domain is passed too, so employees go straight to the right organization. As with SSO, the employee returns on a single-use link, which is exchanged for a session.

By default the assistant uses Leena AI's Microsoft application. To use your organization's own Microsoft app registration instead, contact your Leena AI team.

Custom (Web App only)

Custom sign-in is for assistants embedded in your own portal or intranet. Your portal passes the employee's identity to the Web App, and a Channel authorization expression decides whether it's genuine and who the employee is. You can also set an Auth field to match against a profile field in your synced directory. Custom sign-in can be set up to fall back to another method, such as OTP, when the employee opens the Web App outside your portal. Custom isn't available on the mobile or desktop apps.

External app (mobile app)

Some organizations want employees to sign in through another company app. When an employee uses Find my organization and that organization is set up for it, the Leena AI app hands off to your app. When sign-in is complete there, your app returns the employee to Leena AI already signed in. Your app must be installed on the device. If the employee comes back without finishing, they can close the prompt and try another way.

---

Signing in on the mobile and desktop apps

The apps add a step before the method is chosen: they need to work out which assistant, and which region, the employee belongs to.

flowchart TD
    A["Employee opens the app"] --> R["App finds the region<br/>hosting the assistant"]
    R --> B{"How does the<br/>employee start?"}
    B -->|"Find my organization"| O["Organization name"]
    O --> AUTH
    B -->|"Email or mobile number"| C{"Email domain registered on<br/>an assistant's Apps authentication?"}
    C -->|"Yes"| AUTH["That assistant's<br/>sign-in method"]
    C -->|"No"| X{"Employee found on<br/>how many assistants?"}
    X -->|"One"| AUTH
    X -->|"Several"| P["Employee picks<br/>an assistant"]
    P --> AUTH
    X -->|"None"| N["Not registered message"]
    AUTH --> M1["OTP"]
    AUTH --> M2["SSO in a private<br/>in-app browser"]
    AUTH --> M3["OAuth"]
    AUTH --> M4["External app<br/>(Find my organization only)"]

• Email or mobile number. The sign-in field switches to mobile number entry, with a country code picker, as soon as the employee types a number.
• One domain, one assistant. On the apps, the email domain decides which assistant the employee reaches. A domain can therefore appear in Allowed domains on only one assistant's Apps authentication; saving a domain that another assistant already uses is rejected.
• Personal emails and pre-boarders. If the domain isn't registered anywhere, for example a new joiner using a personal email, the app looks for that person's record across your assistants. If they exist on several, the app asks them to choose one.
• Mobile number sign-in. This only works if the assistant the employee belongs to has Allow login via mobile number on.
• Find my organization. Employees can instead start from their organization name. An unknown name shows "Oops! This Organisation name is not registered with us. Please enter your Organisation's first name or contact your HR team for further support."
• Passcode and biometrics. With Enable passcode on, employees set a PIN that they enter each time they open the app. Enable biometrics lets them use face or fingerprint instead, on devices that support it. These checks run when the app opens and are separate from sign-in. A forgotten PIN is reset with an OTP.
• Desktop app. The desktop app uses the Apps authentication settings, not Web authentication. For SSO it opens your IdP in a browser window and hands the session back to the app.

---

Access checks

Once identity is proven, the platform decides whether this person may use this assistant. The rules come from Other auth settings and the allowed domains. On the Web App, Restrict access by IP on Web authentication is also checked when it's on.

flowchart TD
    A["Identity proven"] --> B{"Account still active?"}
    B -->|"No"| X1["You no longer have access"]
    B -->|"Yes"| C{"Restrict login to<br/>directory users on?"}
    C -->|"Yes"| D{"In the latest<br/>employee sync?"}
    D -->|"No"| X2["Not registered message"]
    D -->|"Yes"| E{"Access rule set?"}
    E -->|"No"| OK["Signed in"]
    E -->|"Yes"| G{"Profile matches<br/>the access rule?"}
    C -->|"No"| E2{"Access rule set?"}
    E2 -->|"Yes"| G
    E2 -->|"No"| F{"Email domain on the<br/>allowed list?"}
    F -->|"Yes, or a personal email<br/>with blocking off"| OK
    F -->|"No"| X3["Not registered,<br/>use your work email"]
    G -->|"Yes"| OK
    G -->|"No"| X4["Not allowed to<br/>access this app"]

---

Staying signed in

After sign-in, the session is renewed in the background, so employees aren't asked to sign in again while they are using the assistant.

Session settings are separate for the Web App and the apps, and a sign-out on one platform doesn't sign the employee out of the other. On the Web App, all open tabs share one session, so signing out in one tab signs out all of them. For how each limit behaves, what employees see and what your IdP controls, see Session & inactivity timeouts.

---

SSO and employee IDs: preventing duplicate accounts

This affects assistants that use SSO when both of these are true:

• Your IdP identifies employees by a sign-in name that is not their HR employee number, typically a Windows or Active Directory account name such as de0o2d.
• The SAML app has no claim rule that supplies the real HR employee number.

What goes wrong. With no employee number in the SAML response, Leena AI uses the sign-in name as the employee ID and saves it on the employee's record. When your HR sync later brings in the same person with their real employee number, it can't match the two: it looks for that employee number, and only falls back to matching by email for records that have no employee ID at all. So it creates a second record. Microsoft Teams then finds two active records for one email address, can't tell which is correct, and refuses the employee every time they try to sign in.

sequenceDiagram
    autonumber
    participant I as Your IdP
    participant L as Leena AI
    participant H as HR sync
    participant T as Microsoft Teams
    I->>L: SAML response with NameID de0o2d and no employee ID
    L->>L: Uses de0o2d as the employee ID and saves record A
    H->>L: Same person with employee ID 104233 and the same email
    L->>L: No record has 104233, and record A already has an ID
    L->>L: Creates record B
    T->>L: Employee messages the assistant in Teams
    L->>T: Two active records for one email, so access is refused

Employee ID 104233 is an example.

What to do. Ask Leena AI support to turn off automatic employee IDs for that SAML app. Leena AI then leaves the employee ID empty instead of guessing one, and your HR sync matches the employee by email and updates their existing record. The change applies from each employee's next sign-in, with no release needed. If duplicate records already exist, ask support to clean those up as well.

Check this whenever you connect a new SSO provider: look at what your IdP sends as the NameID, and whether any claim carries the HR employee number.

---

Troubleshooting

Help for employees. Facing Trouble on the sign-in screen opens sign-in help. Where it's set up, the employee identifies themselves with their organization and employee ID, confirms their masked email or mobile number, and reports the problem. A ticket is raised and they're notified when it's resolved.

Help for admins. Web login errors records each refused sign-in and the reason. When contacting Leena AI support, include the employee's email or mobile number, the channel (Web App, iOS, Android, Windows or Mac), the app version, a screenshot of the exact message, and the time of the attempt with its time zone. For SSO problems, also say which SAML app was used.

---

Related pages

• Web authentication and Apps authentication: set the sign-in method for each channel
• Other auth settings: decide who is allowed in
• SAML apps: connect your identity provider
• Azure AD SSO Config, Google SSO Config and AD SSO Config: IdP-side setup guides
• Employee sync: keep the directory that access checks rely on up to date
• Session & inactivity timeouts: how long employees stay signed in
• Login Screen, Mobile App and Desktop App: what employees see
• Dashboard Authentication: sign-in for dashboard users, which is configured separately