Forum Academy Marketplace Showcase Pricing Features

Users email as Primary Field

Hi there,

I’ve been building my app, and when I wanted to make a data type “Employee” with a relation to the Users database, and link it using ‘email’ as a primary field, it appears it doesn’t want to save the email of the User type.

When I change it to a custom field “UserID” (text) and set the Primary Field for Users to UserID, it does make that connection.

Funny thing though. When I set the Primary Field to UserID, link the “Employee” to a “User”, and then switch the primary field to Email, it does list the email in App Data view, but when I edit the record it cleans out the field.

I would love to be able to use the Users data type along with my Employee’s records so I don’t have to store their email twice, since they will be logging into this app using their email anyway.

Here’s a screenshot showing that it’s not working as I expect it to. If login details are required, please let me know so I can provide everything you need to determine if this is a bug, or just me being plain silly and overlooking something.


Do you have a thing of type User on your Employee object?

Also, why cant Employees be just a type of User? Why does it need to be its own type?

All my users sit in the User type and I have one field called ‘Role’ with static values to determine the access level based on that role and the rest I do with User fields on other types.

So for example:

I have a Location type. One thing in the type is ‘Client’ which is a thing of Users. Another could be Manager. But all the data connected to the User is stored in Users. Im not sure if you can save a primary field from Users (email) in another Type and expect it to save in the User type. I think it should work the other way around so when you have fields you dont want in the User type but still want to reference, you store them in another type with a field with User relationship back to the User type.

Not sure if this makes any sense or if its even addressing your question, but this setup works for me. :slight_smile:

@Lenex Bubble is developed using the email as the primary authentication field for the Users. So in order to update the email you can’t just provide access as you would any other field you create in your forms. You have to use the Update the User’s Credentials functionality available through the API. That means you also can’t change it in the data view either. (Also, you can’t change the unique ID.)

Here’s a pic of how it’s done for my app:

I’d really consider doing what @vincent56 suggests, placing this information in the User’s table and letting Employees just be a type of User. Then simply having a Type field as one of the types for the User. This will really help you out as time goes on and your app grows.

Here’s my User table:

Thank you both for your replies.

Yes, I do have a thing of type User on my Employee Object. And that’s what I am trying to reference.

The reason I am having a seperate Employee type is because I am going to have 2 different type of users. End-Customers and Employees. Employees will log into the backend, while End-Customers will log into some sort of client portal. I guess what you are saying makes sense, but would that be possible with these two type of users?

I guess I’d have to make 2 yes/no fields: isCustomer and isEmployee?

Or would making 1 text field with “UserType” suffice? As long as my “Search for Data” searches are constraint to that type, I guess I’d be able to show the right Users.

One more question; Would it be an issue if I had users that’d never log into the app, but are there purely to make notes on? Like in a CRM?


We should really have the meetup soon :wink:

Im building just that, a client portal and an admin backend…

For your last question, for that I would create a different type. Something like CRM. With fields like name, email, phone etc. Since they wont be using the app (registering, logging in etc) i would treat that just like any other data. Unless you want to create actual Users out of them.

But you can build that in already by defining user types in the User object…

1 Like

Hi, @Lenex. If I understand you correctly, the answer is yes; this will work. And it’s similar to what I’m doing. I’ve three different types of users in my app, and two of those user types also allow access through an API. For each of those user types I’ve set pages (with headers, menus, and content) appropriate for each.

In my Users table, the user_type column sets the initial role and after login redirects the user to those pages appropriate. My security settings for each user type ensure that only the correct users can access the correct pages.

I don’t think the greater issue is how they log in, but rather what content they access once logged in. So in your case, you could either set a user type like I do, or as you’ve suggested. Honestly, either would work for searching. I prefer the user_type option as it makes things just a little easier for how I search.

For your last question, you can also setup a “View Only” role, too. They could either have separate pages or you could just restrict certain parts of your screens. Again, this comes down to your preferences and use cases.

Hope that helps.

Cheers Saeed, I’ve been trying to throw all data into the Users table. The only thing I am worried about is when one of the employees will want to change the email address of a customer. Because I can’t just manipulate the email field. I’ll have to use the workflow related to accounts to be able to change the email address.

Am I correct when I think I’m going to have to set a temporary password for the end customer, then use that same temp password to update the users credentials, and then send a new email to allow the customer to reset the password?


Hi @Lenex. I’d probably summarize Bubble’s logic as always placing the ability to change password in the hands of the user who owns it. Given that thought, what I’ve done is to use the “Accounts > Send Password Reset Email” workflow. See the (incredibly long) workflow below. This then sends an email with a password reset link for the user to then generate a password.

Workflow using Password Reset:

Email response: