Robot sessions

A robot session is a Windows user account that the bot uses to run unattended execution. It stores a (reusable) Windows username and password, and is what gives the robot a desktop to work on when no one is logged into the machine.

It is an environment resource (like machines or credentials). By default it works on any machine in the environment; to limit it, check the Máquinas donde vale (Machines where it applies; none checked = all). The Máquinas column shows its status on each one, and you can Probar inicio de sesión en esta máquina (Test sign-in on this machine) before launching a robot. Only Windows desktop processes need it: Sin pantalla (headless) ones run without a robot session.

Why is it needed? Attended vs. unattended

Mode	How the bot runs	Do you need a robot session?
Attended	In the Windows session of a person who already has their desktop open (she launches the bot on her computer)	No — use the desktop that is already open
Unattended	On a server or VM with no one present, with Agent running as a Windows service	Yes

The key point: interface automation (moving the mouse, opening windows, automate the desktop or a windowed browser) requires an active Windows desktop. In unattended, that desktop doesn’t exist on its own — no one is logged in. The robot session solves this: the agent uses that Windows account to open (or reuse) a desktop session of the bot, and runs the automation within it.

If your bot doesn’t touch the interface

Processes that only use HTTP, databases, files, Excel, SMTP/IMAP mail, or a headless browser do not depend on a visible desktop. Even so, the portal asks you to choose a robot session when launching the execution: it is the Windows account under which the process will run.

Create a robot session

1. In the menu, open Centro › Máquinas › Sesiones de robot (Center › Machines › Robot sessions), in the environment picked at the top right.
2. Click New session.
3. Fill out the form:
   • Name — an identifier for the session (e.g. bot-cuenta-01).
   • Windows user — the Windows account, with domain if applicable: DOMINIO\bot01 or bot01 (local account).
   • Windows Password — the password for that account.
4. Click Create Session.

To change your password later, edit the session and enter the new password (leave it empty to keep the current one).

The password is saved encrypted

The Windows password is stored encrypted and is only used on the agent machine to log in to the bot. It is not shown back in the portal nor does it appear in the logs.

Windows account requirements

For a robot session to work unattended, the Windows account must meet, on the agent machine:

• Remote Desktop Login (RDP) permission The agent opens a desktop session for the bot using a local Remote Desktop connection; The account requires the “Allow login via Remote Desktop Services” right and Remote Desktop is enabled on the machine.
• Batch login. The agent automatically grants the batch login (SeBatchLogonRight) right to the account.
• Valid and non-expiring password. If the password expires or changes, runs will fail at login until you update the password in the robot session. That is why it is advisable to use a service account with a password that does not expire.

Use a dedicated account for the bot

The recommended thing is a Windows account exclusive to the robot (not that of a person), with the minimum permissions that the process needs and a managed password. So the bot has its own desktop, its own configuration and separate traceability.

Use a robot session when running

The robot session is chosen when launching the process:

• In Run Manually, the new run dialog asks for process, agent, and robot session (all three are required).
• In scheduled triggers, you configure the robot session with which each automatic execution will run.

Each selector option displays the name, Windows user, and state of the session.

States

Status (on the portal)	Significado
Disponible	The session is ready to use
No disponible	The account does not have a usable desktop at this time (no active session, or a connection/credentials issue)

The agent reports the status of the sessions to Zoan Cloud; If one becomes Unavailable just when it should run, check that the machine is turned on, that the account can log in via RDP, and that the password is still valid.

Credential rejected by Windows

If Windows rejects a session’s account (the password changed, or the account was locked, expired or disabled), the session shows Credencial rechazada por Windows (credential rejected by Windows), with the reason, the machine where it was detected and what to do.

Why it is not retried on its own. Signing in again with a wrong password does not fix it, and every failed attempt brings the account closer to a Windows lockout, which can also affect other systems that use that account. That is why, once Windows rejects it, neither the Agent nor Zoan Cloud tries it again on their own:

• Runs that need that session are not sent: they fail right away with a clear message and the reason, instead of waiting or piling up attempts.
• With a domain account, the session stops being used on every machine. With a local account, only on the machine that rejected it; if there is no other machine where it can sign in, the run says so.
• In a flow, the step becomes an incident with the action Actualizar la sesión de robot (update the robot session) and the Ir a Sesiones (go to Sessions) link. The robot never ran, so retrying it afterwards is safe.

How to fix it.

Reason	What to do
The user name or password is not valid	Click Actualizar contraseña (update password) and enter the current password. Once saved, the session is used again on every machine.
The account is locked	Wait for Windows to unlock it, or unlock it. Zoan Cloud tries again on its own only 15 minutes after the rejection.
The password expired or must be changed	Change it in Windows and then update it in the session.
The account is disabled or expired	Enable it (or extend its validity) in Windows and test the session again.
The account is not allowed to sign in on that machine	Check the Remote Desktop sign-in right and the account’s time-of-day or workstation restrictions.
The machine could not validate the account (no connection to the domain)	Check the machine’s network and domain membership. This case does not mark the session as rejected: it is a problem with the machine, not the account.

The badge clears on its own when you change the user or enter a new password, when a test of the session succeeds, or when a later run signs in without trouble. Changing only the name or the allowed machines does not clear it.

Error codes

Runs that fail because of the session’s account show one of these codes, with the plain message first and the technical detail below. The password never appears.

Code	Meaning
session_credentials_invalid	Windows rejected the robot session’s user name or password.
session_account_locked	The robot session’s account is locked by Windows.
session_password_expired	The robot session’s password expired or must be changed.
session_account_disabled	The robot session’s account is disabled or expired.
session_logon_denied	The account cannot sign in on that machine.
session_logon_unavailable	The machine could not validate the account (no connection to the domain controller). It is treated as a temporary problem.

The password, always protected

The Agent remembers that a credential was rejected without storing the password, and its latest version no longer passes the password on the command line when it opens the robot’s desktop session.

Robot vs. session credential

Don’t confuse them — they are different and complementary things:

	Robot session	Credencial
What does it keep	The Windows account under which the bot runs	Secrets of systems that the bot uses (ERP, email, API, DB)
for what	Give the bot an unattended desktop	Let the playbook access a system without exposing the secret
How to use	It is chosen when executing the process	It is referenced in the playbook with credential("nombre")

Which one do I need?

Almost always both, for different things. Think about it like this:

• Where does the bot run? → a robot session (the Windows account that gives you unattended desktop). One per machine/account, chosen at launch.
• What systems does the bot enter? → a credential for each system (the ERP, the email, the database). As many as systems use the playbook.

Example: a bot that runs at night to download invoices from a portal needs a robot session (to have a desktop) and a credential with the portal username/password.

Next steps

• What is an agent — the machine where the bot runs.
• Run manually — choose the robot session when launching.
• Credential Management — secrets of the systems the bot uses.