Login

Login authenticates returning customers by matching an identity value to an existing borrower record. The customer types their ID — cedula, RUC, or whatever identifier the tenant uses — the system looks it up, and if found, links the conversation to that borrower. From that point forward, subsequent nodes can read and write to this customer's data.

This is for customers who already exist. New customers need Create Borrower first — Login is the "welcome back" path.

The Typical Pattern

Most flows start with a Login attempt. If it succeeds, the customer continues with their existing record. If it fails — meaning the ID doesn't match anyone — the flow branches to create a new account.

The Login node handles retry logic internally. If the customer mistypes their ID, they get an error message and can try again — no need to build retry loops in the flow. Only after exhausting all attempts does the node route to the failure path.

When to Use It

Use Login for returning customers — collections, renewals, account inquiries, support requests. Use it before sensitive operations like showing account details or processing payments. Use it when you need session management to prevent duplicate concurrent conversations.

Don't use Login for new customer onboarding (use Create Borrower), anonymous interactions that don't need authentication, or when you just need to capture an ID without verifying it against existing records (use Ask Question with validation instead).

Configuration

The identity type determines what kind of ID to look up — typically person_id for cedula (national ID), tax_id for RUC (tax identification), or similar keys from the tenant's data model. The system searches for a borrower with an identity record matching that key and the value the customer enters.

Adding OTP Verification

For sensitive operations, you may want to verify the customer's identity beyond just knowing their ID number. Enable Require OTP in the OTP tab, and after a successful credential match, the node sends a one-time code before granting access. The OTP configuration works identically to the standalone OTP Verification node — same contact source options, same delivery channels, same retry and timeout settings. The difference is context: Login's OTP confirms the person entering the ID actually controls the associated phone or email, adding a security layer to authentication.

When OTP is enabled, the success handle only fires after both the credential match and the code verification pass. Failed OTP attempts follow the same max-attempts logic, eventually routing to the failed handle.

Session Control

The Advanced tab offers controls for managing concurrent sessions. When unique session per borrower is enabled, the system checks whether this borrower already has an active conversation elsewhere. If they do, you can show a message explaining the situation and optionally redirect them — target a specific flow and node (like Jump To), or hand off to a human agent. This prevents scenarios where a customer starts a new conversation while another is mid-process, useful when flows modify data and shouldn't run in parallel.

Output Handles

Prerequisites

The customer must already have a borrower record with an identity of the type being checked — if looking up person_id, they need an identity record with that key. For OTP-enabled logins, the borrower also needs a Point of Contact (POC) record matching the configured contact type (phone POC for SMS or WhatsApp delivery, email POC for email delivery).