Explaining custom states


I’m new to Bubble so please bare with me - custom states are killing me off.

I’ve watched every video on custom states, I’ve read everything and I still cannot understand one thing.

I’m aware of what custom states do but I can do absolutely everything that people are doing with custom states, without custom states.

For example, hiding a group when a button is clicked and showing another group. I can do this without custom states.

I literally see zero use for custom states other than an apparent performance boost.

Custom states still need to use the work flows and they still often use conditioning so why do I need them? Somebody said it uses less work flows but it doesn’t.

Example below:

Custom State example:
Work flow when button 1 is clicked: SET STATE TO X > HIDE GROUP 1 > SHOW GROUP 2

Not using custom state example:
Work flow when button 1 is clicked: HIDE GROUP 1 > SHOW GROUP 2

It uses LESS workflow NOT using custom states.

Please can someone tell me what I’m missing because they’re absolutely useless to me. I’ve literally built everything these video tutorials are building with custom states, without them and they work just as well with less workflows. It just doesn’t make sense to me whatsoever.

Thanks in advance.

1 Like

You’re right, 9 times out of 10, you can get by with just vanilla workflow architecture and ignore custom states.

FOr me custom states have shown their value primarily when multiple things start getting involved in your logic. Examples:

-In a workflow, do A if a condition has occurred in another workflow that flipped a custom state. It’s hard to cross check workflow statuses without custom states, unluss you drop invisible groups on a page to hold values.

-Checking conditions on multiple items on a page simultaneously. For example let’s say you have a page that on-load evaluates what objects it should show or not show based on intensive DB queries. Then you want a workflow only to do an action when a specific set of those elements on the page are active. Re-querying the DB to check the conditionals would be murder when instead you could just construct a simple check on the element custom states.

1 Like

I think they’re absolutely fantastic. They let you store temporary information in the browser, which is several times faster than writing to and deleting from the data base.

For example. You can preload information in the browser, and only save it once the User does X.
This will be much faster than creating a temporary data entry that you delete if the User does not do X.

Or you could store a Yes/No state when the user has completed an action. Again, much faster than writing this data and deleting it afterwards. And perhaps not something you’d want to save to the database in the first place even.

Or why not save a whole list of things in the browser when User does X Y Z, and then throw it away, or write it to the data base depending on whether user completed another action or not.

The possibilities are endless. :slight_smile:

If you think of custom states as simply Yes/No hide or show a group with a conditional, you’re missing out on all the good stuff :slight_smile:

Another example. I recently set up a little thing where the user was mucking about selecting stuff in step 1. and while moving to Step 2, all the heavy lifting was done “in the background” and moved into states. Now all that “finished” data lives in states, and when the User hits “Save”, the data is pulled from the states, making it much faster and provides a much better user experience.

If the user decides to leave it, no harm, I don’t have to delete anything from the data base, it will just get binned once the browser is reloaded.

Edit 2.
Thought of another one, I was making a scrollable RG, scrolling the group with buttons. I did this with setting a custom state to add +1 to the repeating groups index for every time you click the button. and then scrolling to that index in the workflow.

Ok, I’ll leave it now haha. but don’t give up on custom states just yet :slight_smile:


Hi both,

Thanks for your message.

I don’t really understand what you both mean so maybe I’m not grasping what Custom States even do.

I’m really confused even reading your edit. Let’s say my site is Facebook, when a user clicks the button ‘Newsfeed’ it’ll bring up the news feed. Whether I used a state or not to do that, it still pulls the newsfeed from the database so what’s the difference?

Again if I had a form built with states, they mucked about on step 1 of the form, then step 2 pulled the rest of the form, I still don’t have to enter their data into my database until they click save. I can create a form that only sends the data to my database when they click Save, without custom states. If they leave, regardless of whether it’s in custom states or not, unless that Save button is hit, nothing goes anywhere.

What am I missing?

Perhaps you’re thinking of it as simply a way of showing hiding stuff with conditionals?

But there’s much more to it. In my example of mucking about in steps, The main reason is to load the data before the user saves it, to make it more of a seamless experience. It’s a bit of sleight of hand. If you do all the heavy lifting when the user clicks save, they might have to wait for the searches etc. But it’s already been done here, so when they hit save, they see an instant entry providing a seamless experience without the hick up of having to wait for the app to catch up, if that makes sense? It will of course all depend on the specific case, and is not a “always do this” thing. :slight_smile:

Another one :slight_smile: in a sign up, you could have one step where you say “hey tell us your name and what your favourite pasta” and store their name in a state, and in the next step you can say “Hi Ash please fill in your email and a password to sign up”…

