Skip to main content
Solved

Can the "Session Expiring" countdown duration be increased in Assyst?

  • Oct 29, 2026 6:45 PM UTC
  • 2 replies
  • 15 views
Hero (Customer)
Forum|alt.badge.img+10

Hi,

Is it possible to modify the duration of the "Session Expiring" countdown associated with the Maximum Session Life system parameter in Assyst?

From what I can see, the warning dialog currently gives users only 60 seconds to respond before their session is terminated. This can be challenging because users are not continuously aware of session time or how much remains, and the warning may appear while they are focused elsewhere.

In practice, this results in users being logged out while they have work in progress, causing unsaved work to be lost if they do not notice the warning in time due to a conversation or working on multiple monitors.

I have not been able to find any related system parameters that control the warning period separately from the session lifetime itself.

Does anyone know whether the behaviour can be modified in some ohter way (for example within assystEAR.ear or similar) in an on-premises deployment?
Or would this require an enhancement request to IFS before it can be changed?

Any guidance or experience with this would be appreciated.

Best answer by LukaszK

Hi,

There is currently no system parameter that controls the length of the "Session Expiring" countdown - the warning period is fixed in the product. The Maximum Session Life parameter (webFrontEnd/MaxSessionLife) only controls the overall session length; when the user selects OK on the warning, the session is extended by the full Maximum Session Life again.

Modifying the behaviour inside assystEAR.ear (e.g. the client-side scripts) is not supported - such changes would be overwritten by every upgrade/service update and may affect the supportability of the environment - so we would not recommend this.

To reduce the impact in the meantime:
- Consider setting Maximum Session Life so that it comfortably covers a normal working day (e.g. 600-720 minutes, the default is 720), so the warning only appears for users who stay logged in beyond that.
- Inactive sessions are handled separately by the Session Timeout Period parameter (webFrontEnd/SessionTimeout), which only applies when there is no activity - so a longer Maximum Session Life does not prevent idle sessions from being closed.
- Setting Maximum Session Life to 0 disables the limit entirely, but this is only recommended for closed systems due to the risk of unattended sessions remaining active.

If a configurable warning period (or a longer default countdown) is a requirement for you, we would recommend submitting it as an enhancement suggestion through the usual enhancement request process, including your business case (users working across multiple monitors losing unsaved work).

References:
https://wiki.axiossystems.com/assyst26R1Wiki/index.php/Maximum_Session_Life_System_Parameter
https://wiki.axiossystems.com/assyst26R1Wiki/index.php/Session_Timeout_Period_System_Parameter

View original

2 replies

LukaszK
Do Gooder (Employee)
Forum|alt.badge.img+3
  • LukaszK
  • Do Gooder (Employee)
  • Answer
  • Oct 30, 2026 11:58 AM UTC

Hi,

There is currently no system parameter that controls the length of the "Session Expiring" countdown - the warning period is fixed in the product. The Maximum Session Life parameter (webFrontEnd/MaxSessionLife) only controls the overall session length; when the user selects OK on the warning, the session is extended by the full Maximum Session Life again.

Modifying the behaviour inside assystEAR.ear (e.g. the client-side scripts) is not supported - such changes would be overwritten by every upgrade/service update and may affect the supportability of the environment - so we would not recommend this.

To reduce the impact in the meantime:
- Consider setting Maximum Session Life so that it comfortably covers a normal working day (e.g. 600-720 minutes, the default is 720), so the warning only appears for users who stay logged in beyond that.
- Inactive sessions are handled separately by the Session Timeout Period parameter (webFrontEnd/SessionTimeout), which only applies when there is no activity - so a longer Maximum Session Life does not prevent idle sessions from being closed.
- Setting Maximum Session Life to 0 disables the limit entirely, but this is only recommended for closed systems due to the risk of unattended sessions remaining active.

If a configurable warning period (or a longer default countdown) is a requirement for you, we would recommend submitting it as an enhancement suggestion through the usual enhancement request process, including your business case (users working across multiple monitors losing unsaved work).

References:
https://wiki.axiossystems.com/assyst26R1Wiki/index.php/Maximum_Session_Life_System_Parameter
https://wiki.axiossystems.com/assyst26R1Wiki/index.php/Session_Timeout_Period_System_Parameter

    Hero (Customer)
    Forum|alt.badge.img+10

    Thank you very much for the reply. 🙂

     

    We have not previously made use of the Maximum Session Life parameter because the 60-second warning period has proven too disruptive when users do not notice the dialog in time.

    The reason I raised the question was to better understand what options are available when determining an appropriate balance between the “Session Timeout Period” and the overall session lifetime and keeping a balance between end user and agent sessions.

    We are currently testing a shorter session timeout and have seen positive results without affecting agents with multiple tabs so this might be unneeded. One alternative we were considering was keeping the existing timeout values while using a shorter Maximum Session Life value, effectively presenting end users with an "Are you still there?" prompt after, for example, an hour of activity. Our assyst agents could then be exempted through the Ignore Max Session Timeout privilege.

    However, if the duration of the countdown cannot be changed, we already know this would not be a realistic alternative to consider due to the disruptive impact on users who are temporarily distracted, working on multiple monitors, or otherwise miss the warning dialog.

    Thank you again for taking the time to clarify this. We'll review the available options and consider whether an enhancement request would be appropriate.

     

    Regards

    Richard

    Terms & ConditionsAccessibility statement