We are exploring whether the client portal has a timeout mechanism for inactive sessions. Specifically:
Does the portal automatically log out users after 15 minutes of idle time or total login duration?
If a timeout occurs, is there an option to auto-save the user’s progress to prevent data loss?
user logs into the client portal to update Location details. While entering data, the user gets distracted or steps away for more than 15 minutes. If the session times out, any unsaved data is lost, potentially requiring the user to re-enter all information.
Discussion posts and replies are publicly visible
I am a bit confused. Do you specifically mean "Portals", or the normal environment built using "Sites". I ask, because in "Portals", there is no such thing as a log in.
We have developed a portal with email ID and password-based login, linked to the opportunity ID (OppID), which will be shared via email to collect customer information.
In that case then I assume you could implement something manually. You would basically be forced to "cache" every user input immediately upon their inputting it (i.e. sending to some sort of temprary table, etc), then once they successfully submit the portal form, "clear" that "cache". Therefore any time they "log in" (via your bespoke login system), the form would check whether there are any outstanding "cache" entries and use that to pre-populate their form.
you'd also need to manually build a "timeout", assuming this functionality works in a Portal (which i haven't tested) - you'd merely load a local variable (at page load) that stores the time of first load, then set an auto-refreshing local variable to the current time (updating every .5 or 1 minute), and once the delta between the two variables grows to whatever you want your "timeout" to be, simply hide the original form and instead display a "page timed out" message.
Assuming that you've had the form "cache" all of their previous inputs as I described in the prior comment, now they'll be forced to reload their form and after they "log in" again, it should pre-populate anything they'd entered.
I don't know your customer or contractual situation, and the Appian Product team can't provide authoritative licensing answers.
However, if you find yourself creating custom password-based login UIs in an Appian Portal object, there are two risks you should consider:
1. You should double-check the security of your app and system. You're missing the layers of protection that come with our OOTB authentication, which you can't recreate yourself within an app. you're already experiencing part of this, which is having to attempt to manually recreate session timeouts.
2. You should double-check whether you're within the bounds of your licensing. Appian Portals is specifically licensed for unauthenticated users, so if you're creating a login experience you may be outside the bounds of what your licensing allows. There is a precise contractual definition of what's allowed to count as an unauthenticated user, and it does allow for some patterns like verification codes, and going through your account team can resolve any ambiguity.
If you want an authenticated experience, I'd start with Appian Sites, and let us know if there's something you can't achieve there which is pushing you toward Portals.