But if your custom states save the data throughout then sends it to the database at the end, and my non-custom states wait until the end to save it and send at the same time, surely mine would be a faster experience as my non-custom states aren’t saving it as they go, yours is. Yours may be ever so slightly quicker at the end as you won’t need to save it, you could just send it straight to the database but mine would be quicker up until the save point.

In your edit, I could do that without custom states by waiting to the end and having a workflow that says “grab their name and favourite pasta from input 1”, “grab their email and password from input 2” and sign up. The only thing I can see custom states do is save it as they go, which is undoubtedly slower than if you didn’t save as you go, like non-custom states.

If 99% of users didn’t bother saving and just left the site pre-save, surely it would be a quicker seamless experience to not use custom states?

Edit: Ooo I misread your message, the 2nd step using that persons name from the first step is a pretty neat benefit to custom states! I’m slowly starting to see benefits.

So other than saving as you go, and @jesse.r.hunter’s checking conditions, is there any other benefits?

We’re getting there :slight_smile: You hit the nail on the head here “The only thing I can see custom states do is save it as they go” that 's exactly what they do, but bare in mind it doesn’t actually “save” the data. States can keep anything (ok, some things) in the browser, what you choose to do with it, is up to you.

And the key is, it’s much faster and more convenient to keep temporary data in the browser than writing it to a temporary Thing in your database. Sometimes that’s not even what you want to do, or can do.

I would say, play around with it, see what you can come up with. But try to not think of it as simply “JUST” saving as you go, or to be used for simple conditionals to show/hide elements. I’m sure you will start to come up with some pretty cool ideas :slight_smile:

For the saving at the end example, when you create a new Thing at the end, and you want the user to see a visual result right away, the user would have to wait for all the searches etc. to happen before the visual element is available, right?

Putting stuff into custom states means that it’s (almost) already available by the time the user hits Save. And the user will be none the wiser to the fact that it’s already been made available. If you don’t do anything crazy, the user won’t notice it happening if you keep them busy with other stuff.
But that’s just one scenario and won’t work all the time. but you wouldn’t be able to do it without keeping stuff in memory on the browser level.

Have a look at setting up the RG scroll for example, that’s a great use case for custom states that doesn’t show/hide elements or stores data to be saved to a Thing later on.

Edit. When it comes to showing/hiding elements, I do find that if I want to click the same element twice and have it flip between Yes/No, it’s much easier to do that with a custom state than setting an “Only do when…” condition on a “show/hide element” workflow. But that might be more of a personal preference.

1 Like

Custom States is just the way Bubble handles variables. It allows you to manipulate data and carry out operations without having to store it in a database. Bubble just has a weird way of having each custom associated with a page element.


Try this out. May help further understand the concept

1 Like

Custom state in terms of hide/show groups saving workflows can be shown if you have multiple groups you want to hide and show. If one group yes you might hide and show easily. However what’s done in browser doesn’t consider workflow.

You can use page parameter to navigate gives the user the feeling that he is going through multiple pages the fact he can use back at browser. And if he refresh the page link will remain at top so he is going to see the same views… in custom states he will go to default view or page. Custom states are hidden. Page parameter are shown in url.
I admire two plugins from BDK. Super Workflows… you can store 3 variables at once and RG extractor saving data from RG cells it is useful for ecommerce. Another custom states available for you

1 Like

Another use for custom states is to create a check/uncheck all feature for a list of checkboxes for searching. I also use them so that a checkbox that is searching a yes/no field returns all results if it’s unchecked (rather than just the no results).

1 Like

Thank you everybody - I’m slowly starting to grasp the concept behind it and I’ve been using it more frequently.

A few of the things you’ve all said has really helped. Thanks a lot.

@ashelderstone direct message me on Skype (Skype ID: CoreyChancelor), then you and I will have a brief call and I will explain it to you: both my 10 and 12 years build web apps in Bubble and they use Custom States ALL THE TIME. The title “Custom States” is a TERRIBLE title-- it is not intuitive AT ALL. Hit me up and I will explain it to you in a way so simple that my 10 and 12 year old use Custom States almost daily.


Hi there, l have a the general idea of what it’s about but l can’t find anything that explains it will enough, especially when the the custom state is set at page level. Would you mind l contact you also?
Cheers Mar

1 Like


Sure thing: direct message me on Skype (Skype ID: CoreyChancelor)



Sure thing: direct message me on Skype (Skype ID: CoreyChancelor)

Hi there

Sorry, but your Skype ID cannot be found.

As few clients I talk with had never heard of custom states, and also at the start of Bubble I was stuck, but now use them all the time, I did create a youtube playlist on them a while back, going from the simple to the more complex use-case. Hope it helps.

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.