I’m trying to avoid duplicate usernames during the onboarding process of my app. I got great inspiration from previous help topics like this one.
I’ve tried multiple different solutions, but the conditional logic seems to be evaluating incorrectly.
The baseline situation:
I have a users table with fields for: row ID, name, username, email, name entry (user specific), username entry (user specific), lookup of all existing usernames, joined list converting that lookup of existing usernames into a comma-separated list, relation between “username entry” and all existing usernames
My onboarding screen is collecting “Username Entry”
The CTA button is triggering a custom action on the Users table — this is where I’m trying to implement conditional logic to prevent duplicate usernames.
Solution 1 where the conditional logic seems broken:
I’ve tried creating a “Condition Case” where the data is only updated if the Relation column (relating Username Entry to the list of all usernames) is empty. If that relation column is empty, that should mean that the username is unique, and the logic can continue to write the data from “Username Entry” into the “Username” field.
If that relation column is not entry, that should mean the username is a duplicate, and the logic should branch to the other path that just shows an error message—the user would need to choose a different username.
However, somehow, with this logic in place, even though I can see that the relation column is not empty before I hit the CTA button, it is allowing duplicate usernames to be saved.
Solution 2 where the conditional logic seems broken:
This one is relatively similar. For this solution, the “Condition Case” where the data is updated only happens if “Username Entry” is not included in the comma-separated list of all usernames. If Username Entry isn’t in that list, that should mean that the username is unique, and the logic can continue to write the data from “Username Entry” into the “Username” field.
If the value of Username Entry is found in the list of all usernames, that should mean the username is a duplicate, and the logic should branch to the other path that just shows an error message—the user would need to choose a different username.
However, somehow, with this logic in place, it is allowing duplicate usernames to be saved.
If you trying to implement logic on userside i.e. app it self so didnt luck. Any logic will fail because it runs locally on multiple user sides. Only one solution for now is to move logic to external service which will proceed requests in serial order.
Previously make.com had only serial way, but now it can run multiply instances, so you need to to configure it correctly. I thinking
Also i don’t understanding how you collect data from multiple users thru user specific column, i think us fully isolated from other users
The problem here seems to be that you’re using row owners/roles and a user can’t see all of the rows, hence their input can not be matched to all rows. That allows duplicates to happen.
Also, I’m not sure why you’re setting the row owner on your Row ID column. Which one is your “role” column in user profiles settings?
Nevertheless, I think you must settle for a setup of a “row owners” table for your User Profiles, and a public table for your de-duplicating purpose. Everytime a user finishes onboarding or edit their profile, add/edit a row in the public table, and check for duplicates using that table (without applying row owners).
Fascinating—I guess I thought that the conditional logic was a “back end” function that wasn’t exposed to the front end or related to the permissions of users on the front end. The system “knows” there is a duplicate, but it won’t use the logic because the user doesn’t have access to the data.
I was using row owners because my thought is that members of a team should all be able to share data between each other (you can see the “Team” column is a row owner), but that other teams shouldn’t have access to a different team’s data.
But yeah, the answer is probably having a “Public User Data” table that includes things like username and makes them accessible to all users, since that’s not sensitive data in any way.
Ok, now if I want do de-duplicate users based on email address… how would I do that?
I was thinking Glide wouldn’t allow duplicate email addresses in the Users table, but it seems to be allowing them when one of my users invites a teammate. They can type an existing email address, then it lets them add a new row to the users table even if another user exists with that email address. I tried creating a Custom Form, but then I ran into the same de-duplication issue above.
I don’t want to include every user’s email address in the “Public Users” table, because that’s a privacy concern. But this means that if I have a Relation column checking for an existing email, it won’t find the email unless that person is already a member of that person’s team (because the row owner is maintaining the privacy of the non-team-members).
Can any user invite another user, or is it only certain people? Could you utilize Roles as row owners so certain users have access to all emails within a team or in the entire table?
Yeah, it gets a little difficult because computed columns, including relations and lookups are computed in the user’s device, and if the data isn’t their due to row owners, then your logic isn’t going to work.
If you can’t utilize Role functionality, then I suppose there is a convoluted way to do it without exposing email addresses. You would first need a column to set the email address to all lowercase letters to guarantee consistency between what is typed and what is compared. Then you need a SHA256 column to hash the email into an encrypted code. Then find some way to write that hash into a public table. In your custom form, when you enter an email address, you then lowercase and hash it, and then you can compare the hash value to what’s in the public table. The hard part would be figuring out all of the logic to get those hash values into the public table, but it’s doable.
The hash value is going to be the same regardless of where it is calculated. If there is a public table with only hash values in a basic column in that table, the. why would it still lead to doubles?
All users will have access to all rows in the public table, and the same email will lead to the same hash in the custom form. The hash from the custom form will be compared to all existing hashes in the public table. If a matching hash is found then it’s a double, but it doesn’t expose any email addresses.
There is no problem with hash. The problem is you have no actual data on user side so it possible to some users do the same action and both will generate same hash. It is fundamental: there no way to prevent doubles if calculation is on user side. Only way is if calculation on server side and proceed like atomic.
It is not me who must told it for Jeff_Hager of course, but it true
But you do…That’s why I keep mentioning a public table. It’s not the user table. It’s a public table accessible to everyone, that only contains the hash values.
This is true, but I highly doubt two separate people are inviting the same user at exactly the same time. If one person invites a user, the hash will be added to the public table. Five seconds later, a second person tries to invite the same user but now it will see the duplicate because the public table will have synced the new hash to all other devices in that amount of time.
If two people are inviting the exact same user at the exact same time, then there needs to be some better communication because they are probably standing right next to each other if that would happen.
You are correct about atomic operations and the limitations within Glide, but that applies more to things like sequential invoice numbering. Much less of an issue in a situation like this where it’s just comparing to pretty unique strings of text to see if they match.
Yes i agree with you, but only if after 5 seconds. If two person will do in at same time, or of have some connection broken so it really possible to have doubles.
I had thinking like you, but when my customers goes to report doubles i don’t believe any more to possibility. If something can happen it will be.
Do you realistically think two individual app users typing a specific email address to invite a single person into the app, at exactly the same time, would be a common issue? I just don’t see that realistically happening ever. I think the most common case would be one single individual app user having a conversation with a person and then offering to invite them into the app.
Just to be clear, I’m not disagreeing with you at all. I understand and completely agree with what you are saying. I just feel in this particular use case, the chance of allowing a duplicate is very rare. It would be the same issue if we didn’t have the separate table or the hashing, and @prossm was able to use only the user table.
I really think one person can start do in from smarphone, losee connection and go to do it from PC, then when connection on smarphone resored doubles appears. I have real experiance with customer with this.
Not with a custom form. The only way to touch data without a connection is with a native Add Form. You would be locked out of a custom form if the connection was bad, so they wouldn’t be able to submit the form in the first place. If the connection is restored and a row was already added to the table, it would be synced to the device and the form still couldn’t be submitted because it would now be a duplicate.
Actually for @prossm situation this is does not matter how many doubles presents in user table, actually glide will deal with first one. And you can easily deleting duplicates when new user have to login and clicking some button or collection.
