HI,
im doing a mobile app for a client, however, they have around 2000 employees that does not have a company email. although they get added to the company active directory, they really only have an employee code and mobile number.
How do i work around this?
thanks
Ilse
That’s tricky.
I think the only thing I could suggest (assuming that sign-in will be required) would be to have the employees use their personal email addresses to access the App.
I did that for a private app for company with about 600 employees, where only about 50 of them had company email accounts. It’s not ideal, but it works.
thanks for the feedback @Darren_Murphy. my concern is, with the nature of these employees i dont even think they have personal email addresses - as they earn very low income and their basic means of comms is whatsapp and sms.
is there not a way one could do a public app (or does that also require an email to signup?)
re
Ilse
Thinking out load.
What is the employees had an employee number - and can remember it.
Then they used gmail account to log in so email would be like+<employee_number>@gmail.com
All mails are going to the same gmail account
The email is grabbed by Make/integromat and the code in the mail is sent to the users phone. There must be a translation table in Make to relate employee_number, email, phone number to things work
An email account that caches all emails could be used as well I suppose
Would that work ?
You can do a public app if everybody is allowed in and you don’t need to store any info of the user
I get that. Although, I had the same situation. Many of the users in my scenario also didn’t have email addresses. But, personal Gmail accounts are free, so we just told them all to get one. It’s amazing how quickly they were motivated to do that when they found out that’s the only way they would be able to retrieve their monthly payslip 
Yes, you could make the app public. But public means public - anyone that had the URL could access it. And as Roldy pointed out, if users are not signing in, then there is no way to associate data with specific users. So whether or not that would be a viable option will depend on the purpose of the app. If it’s read-only like an employee directory or something, then maybe that would be okay.
What is the idea of your app?
I made a timesheet and task app for employees without email using User Specific Columns. Although it isn’t secure, but it serves the purpose.
Employees entered a unique code to the app which is assigned to them, and when they do it, it relates their information from the employee sheet which contained their data including that unique code. Then they can see their tasks, and enter their check in/check out time.
This was a small scale app with less than 100 employees. I wouldn’t suggest you this for a company with over 2000 employees.
@Darren_Murphy i agree, i will suggest the same approach to my client re using personal email with gmail being free - its a wellness appointment booking app so it makes sense.
i have been doing alot of research on the costing model, please can you advise if my understanding is correct:
thanks
Ilse
I’m afraid your understanding is a little bit off 
Refer to the Pricing Page at Flexible Pricing Plans That Scale With Your Business | Glide
A Starter Plan only gets you a maximum of 10 Private Users per month, so that definitely won’t do.
If you’re expecting private 100 users per month, then you’re at the upper limit of the Business Plan. And once you go over that, then you’re looking at an Enterprise subscription.
I guess the question is does it absolutely need to be Private?
If you need to restrict who can log in, then yes it does and the above applies.
Thanks Darren, i have been struggling to understand the implications between private vs public. my client wouldnt want any random person to open the app and book an appointment - but im thinking perhaps we load the agents as public users but they can only see the option to book if they have input their employee code - what do you think?
that way, private users will be the admin & appointment approvers who will need to signin with company email. and the agents (1000 of them) will be public.
thanks
Ilse
That could be an option, but you need to understand that would not be completely secure.
In order to validate the codes, the entire database of employee codes would be downloaded to each users device. So a user with nefarious intentions could conceivably discover the employee code of every agent.
A better option might be to make it public, but apply row owners to your user profiles. Then include the employee code as a column in your user profile table. It would be secure, as each user would only get their own user profile row, which may or may not contain an employee code. Then you could configure it so that the booking form is only available if an employee code is present.
With this approach you may wind up with extra users in your user profiles table that you don’t want, but if the URL isn’t widely advertised that may not be too much of a problem. And you could always periodically clear them out.
