# SyteLine: License Limit Reached and Users Cannot Log In

> Source: https://netray.co/erp-help/syteline-license-session-limit-cannot-log-in
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

When SyteLine refuses a login because the license or session limit is reached, the usual cause is not too many real users but stale sessions that were never released: killed browsers, dropped VPNs, service accounts and integrations holding connections open. Find the sessions in the application's session management form, release the dead ones, then fix whatever keeps leaking them.

## Kind

error

## System

syteline

## Erp

Infor SyteLine (CloudSuite Industrial)

## Module

Licensing / Session Management

## Query

SyteLine license limit reached cannot log in no licenses available

## Alternate Queries

- CloudSuite Industrial maximum number of users exceeded
- SyteLine ghost sessions using licenses
- SyteLine users locked out license count
- Mongoose session not released after closing client

## Applies To

Infor SyteLine 8.x and CloudSuite Industrial (on-premises and multi-tenant admin views differ; menu names vary by release)

## Steps

### How to clear a license or session limit lockout

**Items:**

- Have one administrator who is already logged in open the session or user-session management form in your release (search for Session in the form search, the name varies by version).
- Sort sessions by last activity. Sessions idle for hours from users who went home are almost always dead.
- Separate human sessions from service accounts: integrations, scheduled reports, SSRS data access and the background task processor also consume sessions.
- Release or end the stale sessions from that form. Do not kill SQL spids directly unless the application form fails, because the Mongoose session state will not match.
- Ask the locked-out user to close the browser tab or client completely and log in again.
- If no administrator can get in, recycle the application pool or Mongoose service on the application server. This drops every session, so announce it first.
- Check your license entitlement against actual named and concurrent usage with the account team or Infor support before buying more.
- Fix the leak: shorten idle timeout, correct the integration that opens a session per call, and stop shared logins.

## Sections

### Why licenses look exhausted when they are not

**Body:**

SyteLine counts a session from the moment the client authenticates against the Mongoose application server until the session ends or times out. A user who closes a laptop lid, loses a VPN or force-quits a browser does not always send a clean logout, so the server keeps the session until the idle timeout fires. On a busy Monday morning, ten or fifteen of those can be the difference between a normal day and a lockout.

Whether the limit is concurrent or named depends on your contract. With concurrent licensing, ghost sessions directly steal seats from real users. With named users, the symptom is usually an assignment problem instead: a user has no license assigned, or a departed employee still holds a named seat.

### Integrations are the quiet offender

**Body:**

The most common non-human cause is custom code that logs in through the IDO web service or REST API for every request and never logs out. Each call creates a session that lingers until timeout. A script running every minute can hold dozens of sessions open all day without anyone noticing, because the account looks like one user.

Review every service account in the user list. For each, ask what calls it, how often, and whether the caller reuses a token. A well-behaved integration authenticates once, reuses the token, and ends the session when done. If you cannot change the caller, shorten the idle timeout for that account's configuration group where your release allows it.

**Code:**

-- Rough view of connections per login on the SQL side (not a license count)
SELECT login_name, host_name, program_name, COUNT(*) AS connections
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
GROUP BY login_name, host_name, program_name
ORDER BY connections DESC;

### Prevent it from coming back

**Body:**

Set a sensible idle session timeout. Too long and ghost sessions pile up; too short and users on long phone calls lose unsaved forms. Between 30 and 60 minutes is a common starting range, but test with your heaviest data-entry users first.

Put a weekly review on the session list. If the count of sessions per service account keeps rising during the day, you have a leak. Also confirm that terminated employees are disabled in both SyteLine user maintenance and your identity provider, since a forgotten account can hold a named license for years.

## Pitfalls

- Restarting the application server to fix one lockout drops every active user mid-transaction. Release stale sessions first.
- Killing SQL spids directly leaves Mongoose believing the session is alive, so the license stays consumed.
- Sharing one login across a department hides who is using seats and breaks the audit trail.
- Buying more licenses before measuring ghost sessions and integration leaks often fixes nothing.
- Counting SQL connections as licenses is wrong: one session can open several connections and some connections serve no user.

## Ai Angle

SyteRay can sit read-only beside the session and user data and answer "who is holding sessions right now and which service account is leaking" in plain language, showing the query it ran. It does not release sessions by itself; a human approves any action. For license planning, it can compare peak concurrent sessions over a month against entitlement so the conversation with Infor starts from numbers.

## Faq

### Is it safe to end another user's session?

**Answer:** Yes if the session is idle and the user is gone, since unsaved work in that session is already lost. If the user was mid-entry they will see a session error and must log in again. Check last activity first and prefer ending sessions idle for hours over any that show recent activity.

### Why do I still get the error after ending sessions?

**Answer:** Either the sessions you ended were not the ones consuming seats, or new ones are being created as fast as you clear them, usually by an integration. Look at which account recreates sessions immediately and fix that caller. Also confirm the user is not blocked by a named-license assignment instead.

### Does the background task processor use a license?

**Answer:** It authenticates as a configured user, so it holds a session while it runs. Check how your agreement treats system or service accounts. Do not assume they are free. Ask your Infor account team and document the answer.

### Can I raise the session limit myself?

**Answer:** No. The limit comes from your license entitlement, not a setting you can edit. You can tune idle timeouts and clean sessions, but additional capacity requires a license change through Infor or your reseller.

## Search terms

syteline license limit reached, syteline cannot log in, cloudsuite industrial session limit, syteline ghost sessions, mongoose session not released, syteline concurrent users, syteline service account sessions, syteline idle session timeout

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json