How to get response from a non Glide user in my App

I have a design question.

I want a user (Glide user/customer) to select from a list of names and then forward this list (typically a subset of a table) to a non-Glide user as a webpage. The non-Glide user then selects from the list and sends/submits their response back to the Glide user.

The list from the Glide user times out (not accessible) after 7 days (in case the non-Glide user is non responsive) or after it has been submitted back. In either case the response time will be tracked and the list is not accessible after time-out/reply.

The App allows Glide user to work with non-users in selecting tasks to work on.

Am drawing a blank on how to achieve this within a Glide framework.

All ideas welcome.

The non-user’s ID will be their email/phone number. Other security ideas (like a PIN) would be great so it takes more than just their email/phone to access the page.

You could set a one time pin using visibility.

[Try this:]
(Untitled: Mar 26, 2024 2:41 PM.webm - Google Drive)

I think this is what you were looking for. If you want you can try it at

https://collins-app-g45u.glide.page/

Just want to note that creating your own authentication or pin system is not data secure. It’s reasonably easy to snoop data to see what the pin is, as well the underlying data is meant to protect. Since the request is for something that would be accessible to non-signed in users, I guess it’s a moot point regarding data security, but just want to emphasize that data would not be secure in a case like this. If security is not critical, then it’s a fine alternative.

1 Like

Yes. You could also lock it with row IDs

Row Owners would protect data…not Row ID’s, but that would require users to sign in.

1 Like

The goal is to share a subset of data in a secure manner for a non Glide User (nGU) to provide feedback to the Glide User via a temporary shared list.

I was considering creating a second App (aside from the main App which the Glide User uses to create lists) which would have a shared table (which includes the list of data the nGU would select from).

To protect the data, which I would want to do, I would create a user account for the nGU of the main App that expires in one week or until the submit button is pushed which then deletes the ‘temporary user’ from the User account. I would have row-owners for the Glide User and the nGU in this shared table so either could access/see the data.

Is this the reasonable way to protect the underlying data from prying eyes?

Other ideas/thoughts that fit in the Glide model/framework?

I think it would have to be a Private app with a whitelist to work. If you are creating accounts for the user, would you use their email or a dummy email? If it’s a dummy email you would have to share the magic link, otherwise a pin would still be required to sign in. Other than that, it sounds possible.

  1. I could create actual users with actual/dummy emails. They would be temporary Glide users for the purpose of this one workflow (selecting an item)
  2. Yes I though this would be a very lightweight private app
  3. I could use a dummy email with a magic link (and map the dummy email to the correct person/name) - but can that be automated? @Darren_Murphy

Thanks for ideas.

Yeah, I’m not aware of a way to automate the distribution of magic links. Would be cool though.

If I used email accounts and created temporary Users in the user table and a link to the page with the list (basically their home screen) - Glide would authenticate them by requiring a PIN to access the link.

Correct…

PS. How often does Glide check if I ADD/SUBTRACT Users from the User table. Any ideas?

If you used real email addresses for the users, then they could sign in using a pin, and I’m sure you could automate the shareing of the app url for them to sign in, but I still don’t think you can automatically share the magic link. You can include it in the email they receive with the pin after they try to sign in, but that’s about it.

Glide doesn’t care if you add or remove users from the user table. What they count is how many unique users sign into the app per month.

1 Like