Build your own CRM with Bubble.io NoCode - Part 1

Headshot of Matt the Planet No Code Bubble Coach

Need 1 to 1 help?

Your no-code consultant & Bubble tutor.

In this no-code development video we begin tutorial series demonstrating how you can build your own custom CRM with Bubble.io - all without writing a single line of code. Bubble.io is a powerful nocode web app creation platform. Watch to discover how to create a Registration and Login page for your SaaS app users.

Introduction


This Bubble tutorial video is the first in a series of how to create a no code CRM built with Bubble.io. We're going to be breaking it into a number of different blocks.

Building a Login/Registration Workflow


This first episode of this mini series is going to be about building a login/registration
or everything in our database is where it should be, and it's all nice and secure.

Exploring Bubble Tutorial Videos


But before I launch into it, did you know that we have got over 160 Bubble tutorial videos available on our website? Some of them you can only find there. You can search YouTube as much as you'd like, but they are for our members, and you can find out more about becoming a member at pm68rf4jt3-staging.onrocket.site.

Getting Started with Bubble


Here we have a blank canvas in Bubble, though. I've added nothing to this app. I've simply created the new app, and I'm going to start, like I said, with registration and logging. So my page here, I'm going to set the
to align to parent. I'm going to give the background a grey color and I'm going to add in a group. And I'm going to be doing a rough but all right looking UI build as I go along. And then maybe later on, I'll include the whole video about just improvements that we can make to the UI. So it's not going to be perfect, but I'm not going to try and make it look rubbish either.

Creating the Login and Registration Forms


So we are going to give this a
and put some padding in there. And this is going to be one of the boxes for one of our forms for login and registration. And I'm building it on index because I'm going to set my app up so that when people come visit the domain name that I attached to this Bubble app, they will be taken to login or register. And then actually the actual dashboard for the CRM is going to be a different page. And that's going to help me add in workflows if the user is logged out. So end them to index. If they are logged in, send them to dashboard, that thing.

Adding Form Elements


So let's add in some text. And I use the H2 here, I'll say login. Actually, I'll do first. And then I'm going to add in some text. And I'll call this one... This is going to be my label for my form items. From an accessibility point of view, it is not best practice to simply rely on placeholders because they don't always interact well with screen reader software. So I'm going to add in a label and
. These tend to look good at around 55 or 52. I'm also going to make that 100 % width. And I'm going to group these together. You'll see why in five seconds, because then I can use the space between. And so I can add in a gap for, tends to look quite good. And then I'm going to duplicate this, right clicking on the group, pasting in the parent of the group.

Setting Up the Workflow


And so this is going to be password. And now I'm going to select both groups. We can see, basically, I've selected these two here, and I'm going to put these into a group. And this is going to enable me to put a nice uniform gap in between each of the form elements. And so group elements in
.

Adding a Button and Workflow


And then email, we'll put enter your email mail. And I'm going to change the content format to email. This means that Bubble will reject and show an error if someone doesn't enter an actual email address. And we'll say enter email enter a password and make sure that this content type is password. Cool. Lastly, I think we need a button. So I'm going to add a button into my form and now say register. Okay. Yeah, it's not amazing UI design, but it's also not can't untie the either. In fact, I'll add a little border radius to here. Cool. Right, let's set this up with a workflow.

Setting Up the Registration Workflow


So when the user clicks Register, we add a workflow here. Our action is going to be account, sign the user up. And then this is where it's helpful that by replacing the placeholder text with our own, if I type an email, I then get Bubbles automatically renamed the email input to be enter your email. So it helps me match up and we'll go password and change another field because we're also taking first name. And so I'm going to create a new field and say first name and make this of type text.

Creating the User Data Type


And so I've created the field of on the user data type. Let's have a quick look at that. So in data, I've only got one data type so far. Because it's a CRM, I'm at least going to create contacts at some point. But right now, I just have user. And user is a special data type because the user data type is the only data type that you can put the register user and the sign up user workflows. And anything to do with user authentication that is linked to
, you have to do that through user. And the mistake that I see quite few people making is that they think, Oh, my app's got multiple users. Maybe I've got admins, and then I've got team leaders, or I've got buyers or sellers, the thing you get in a marketplace. And so they attempt to create a buyer user type and a seller user type. And with creating a new data type. Now, that could be used if you indeed link them all back in to a user type, but you can't give a seller... If you create a new seller type here, you can't give that seller the ability to log in and register.

Connecting Form Inputs to User Fields


