User Login

Audience: Low-code Engineers

Skill Prerequisites: Actions, Tokens, Users

Signs a user in to the site with a username and password. It checks the password against the site's own user accounts. On success, the user gets a login cookie and the [User:*] tokens, such as [User:UserID] or [User:FirstName], refer to the signed-in user in the actions that follow.

This action replaces the old form-field-based User Login action. You pass the username and password as parameters, usually from form fields or tokens.

It isn't available in Automation (workflows and scheduled jobs), because signing in needs a browser to receive the login cookie.

Typical Use Cases

• Build a custom login form
• Sign a user in straight after User Registration
• Let users sign in with their email address instead of their username

Don't use it to

• Check a password without signing the user in. Use User/Password Validation instead.
• Sign in users from Active Directory or an LDAP server. Use User Login (MS Active Directory) or User Login (OpenLdap).
• Sign a user in without a password, for example from an email. Use Create Auto Login Link, and read its security notes first.

Related Actions

Action Name	Description
User Registration	Creates a new user account. It doesn't sign the user in.
User/Password Validation	Checks a username and password without signing in.
User Login (MS Active Directory)	Signs in a user with their Active Directory account.
User Login (OpenLdap)	Signs in a user with their LDAP account.
Create Auto Login Link	Creates a link that signs a user in without a password.
Send User Reset Password Email	Sends a password reset email, for example from a "Forgot password" link.
Unlock User	Unlocks an account that's locked after too many failed logins.
Authorize User	Authorizes (approves) an account so it can sign in.

Input Parameter Reference

Parameter	Description	Supports Tokens	Default	Required
Username	The username to sign in with. In forms and listings you pick a field, or switch to an expression and use a token, for example [Username]. If it's empty, the action looks for a username field in the submitted data. See Empty Username or Password.	Yes	empty string	No
Password	The password. In forms and listings you pick a field, or switch to an expression and use a token. If it's empty, the action looks for a password field in the submitted data.	Yes	empty string	No
Try Email as Username	When the login fails and the Username value looks like an email address, the action looks up accounts with that email and tries the password against them. See Signing in with an email address.	No	false	No

Output Parameters Reference

The action has no output token of its own. After a successful login, the [User:*] tokens refer to the signed-in user for the rest of the actions, for example [User:UserID], [User:Username], [User:Email] or [User:FirstName].

How the login works

1. The action reads the username and password.
2. It checks them with the site's normal login. This is the same check the standard login page uses, so the site's lockout rules apply. Too many wrong passwords lock the account.
3. On success, it sets a login cookie and makes the user the current user of the action flow.
4. On failure, it stops with the error Login failed! Invalid username or password (status <Status>).

The status tells you why the login failed:

Status	Meaning
LOGIN_FAILURE	The username doesn't exist or the password is wrong.
LOGIN_USERLOCKEDOUT	The account is locked after too many failed logins. Use Unlock User, or wait for it to unlock automatically if the site allows that.
LOGIN_USERNOTAPPROVED	The account isn't authorized yet, for example because the user hasn't verified their email. Use Authorize User.

Host (superuser) accounts can also sign in with this action.

The action doesn't redirect. Add a redirect action after it if the user should go to another page.

Signing in with an email address

With Try Email as Username on, the action first tries the value as a username. If that fails and the value looks like an email address, it:

1. Looks up the accounts that have that email (up to 5).
2. Tries the password against each one, starting with the most recent.
3. Signs in the first account the password matches.

If no account has that email, you get the usual LOGIN_FAILURE error. If accounts have the email but the password matches none of them, the action fails with a general error ("Sequence contains no elements") instead of the login error. Handle this in On Error of an Execute Actions if you want a friendly message.

If your site uses the email address as the username, you don't need this option.

Empty Username or Password

If you leave Username empty, the action looks in the submitted data for, in order:

1. An email field or an [email] token, if a User Registration earlier in the same flow used Register with email
2. A field of type username
3. A token called [username]
4. With Try Email as Username on, an email field, then a token called [email]

If you leave Password empty, it uses [RegRandomPass] from an earlier User Registration with Generate random password, then a password confirmation field, a password field, and finally a token called [password-confirm] or [password].

This lets you put User Login straight after User Registration without setting anything. In other cases, set both parameters so it's clear where the values come from.

Considerations

• Use HTTPS. The password is sent from the browser to the server. Only use the action on pages served over HTTPS.
• The login is persistent. The action always creates a persistent login cookie, like ticking "Remember me" on the standard login page.
• The error shows the status. The error text includes the status, such as LOGIN_USERNOTAPPROVED. That tells a visitor that the account exists. If you don't want that, catch the error with Execute Actions and show your own message.
• Wrong passwords count. Every failed attempt counts towards the site's lockout limit. With Try Email as Username, a wrong password can count against more than one account that shares the email.
• No second factor. The action only checks the username and password.
• Not in Automation. Workflows and scheduled jobs run without a web request, so there's no browser to sign in.

Examples

tip

To understand how to use the below examples, please see Running Examples.

1. Sign in from a login form

This action signs the user in with the values of the Username and Password fields. Users can type their email address instead of their username.

{
    "Title": "User Login",
    "ActionType": "UserManagement_UserLogin",
    "Description": "Sign in from the login form",
    "Parameters": {
        "UsernameField": "[Username]",
        "PasswordField": "[Password]",
        "TryEmailAsUsername": true
    }
}

2. Sign in a user straight after registration

Put this action after a User Registration that uses Register with email. The account's username is the email, so the action signs in with the Email and Password fields.

{
    "Title": "User Login",
    "ActionType": "UserManagement_UserLogin",
    "Description": "Sign in the user who just registered",
    "Parameters": {
        "UsernameField": "[Email]",
        "PasswordField": "[Password]",
        "TryEmailAsUsername": false
    }
}

Revised 09/28/2026