SyteLine Session Timeout Configuration and Fix Guide
SyteLine session timeouts produce the frustrating error "Your session has expired. Please log in again." at the worst possible moments—mid-transaction, during long data entry, or while reviewing a complex report. In CloudSuite Industrial, session management spans multiple layers: IIS session state, IDO runtime tokens, authentication cookies, and load balancer affinity. A misconfiguration in any single layer causes premature timeouts that destroy unsaved work and erode user confidence.
Understanding SyteLine's Session Timeout Stack
SyteLine has four independent timeout settings that must be coordinated. The IIS Session State timeout (default 20 minutes) controls the ASP.NET session. The IDO Runtime token expiration (default 30 minutes) controls the authentication token validity. The Forms Authentication timeout (default 60 minutes) controls the login cookie. The load balancer session affinity timeout (varies by hardware) controls request routing. If any one of these expires before the others, the user gets logged out. The effective timeout is the minimum of all four values.
- IIS Session State timeout: IIS Manager > Sites > SyteLine > Session State > Cookie Settings > Time-out = set to 120 minutes; also set in web.config: <sessionState timeout="120"/>
- IDO Runtime token: SyteLine Configuration Manager > Application Settings > IDO Token Timeout = set to 120 minutes to match IIS session state
- Forms Authentication: web.config > <authentication> > <forms timeout="120" slidingExpiration="true"/> — the slidingExpiration attribute is critical, as it resets the timeout on each request
- Load balancer: configure sticky sessions (session affinity) with a timeout of at least 130 minutes (10 minutes beyond the application timeout) to prevent mid-session routing to a different server that lacks the user's session state
Fixing Data Loss on Session Timeout
Even with properly configured timeouts, users will occasionally experience timeouts during extended idle periods. The real pain is data loss—a user spends 30 minutes entering a complex production order, gets a timeout, and all unsaved data is gone. SyteLine provides mechanisms to mitigate this, but they must be explicitly configured. The AutoSave feature, form state recovery, and timeout warning dialogs protect against data loss.
- Enable the session timeout warning dialog: in SyteLine Configuration Manager > Client Settings > SessionTimeoutWarning = true, SessionTimeoutWarningMinutes = 5 — this shows a popup 5 minutes before timeout with a 'Keep Session Alive' button
- Configure form auto-save: for critical data entry forms, add an AutoSave event handler that triggers every 10 minutes using a client-side JavaScript timer calling the form's SaveCollection method on a background thread
- Implement draft recovery: create a custom IDO that stores form state to a draft table on a timed interval; on form load, check for existing drafts and offer to restore the user's unsaved work
- For users on slow WAN connections (common in multi-site deployments), increase the HTTP request timeout in web.config: <httpRuntime executionTimeout="300"/> to prevent request-level timeouts that masquerade as session timeouts
Troubleshooting Premature Timeout Issues
If users report being logged out after just 5-10 minutes despite all timeouts being set to 120 minutes, the cause is usually the IIS app pool recycling (which destroys all in-memory sessions), a misconfigured web farm without shared session state, or antivirus software intercepting and modifying authentication cookies. These are infrastructure issues that do not appear in application-level logging.
- Check IIS app pool recycling: IIS Manager > Application Pools > SyteLineAppPool > Advanced Settings > verify Regular Time Interval is 0 (disabled) or set to a high value like 1440; each recycle destroys all active sessions
- For web farm / load balanced environments: configure a shared session state store using SQL Server session state: <sessionState mode="SQLServer" sqlConnectionString="..." /> — in-memory sessions (the default) are lost when requests route to different servers
- Disable antivirus real-time scanning on the SyteLine web application directory and the IIS temporary ASP.NET files directory to prevent file lock conflicts that corrupt session state files
- Enable IIS Failed Request Tracing for status code 302 (redirect to login page) to capture the exact moment and reason the authentication cookie was rejected—look for cookie size exceeding 4KB or domain mismatch
Never lose user data to session timeouts again—let Netray's AI agents optimize your SyteLine session configuration across all infrastructure layers.
Related Resources
SyteLine Memory Issues: Troubleshooting Guide
Troubleshoot SyteLine memory leaks, high memory usage, and OutOfMemoryException errors. Fix IIS app pool recycling and optimize CloudSuite Industrial memory.
Infor SyteLineSyteLine Form Loading Slow: Diagnosis and Fix
Diagnose and fix slow-loading SyteLine forms. Address IDO query performance, event handler bottlenecks, and grid rendering issues in CloudSuite Industrial.
Infor SyteLineSyteLine Licensing Errors: Fix Guide
Resolve SyteLine licensing errors including activation failures, concurrent user limits, and license server connectivity issues in CloudSuite Industrial.