You can only give that to users. And all I was trying to point out here before I went off on a bit of a tangent with that is that the first name field, you can see it's been added in to the user type, and we created that back on the workflow screen.

Redirecting to the Dashboard


Let's link this up to input your first name. And then when the user signs up, what do we want to do? I think we should send them to another page. So I'll create a new page here. I'll call it dashboard. My spelling is all over the place today. I'll just click Create, and it's going to be blank. And we're going to pick that up in another tutorial. So we're on the dashboard page. I'm going to go back to Index and finish this off by giving a go to step in our workflow and the destination is dashboard. Quick word on go to steps. If you add in go to steps without conditions, then Bubble knows that if you're going send the user to another page, it has to come at the end of a workflow. Otherwise, you're going to get an issue showing up in the top here. You can use conditions to say if the user is this user type, send them here. If they're that user type, send them elsewhere. In that case, you can stack go to workflow actions in the same workflow.

Creating the Login Form


So this is going to sign our user up and send them to dashboard. I'm going to copy and paste this. And because I have my layout set to aligned parent, the new one I've created is actually on top. So I have two identical ones, but they're sitting on top of each other because they're both set to center in the parent container type. So I'm going to name this one Register so that I can see more clearly in my element tree. And I'm going to name this one Login.

Switching between Login and Register


Now, I keep renaming elements to the minimum. I know some people, they build a Bubble and they really want to have an ordered elementary here. And so they rename everything as they create it. I tend to only rename if I think it's going to be genuinely useful to me when I'm looking for an element in the elementary. So for example, these groups contain quite a few elements now. Lots of nested groups, text labels, inputs. And it just helped me be able to tell the difference, especially as they are both visible on the screen at the same time. But I'm not in the habit of renaming every single group or renaming every input, especially inputs, because then if you change the input placeholder and you've renamed the input element, Bubble won't automatically update it in that case. And you can just end up with lots of duplicates that you can't tell which one's which.

Improving User Experience with Show/Hide Actions


But anyway, let me hide by clicking the i button here, the register one. So now I'm definitely looking at login. So I'm going to change this to login, my header here, and I'm going to get rid of the name field. And then email address and password are the same. And so I change this to
. And so this one is going to be log the user in. And I matched up the email address. Now I do have multiple fields called, enter your email address twice. So what I should shall do is I'll just change this one to your email. Otherwise, you could relabel it and I'll change this one to your password.

Implementing URL Parameters


So this is your email and then your password. And I'm going to do the same thing, which is go to page and set it to dashboard. Let's preview and just see what's going on. Okay, so I get some rather ugly UI because they're both sitting on top of each other.

Showing and Hiding Forms Based on URL Parameters


So I now need to set up a way to only show one or the other. And I would suggest in terms of user experience that you get a little bit more complicated here than what I'm about to show you, because you might well want to send your users to the same screen, whether they're registering or logging in, but you could use URL parameters to dictate which one is shown. And that can be useful because if you've built your landing page for your Bubble up outside the Bubble, say Webflow or Framer or
, you might want to have a login and a register button that are separate, and you can use the URL parameter to determine which one is shown. But in this instance, I think I'm going to have users showing the login because I want the better experience for my experience existing users.

Implementing URL Parameter Logic


So register, I'm going to say,
on the page.

Using Custom States to Toggle Forms


And then custom state is a word temporarily storing data. Oh, no, actually, I won't use the custom state. I'm going to use the URL parameter. So in fact, I'm going to have both both of these hidden and I'm going to add a condition. No, in fact, I'll have it visible and I'll add a condition to register. And so I'm going to say get data from URL parameter, and I'll say show register. And I'll say is yes. And I'll add it, and then say element is visible. So this is a way of carrying data between even different websites is you can put data in the URL. I'm going to show you how in the moment. But I need to create a mirror image of this on login. So I could do this and then on ticket, but actually, what if I was to change this parameter, the when statement here, I then need to update it into location. So instead, I'm simply going to say when the register is visible, hide login.

Testing the Login/Registration Functionality


Let's preview that. So we see login by default, and the debugger mode here is an example of a URL parameter. It's saying debug mode equals true.

So this is a smart way to approach it because it means that if I send users to this web address, I know that they're going to get logged in. If I send users to this web address, I know that they're going to get registered. I also know that if for some reason they have clicked the wrong button, they can easily toggle between the two themselves.

Conclusion and Future Topics


That's the end of part one. Let me have a look at my notes. Part two is going to be actually building out a dashboard. And then in the following parts of this mini series, we will be covering topics such as creating contact data types, how to add and edit entries in your