We are currently performing maintenance on Appian Community. As a result, discussions posts and replies are temporarily unavailable. We appreciate your patience.
I have a portal that is reached by scanning a QR code and takes 1 url parameter and passes it into the initial page where the user can fill out some data. However, if the user navigates away from that page to another page on the portal, and then comes back, the rule input is blank and the url parameter has also been lost. Is there a way to save the user's data so they don't lose it when they navigate back, or at least a way to preserve the url parameter between pages so it can be passed back in to the form?
Thank you,
Jack
Discussion posts and replies are publicly visible
Hi Jack Ferguson Portals Don't have any Stored Cookies and the Moment you refresh your page all the Local Variables also get refreshed .One of the best way would be to have a unique Token Generated During page Load or on Portal Have a button to get unique code and with respect to that code we can get all details in this way we will not lose any data also at run time .
I don't think you can achieve it unless you hardcode that value within your code. Will your parameter always have the same value or every QR code passes a new value in the parameter?
We Can Have token as Particular Key to Handle Instance Data and then the moment it goes to Appian we can keep the necessary Details . As For Every QR an instance will happen with respect to token we can manage the Value associated with that QR so then refresh page will not be a blocker .Now it depends to have token associated with QR or assign it through Portal.
Moreover if we are Concerned with Unused token Space we can have a scheduler(Empty Records Cleaner) which can help in Space Optimization also.
Harshit,
Each QR code will pass a different parameter (a serial number for the product). So we can't hardcode the value. I also found your article on Appian Space titled "Preserving the State of Navigation/Selection" and it seems like that plugin would work (when called from a web API), however I can't figure out how to uniquely identify the user so I can retrieve the correct cashed data. Is there any kind of portal property that uniquely identifies the instance and doesn't change if the user changes the page?
Daisy,
Is there a way to have a unique token or key for each instance of the portal that persists when the user changes the page? Since all url parameters are lost on page change, we can't store the token in the QR code and pass it as a parameter. If there is a parameter in Appian we can access, that would be perfect.
Thanks for checking the blog. Appretiate it.
Coming to your question, plugins don't work on Portals. And as you said, there is no way to uniquely identify a user on the portals because portals are used for anonymous users.
Hi Jack, Were you able to resolve it or handle it with some workaround? Asking as we may face same blocker in our application.
Shivika,
No, I was not able to resolve this issue. While I was able to use the plugin I mentioned above ("Preserving the State of Navigation/Selection") successfully in the portal via a web API (Harshit Bumb (Appyzie) I believe this is a new feature of 24.1 based on the release notes) there is no way to uniquely identify a user or portal instance in Appian currently.
A work around that should work, although I haven't implemented it yet, would be to have only one page on the portal containing one "master" interface with a rule input that the url parameter is passed into. Then create your own tab system within that interface to call sub-interfaces that can be passed that rule input.
Jack Ferguson said:A work around that should work, although I haven't implemented it yet, would be to have only one page on the portal containing one "master" interface with a rule input that the url parameter is passed into. Then create your own tab system within that interface to call sub-interfaces that can be passed that rule input.
This is exactly what I would do.
I think that the use case for a user clicking a personalized link, is to guide the user through a very streamlined process, but not to allow free navigation.
So you could just have two portals. One for free navigation, and the other to support that straight process for which the user needs that special link.
Thanks Jack Ferguson and Stefan Helzle , we are also inclining towards having one page though our requirement is for a site instead of portal. But one page would definitely help in maintaining the URL parameter.