SyteLine: License Limit Reached and Users Cannot Log In
SyteLine license limit reached cannot log in no licenses available
Also searched as
- 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
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.
Applies to: Infor SyteLine 8.x and CloudSuite Industrial (on-premises and multi-tenant admin views differ; menu names vary by release)
How to clear a license or session limit lockout
- 1Have 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).
- 2Sort sessions by last activity. Sessions idle for hours from users who went home are almost always dead.
- 3Separate human sessions from service accounts: integrations, scheduled reports, SSRS data access and the background task processor also consume sessions.
- 4Release 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.
- 5Ask the locked-out user to close the browser tab or client completely and log in again.
- 6If no administrator can get in, recycle the application pool or Mongoose service on the application server. This drops every session, so announce it first.
- 7Check your license entitlement against actual named and concurrent usage with the account team or Infor support before buying more.
- 8Fix the leak: shorten idle timeout, correct the integration that opens a session per call, and stop shared logins.
Why licenses look exhausted when they are not
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
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.
-- 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
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.
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Is it safe to end another user's session?
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?
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?
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?
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.
Related
Diagnosing and fixing SyteLine session timeout errors
SyteLine session timeouts come from one of three independent layers: the IDO Data Service session timeout on the app server, the IIS/application pool idle timeout for the web (Mongoose Web) client, or a load balancer/proxy idle timeout in front of a CloudSuite hosted environment. Fixing the wrong layer is the most common mistake - you need to identify which layer is actually expiring the session before changing anything.
AdvancedHow to Schedule a Background Task in SyteLine Task Manager
SyteLine's Task Manager lets an administrator schedule recurring background work - an MRP or APS regeneration, a report run, a custom IDO method, or an external program - without a user triggering it manually from the client. You define a task with what to run and on what recurrence, and the Task Manager background service picks it up and executes it at the scheduled time.
Error fixSyteLine error: this row has been modified by another user since you began editing it
This is SyteLine's IDO optimistic concurrency check. It fires when the row's timestamp column (usually ts_prefix or a similar rowversion field) on the database no longer matches the value the client loaded, meaning another session, a background job, or an integration already saved a change. Refresh the record and reapply your edit; if it recurs constantly on one record, look for a duplicate integration process or a stuck lock rather than user contention.
AdvancedHow to Improve SQL Server Performance for a Slow SyteLine ERP System
Most SyteLine performance complaints trace back to a handful of SQL Server issues: stale statistics, missing indexes on high-churn IDO tables, blocking caused by the default isolation level, and IDO Runtime connection pool exhaustion. Working through those systematically, with DMV evidence, resolves the majority of slow system tickets faster than guessing at application-layer causes.
Error fixFixing SyteLine's 'Object reference not set to an instance of an object' error
This is a generic .NET NullReferenceException surfacing through the SyteLine IDO Runtime, not a SyteLine-specific error code. It almost always means a form, script or IDO method referenced a field, row or object that came back null, usually after a customization, a missing related record, or a view/IDO method call before the form finished loading. Turn on detailed client logging and check the most recent customization or form event first.
Error fixResolving SyteLine multi-site replication conflict errors
A replication conflict in SyteLine's multi-site architecture means the same record (commonly an item, customer, or BOM) was changed independently at two sites between replication cycles, and the replication engine could not automatically merge the two versions. Check the replication conflict log first to see which record and which fields collided, then decide which site's version should win before resuming the queue.
AI for ERPAI for Infor SyteLine and CloudSuite Industrial
Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.
Stuck on Infor SyteLine (CloudSuite Industrial)?
Talk to engineers who work inside Infor SyteLine (CloudSuite Industrial) every week, and who build private AI that answers these questions from your own ERP data.