Handling session timeout warnings for guest users on long Pega self‑service submissions

I am looking for recommendations and best practices for handling session timeouts for guest users on a Pega self‑service online submission flow.

Context:

We have a public‑facing self‑service case type that is accessed by unauthenticated (guest) users. The submission experience is relatively long and form‑heavy. Users may spend a significant amount of time on a single screen or across multiple screens entering data, reviewing information, or temporarily stepping away before completing the submission.

The issue we are seeing is related to session timeout behavior for guest users:

  • Because the user is unauthenticated, the session timeout is relatively short compared to authenticated users.

  • If the user is idle on a screen for too long, the session expires without sufficient warning.

  • In some cases, the user only discovers the timeout after attempting to submit or navigate, resulting in an error, redirect, or loss of entered data.

  • From a user‑experience perspective, this is especially painful because the user may have spent a long time entering information and has no easy way to recover it.

We are trying to improve the experience by warning the user before the session expires and/or by keeping the session alive while the user is actively working. However, there are a number of constraints and open questions:

  • This is a guest user scenario, so we cannot rely on authentication‑based session extension patterns.

  • We want to avoid introducing custom or unsupported behavior that could break with future Pega upgrades.

  • We are mindful of security considerations and do not want to simply set excessively long session timeouts for all guest users.

  • Ideally, the solution would be reusable across multiple self‑service case types and not tightly coupled to a single UI implementation.

  • We are interested in approaches that work with both traditional UI and newer UI paradigms, if applicable.

Some of the approaches we have considered or partially explored include:

  • Displaying a client‑side timeout warning modal with a countdown before session expiration.

  • Periodically “pinging” the server while the user is actively interacting with the form to keep the session alive.

  • Saving partial progress more frequently so that a timeout does not result in total data loss.

  • Adjusting timeout settings specifically for self‑service use cases, if supported in a controlled way.

What I am looking for from the community:

  • Recommended patterns for handling session timeouts in Pega self‑service flows for guest users.

  • Pega‑supported or commonly accepted approaches that minimize customization risk.

  • Any configuration options, guardrails, or OOTB features that are particularly relevant to this scenario.

  • Lessons learned or pitfalls to avoid when implementing timeout warnings or keep‑alive behavior for unauthenticated users.

  • If applicable, differences in approach depending on UI technology or Pega version.

Any guidance, examples, or references to Pega documentation or community discussions would be greatly appreciated. FYI we are on Pega Infinity '25; users authenticate to the web property through our IdP; the web app server is Liferay; the Pega instance is PegaCloud.

In my opinion, for a guest/self-service flow, I would not rely on extending the session too much. Pega’s guest requestors are intentionally short-lived, and the default idle timeout for guest requestors is about one minute.

What I would suggest is:

  • Auto-save partial progress frequently at each step/screen, so timeout does not mean data loss.

  • Show a client-side warning/countdown before expiry.

  • If the session ends, make sure the user can resume from a draft / saved case state.

1 Like

The recommended pattern is to combine controlled timeout settings ‘warning before expiry’ and ‘frequent save/resume’ so that timeout does not equal data loss.

In Pega, timeout behaviour can be driven either by access group/authentication service or by the external app server/auth service, so in your Liferay + IdP + PegaCloud setup you need to confirm which layer is actually enforcing the timeout first.

Because users authenticate through your IdP and the web tier is Liferay, the timeout may not be controlled only by Pega.

https://community.pega.com/sites/pdn.pega.com/files/help_v84/procomhelpmain.htm#data-/data-admin-/data-admin-authservice/configuring-the-timeout-behavior-tsk.htm

For user experience add a session-expiry warning before timeout. Pega supports warning-message customization for timeout scenarios.

For timeout control, review the Access Group authentication timeout, Authentication Service setting

My recommendation would be to align the timeout settings across those layers, add a client-side warning/countdown, and implement draft/autosave/resume for the submission. That gives a safer and more upgrade-friendly solution than trying to keep guest sessions alive for a long time

1 Like