A common best-practice in web apps is to confirm user email address when they sign up.
This is beneficial because it helps prevent spam, enhances security and improves the integrity of your data.
Here’s how to setup your Knack app to confirm email address on sign-up, all using Knack-native features (no custom-code required)
Great video @Callum.Boase - some really good tips and tricks clearly explained. A great feature all achieved with native Knackness 
I’ve used the zero record table solution many times, I also hide the table with the below code. As you know I’m not a coder, I picked this snippet up years ago. It hides any tables on a scene where there are zero records. That way, even if the user walks back through the URL and finds the table with zero records it will just show a blank page.
I have to admit, I didn’t know you could remove the parent part of the URL and link directly to the child page (with the relevant RECORD ID) thereby removing the breadcrumb navigation.
Everyday is a school day. 
I’ve always coded them out with CSS 
That’s one of the many things I love about Knack and our community, even after years of building I’m always learning something new.
Thank you so much for taking the time to produce the video content and freely share your amazing knowledge. 
/* Change the scene_1 to the scene key of your choice, or replace with any to work on all pages. */
$(document).on('knack-scene-render.scene_1', function(event, scene) {
// Loop through each scene view, on the page.
scene.views.map(function(view) {
// If view has row data and that data is less than 1...
if(Knack.models[view.key] && Knack.models[view.key].data && Knack.models[view.key].data.length < 1) {
// Remove the specific view.
$('#' + view.key).remove();
}
});
});
Nice one, @Callum.Boase!
This is pretty cool. I am having an issue. When I try to confirm the email. the form does not submit. It appears to be changing the last character of the record ID so that it is not associated with the proper record. Any thoughts would be helpful.
Thanks Carl!
Yes I often hide the table with something like that CSS too.
For those reading back here later, it’s important to note that hiding the parent page with CSS does NOT stop users accessing the data shown, it simply hides the data.
But adding setting the parent page grid view to use 0 records is actually securing your data properly because users cannot access it even if they used the API or circumvented your CSS.
So the 0-record filter on the parent page grid view is essential for security, but the CSS to hide the contents of the parent page is just a nice touch
Hi Peter,
Sorry to hear you’re having trouble.
Can you send through some screenshots and/or a short video showing your current configuration & the issue you’re seeing? Happy to try and help
Hi Callum -
I implemented your email confirm setup, was working great, now I too am having the last character of the record ID changed. Were you able to resolve this issue with Peter’s setup?
Thanks in advance!
@Royce @Peter7
Jumping in briefly about the record IDs.
It’s common for the Account record and its Role record(s) to be identical except for the last character. For example, if the Account has a record ID of 12345f, the Role might have a record ID of 12345g.
This would appear as if the record ID has changed, but more likely it’s two records associated with the user… their Account record and Role (e.g. “Customer”) record.
One suggestion is to check the form that creates the user. Is it creating a record under the role table i.e. is it a form that creates a Customer? Or is it creating a record under the Account table i.e. a form that creates an Account?
Database-generated record IDs don’t usually change, as far as I know.
That is all. Carry on. 
Okay, that makes sense! I’m modifying a role, but through accounts. I had thought since I have multiple roles confirming them through accounts would cover them all….
I’ll drop those fields to the roles tables and see how it goes, thank you!
Waiting for Callum to jump back in, but I think confirming the Account is the best practice. Without knowing the details of your use-case, I’m hesitant to make a recommendation. I just wanted to point out that the record IDs are likely not changing. Hope you find a setup that works for you. 
As @KnackPros said, the issue does seem to be what record you are trying to confirm (the account or a role).
I would definitely recommend trying to configure things so that the confirmation happens using the parent account record rather than the child role record, because I usually recommend avoiding adding any fields to child roles (see details here https://youtu.be/ckSSZp4vdoI) and my hunch is that doing it on the account will be neater and tidier (eg avoiding building the confirmation process for each role, and avoiding potential conflicts between multiple processes).
Can you clarify a bit more about your setup and where you are ending up editing a role record instead of the account record (screenshots or details of how it’s set up so far). This will help me suggest a solution
@KnackPros @Peter7 @Callum.Boase
I checked the db, @KnackPros was indeed correct, the Accounts db and the roles db reflect a different record id that is one character off, tha seems to be the issue. I’ll redo the confirm email process to reflect the roles db and not the accounts db. What’s odd to me is this worked up front then suddenly stopped functioning. I’ll chalk it up to operator headspace for the moment and see how it goes in the AM! I’ll keep the thread posted, and thank you all for your feedback and assistance!
Good day everyone -
First, thanks for your input. I followed @Callum.Boase configuration vid, well done I must say! Here’s what I’m seeing. The public page used to edit the user record first pointed to the accounts table, which is where the date confirmed field resides. The result, however is the link sent to the user to confirm their email address reflects the record id associated with the agents table and not that of their record from the accounts table, therefore the link is broken and nothing occurs.
If the confirmation form points to the agents roles table (adding the date confirmed field and dropping the user status field below the date confirmed field ), clicking the “confirm your email” button results in showing the “you’ve been confirmed” response, but the date confirmed field and the user status are not changed in the table.
I also tried setting up the public page edit record form to edit the agents table but leaving the date confirmed field in the accounts table. This also did not result in updating the record of the user to active status with a confirm date.
My final attempt resulted in success! I reset the tables back to the configuration @Callum.Boase uses, then created a one-to-one connection between the roles table and the accounts table. On the public page edit record I created two rules, one to update the user status within the agents table and a second to update the date confirmed and user status fields in the accounts table. This works. Not sure if this is the cleanest, but it works, so I’m happy with the result! If there’s a cleaner way I’m open, and for the moment, thanks for all your help!