The notion behind the above post has been to “hide” a UID as white text, in a white background HTML email. Story isn’t over yet, but if we cut a long story short - That notion is (/seems to be) not possible with Glide.
So on we go to plan B:
Let’s add a UID to the email subject. The obvious risk here is that users can change/remove it from the subject. Well, that’s the best of all bad options…
To make it more “eyes friendly”, I thought about using a six-digit alphanumeric code. The Glide unique value is too long to add to the subject line. It will simply look awful.
I thought about generating with JS, as below:
var characters = 'abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ';
var result = ""
var charactersLength = characters.length;
for ( var i = 0; i < 6 ; i++ ) {
result += characters.charAt(Math.floor(Math.random() * charactersLength));
}
return result
To make sure we don’t use the same UID twice, I thought I’ll write these values to a Glide Table. However, this table will very quickly grow massively. This will not only break the (unbelievable) row limit on Glide, it will also become super slow even if it was on a simple Google Sheet. Thought?
Wow, that was a long intro for a simple question: Why not?
Why not implement this way?
Can someone tell me why is this a bad idea? What are the downsides?
As mentioned in the previous post, more than happy to hear your wonderful ideas on how to easily track emails.
The problem I have with random numbers, is that lighting can strike twice and there is always the possibility that the same number can pop up twice or more. For example, six sided die is random, but you have a maximum of 6 rolls before you start getting repeated numbers.
Even if you could track each and every number, you would still have to build logic to re-randomize the number if a match was found. But like you said, that becomes a lot of overhead.
Another option is to sequentially number a global value…but the way the glide model is designed, you will still have potential duplicates. Each glide app works in a disconnected state that periodically syncs it’s local database to the main server database. If several users are updating a “global” variable, it’s happening on their local device. That increment ultimately becomes a ‘last one wins’ situation so until all data is synchronized between all users and the server, there could potentially be some discrepancies.
GUID and UUID values are inherently designed to always be unique no matter the source. They use several seed values (probably including machine ID, time, and probably other things) to generate an ID that’s almost guaranteed to be unique no matter what. The chances of a duplicate occuring are astronomically high and next to impossible. RowID’s are probably similar, but to a lesser degree. I don’t know exactly how rowID’s are formulated, but I’m sure it’s unique within your personal glide world at least.
Honestly, I would still go with a RowID or UID simply for the easiness and guaranteed uniqueness. In my app, I have a list of students. At the very bottom of each student detail screen, I actually show the RowID visibly shown. The user’s don’t even notice it as they have to scroll a bit to see it. I have it there so if I’m ever looking at other tables in the database, I can easily cross reference that the RowID belongs to a certain student since I only write and create relations using row ID’s. I guess what I’m getting at is that I would embrace it as a visible value to help with tracking. Even indicate that it’s a tracking value and not to delete it. Visible or invisible, it’s always possible that a user could completely wipe out the body of a message.
Thanks. That’s a lot of food for thought.
Another idea I am playing around is the email address, same as it’s done with Zendesk and others.
Glide <support+id123456@glide-help.zendesk.com>
I haven’t played with sub-domains on Google Workspace, but I’m sure it’s possible. Once a sub-domain is set up, we will simply have one catchall address that’ll read the number on the left side of the @. This number, as you suggest, will be a combination of sequential and userID. Never say never, but odds are quite low we’ll have duplicates this way.
What do you think?
Edit:
Here’s a great step-by-step for this sub-domain catch-all
Yeah, I think using the email address for tracking would be a much safer bet. It’s less likely to be altered by the sender or recipient. Gmail is really good at allowing any + extensions to an existing email while still going to the primary inbox, where it can be further categorized and organized. Not sure about other providers, but Google workspaces might work for this. Maybe don’t even need to go as far as a subdomain. The primary domain may suffice with just the + extension to the left of the @.
And yes, I agree that using a user ID in combination with a sequential number should be pretty safe.
It’s not easy being a complete novice on this coding/low-coding world, but it becomes much easier with friends such as you
I had no idea we can do that. Here a link for anyone else who comes here later
This allows us to generate a mailhook on Make that will sort through all incoming emails to the domain, for all users. This would generate a huge number of operations.
Perhaps more efficient to forward ALL emails (using content compliance / filter) and then have Make watch for new emails on this address. this would be more efficient operations-wise, but it’s not ideal from the Google Workspace direction.
