One function of our app is that clients can categorize items in the table and favorite them. I need a function that allows each client organization to share a link to a page or a view of the items they have favorited and categorized. that can be visited by external stakeholders (their members, clients, etc.). Users of our app generally need to be signed in but this page would need to be visible to anyone with the link, no sign in required.
I have a working approach that isn’t very satisfactory, and I’m wondering if there are suggestions here for a better approach. My approach is to create a separate page in the app for each client organization give the page slug the name of the organization and then provide that resulting url (example.com/dl/OrgName) to the client.
The problem with this approach is its tedious to set up (creating and name a dozen plus pages) and somewhat tedious to maintain.
The ideal approach would be where one could have one page and a URL parameter could be accessed to filter the results to match the client. I tried using the get part of url column to do this (e.g. example.com/dl/client?=OrgName) and then use the value after “client?=” to filter the table. Worked great except that when a person clicks on an item to view its details (in this case in an overlay) as soon as the overlay is visible, you can see the page behind it change to whatever is at example.com/dl/client (the query value is gone) and when they close the overlay the filtered page is gone since the url is now just “example.com/dl/client”.
So two questions: 1. Is there a fix to the disappearing url parameter problem described above? I’m less worried about them manipulating the url intentionally. I just want to make sure they are always viewing the intended page at client?=OrgName. OR 2. Is there another approach that could accomplish having essentially a dynamic page without having to create a page for each client.
Create a separate public app with a linked table… or,
In your existing app, make sign in optional and protect non public pages with row owners and visibility conditions.
In both cases, you’ll need to create a landing page tab that points to the table of unique favorite lists per user. Add a collection. You’ll need to decipher the deeplink of the details screen for each record:
Use Glide‘s short.io integration to create a branded short link for each user for each of the deeplinks. I have found short.io to be the best platform for this because it allows for open graph, and persistent URLs, even when navigating.
The only tricky thing you’ll need to solve for is preventing users from navigating up a level from the details screen (unless you don’t mind them navigating back to the landing page for another experience in your app). You can do this with some css to hide back buttons etc. Not fool proof, but possible. I have an example of this that I can provide when I get back to my desk.
@Robert_Petitto , Thank you! I have to admit I was busy writing a response restating my question when I realized that I just needed to sit with your answer and watch your deep link video again (which had helped with another issue) and realized you had given me the solution! Glad I didn’t hit send.
I did have to create a helper table of sorts with each client listed in column1. That gives me a row to deep link to that is specific to each client. A query in that helper table to the favorites table, filtered by the client in that row and…viola!, the detail screen for the row becomes my “page” for each client with the query as the target table. This is great.
Thanks again Bob. I’m less worried about them navigating to a different screen. I’ll have one generic page at the front that is visible to non logged in users only. But I would still welcome the example for possible future uses.