Skip to main content
Question

Detect inactivity in Assyst

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

Hi


Is there a way to monitor user activity or inactivity in the Self-Service Portal and/or the assyst Agent Portal to better determine the appropriate session length in assyst, or to identify which users could have their sessions safely terminated?

This is primarily a question regarding Self-Service, as the Self-Service Portal and Agent Portal share the same session length configuration. A business requirement for longer agent sessions on our end result in end-user licences being held for considerably longer than necessary, or so it is believed.

Our current approach relies on tracking actions performed by agents or end users. However, this does not necessarily reflect actual user activity, as there are many legitimate use cases where a user remains active without generating tracked actions, such as browsing the portal or reading knowledge articles or filling a complex self-service form. Therefore, action-based monitoring may not accurately indicate whether a session is truly active or inactive.

Could end-user and/or agent inactivity be more directly monitored on a per-assyst-enterprise-server basis using WildFly, or is there a way to monitor this in a more centralized manner we’ve not come across?

Thank you 

2 replies

LukaszK
Do Gooder (Employee)
Forum|alt.badge.img+3
  • LukaszK
  • Do Gooder (Employee)
  • Oct 29, 2026 3:01 PM UTC

Hello,

Thank you for your question.

assyst does not currently record a per-user "last activity" time for Self-Service Portal or assyst Portal sessions, so there is no built-in report of idle users. However, the following options can help you measure session and licence usage and make an informed decision on session length.

1. How the session timeout works
The Session Timeout Period system parameter (webFrontEnd/SessionTimeout) is an inactivity timeout: a session expires when there have been no requests from the browser for the configured period, and a licence is released when the user has no remaining sessions. Please note that some requests are not user-driven - for example, Message Center content on the home page, auto-refreshing monitors/dashboards, or additional open browser tabs - and these will keep a session (and its licence) active even when the user is not using it. Reviewing such content on the Self-Service Portal can help sessions expire as intended.
Maximum Session Life (webFrontEnd/MaxSessionLife) is a separate, absolute limit on session length, with a prompt to extend.
https://wiki.axiossystems.com/assyst26R1Wiki/index.php/Session_Timeout_Period_System_Parameter
https://wiki.axiossystems.com/assyst26R1Wiki/index.php/Maximum_Session_Life_System_Parameter

2. Current sessions
Administration > User Sessions shows all current sessions with login date, licence type (Dedicated/Concurrent/Integrations), user, server and client details. Sessions can be exported, users emailed (e.g. to warn them) and sessions deleted from here. The same data is held in the web_session table for your own reporting. Note that this shows when the session started, not the last activity.
https://wiki.axiossystems.com/assyst26R1Wiki/index.php/User_Sessions

3. Historic session and licence usage
If you enable auditing on the web_session table, assyst records each login and logout in web_session_at. The example "assyst Usage History" Power BI report (SQL Server only, provided as an unsupported example) uses this to show maximum and average sessions and licences in use over time, split by Self-Service Concurrent/Dedicated and assyst Concurrent/Dedicated. This lets you measure how long Self-Service licences are actually held, and compare usage before and after a session timeout change.
https://wiki.axiossystems.com/assyst26R1Wiki/index.php/Audit_Table_Structure_and_External_Reporting
https://wiki.axiossystems.com/assyst26R1Wiki/index.php/assyst_Usage_History_-_Power_BI_Report

4. WildFly monitoring
Each assyst server exposes the number of active sessions per portal through JMX (e.g. assystSelfService.war and assystWEB.war "activeSessions"), which can be collected by your monitoring tools. These are counts per server rather than per user.
https://wiki.axiossystems.com/assyst26R1Wiki/index.php/Installation:Useful_WildFly_Monitoring_Attributes
At the WildFly level it is also possible to enable an HTTP access log on each server and send it to a central log tool, which shows actual request activity. This is a standard WildFly feature rather than assyst functionality, generates significant log volume, and will also include automatic (non-user) requests as described in point 1.

Separate session timeouts for the Self-Service Portal and the assyst Portal are not currently available in assyst. If this would meet your requirement, we would recommend submitting it as an enhancement suggestion through the usual enhancement request process, describing your business case (longer agent sessions without Self-Service licences being held for longer than necessary), so it can be considered by our Product team for a future release.

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

Hello Lukasz,

Thank you very much for the detailed response 

We have been actively using the web_session_at table together with a set of custom reports to track user sessions. However, the assyst Usage History Power BI report contains some details that our current reporting lacks, so I will be investigating whether we can incorporate some of the same metrics into our own reporting.

Regarding the WildFly attributes, I am slightly surprised that I had not come across these before, as I believed I had thoroughly searched the wiki... If the enhanced reporting proves insufficient for our needs, I will definitely look into monitoring these WildFly metrics instead.

Separate session timeout settings for Self-Service and assyst Portal users is certainly an enhancement we may need to consider, although we are currently exploring whether there are other options available that could address our more immediate requirements.

I do have one follow-up question, if I may.

Is it currently possible to terminate a user session programmatically through the assyst API when authenticated as a sufficiently privileged user, for example an ETM user?

One idea we have discussed is implementing some form of automated emergency licence management. For example, by querying the web_session table through a JDBC SQL Query channel and identifying the oldest sessions, or by having a monitoring platform trigger an event whenever available licences fall below a defined threshold. In either case, the goal would be to automatically end selected sessions to free licences when required.

I have reviewed the API documentation but have not been able to identify a supported way to perform this type of session cleanup. Is this currently possible in assyst 24R2 or later, either through the REST API or another supported mechanism?

Thank you again for your help.

Terms & ConditionsAccessibility statement