Alternatives to Email Pin?

I’m a little curious about this.
Normally, once a user is signed in the authentication cookie will keep them signed in indefinitely.
So in theory, they should only have to go through the sign in process once.
If users had to go through that process every time they open the app, I could understand the frustration - but that shouldn’t be the case?

1 Like

Can you tell us more about what they find frustrating and what alternative you would prefer?

1 Like

Thank you for the responses, @david, @Darren_Murphy, @Eric_Penn!

My users hop around from workstation to workstation frequently. They work at a hospital, and they may only have a few minutes before they need to get up and do something else. So, they are frustrated that every time they sit down at a new workstation, they need to spend a couple of minutes in the email verification process. The mobile version certainly helps, but it’s not optimal for some of their use cases (reading an article, printing a policy).

Alternatives that I think would help would be:

  1. Username and password login
  2. SMS Verification
  3. The ability to link up to another system for login - such as Duo Mobile or other two-factor authentication services

In an ideal world, my users would most want a SSO solution, but that might be a reach for now

2 Likes

Currently, I am looking into duplicating the app and making a version that is public with email and only accessible on a range of IP addresses (aka, hospital computers). This is a lot of work and not really ideal.

One other solution that could really work for me would be to allow users to assign two email addresses to one account. I need to use institutional emails for the whitelist, but if users could add a secondary gmail address, they could use the login with Google option for faster access.

One possibility could be to whitelist a domain. Not necessarily a solution to your problem but its something.

I don’t think that helps me, because I do need to limit access to certain people. Thanks for your thoughts, though!

If there is a possibility of using two email accounts for one user of which one should be Gmail, why don’t you use it now? Google Sign in is great and fast option. Why do you need email adresses from hospital domain?
Maybe I didn’t get it, sorry… Just trying to understand the logic.

This is a great question. I grant access to this app by having their institutional emails on the white list. I do not know who has a gmail account, and if they do, what they are. I would be open to letting people change their email address to gmail, but that messes up a lot of logic throughout the app that matches email for visibility conditions.

It could be done, it would just take a ton of time that I don’t really have.

1 Like

Yes, I do understand now. It depends on how many users you are expecting. Since you have a whitelist, I assume that you have an exact number. If it is not too many, it can be done quite fast I believe.

If you let your users change their email addresses, I think that it should not mess up your logic unless you hardcode some of them inside components or computation columns.
Or, I’m wrong?

There are several areas of the app that are individualized based on “email is signed-in-user”. As in, the email address of the person who posted this is the signed-in user. If the user changes their email after posting, these won’t match. So, that kind of thing would be an issue in a lot of features.

Yes, you’re right. My bad.
Maybe, after their initial sign-in, prompt them to immediate email update(change)?

yeah, that can work for new users moving forward, but the users that are frustrated with me right now are existing ones with data already saved to their accounts

Ok…Obviously, I can’t help, sorry.
Just one more thing… Usually, the user stays signed in unless he or she manually sign out, or their phone turns off or they kill all active apps occasionally. I’ve never had some issues with users because of the log-in process. That is the main reason I engaged in this discussion. Sorry one more time for wasting your time for nothing.

If you don’t need to apply row owners to your data (for data security), you could consider adding a unique id to your whitelist sheet. If a user adds a secondary email, you could automatically carry over that same unique id to that second record. Otherwise you would assign a new unique id for a new user. If your user profile sheet is a different sheet, then you can pull in that unique id with an email relation/lookup to pull the unique id into the user profile. Both user emails should get the same unique id. Once that’s set up, then you can create a relation/lookup to pull that same unique id into all of your other data tables. Finally, you can change all of your visibility, filter, and If conditions to compare the lookup unique id to the user profile unique id.

That way a user can have multiple accounts, but access there own data from multiple accounts. Again, this is assuming that you are not using row owners. Also, this should have minimal impact, so it really shouldn’t affect users if they are currently using the app. The only hard part is manually assigning unique IDs to existing user records in your whitelist.

6 Likes

Turns out hospital administration has banned access to Gmail, so this won’t work. Best options would still be SMS Verification, Username/Password, or other customizable methods

I voted for this one. The one you posted seems redundant.

1 Like

Good to know ty. I voted here now instead.

I’ve been trying to think of alternative ways of protecting some data while reducing the burden on users. Is there any plan to change this :point_down:?

Using if/then columns, template columns, and relations, I could check a currently logged-in user against an email whitelist and also check for a password match. If those things are verified, the current user becomes a row owner for all relevant data.

This would be huge for me and I imagine others. Would also make it more functional to have gated access to content - some parts are public to all (such as selling points of app, greeting), but you have to be an authorized user who is signed-in to access the rest.

Computed columns are computed on a user’s device after all data is downloaded. Those computations do not happen on the server. At that point attempting to apply row owners to a computed column would be pointless because data security would have already been compromised by pushing all data to a user device instead of only the user’s owned rows. At that point it would be no different than using a filter.

2 Likes