Bubble Language Change: the "is logged in" condition for a User will now be "is signed up"

Hi everyone,

We wanted to let you know about a Bubble language change we are making. From now on the conditions “is logged in” and “is logged out” that can be applied to a User Thing will respectively be “is signed up” and “isn’t signed up”.

This is purely a language change and the underlying behavior will still be the same as it was. So, from now on, “Current user is signed up” will evaluate like “Current user is logged in” used to. Also, this will not break any existing behavior as the language will automatically be changed in any applications that currently use the conditions “is logged in” or “is logged out” and the evaluation will not change.

We are making this language change because this condition evaluates whether the User it is referring to has created an account or not and not necessarily whether they are currently logged in or not. An example where this was confusing was if you created a Repeating Group with Data Type User and made the Data Source a search for all the Users of an application. If there was then a condition in the cells of the form “Current cell’s User is logged in”, this would always evaluate to “yes” because for a User to be in the database, they must have signed up. This led to some confusion because the users might not currently be logged in but the “is logged in” condition would evaluate to “yes”. This confusion is why we have decided to change the language to “is signed up”.

We currently do not offer a feature to know if “User X is logged in” as this would mean exposing if Users currently have a valid session which could lead to security/privacy concerns and is not trivial. For the moment, we only allow checking if the User has an account or not. However, evaluating whether the Current User is logged in or not is the same as evaluating whether they are signed up or not since the only way for the Current User to match an existing account is if they are logged in.

Please let us know if you have any questions and happy building!



That definitely addresses this issue. Nomenclature does matter. Thanks!



You are right, thank you for that!

What would be best practice to access if a user is logged in, for example, for displaying their online status?

You could create a new field in your user data type that changes from the moment they hit your Login workflow (set to ‘online’), and that would renew every time a page loads, with a 3600 second timeout before it’s changed back (to ‘offline’).


The functionality still works the same the working just changed.

isn’t signed up = isn’t logged in
Is signed up = is logged in

Another way to do this is
current user email = empty
Since to be logged in bubble requires an email.

(Edit: take my response with a grain of salt, the explanation in post is actually kinda confusing as it states it was just a language change however then goes on to contradict it to being a functional change from my understanding :thinking:)

You can still use current user email or current user unique id is empty to determine login status though.

1 Like

But this seems a bit illogical to me. Sign up and Logged in are 2 different events - The user can be signed up but not logged in. It means that this change will basically change the behaviour of apps using this condition. And there will no longer be a way to setup workflows based on logged in/out condition, right?


Can I seek some clarity on this change in regards to the following:

  1. Workflow → General → User is logged in / User is logged out
    What are the implication of this, should this be changed or does it actually mean the user is signed up and they are logged in / out.
  2. Privacy rules
    the current user is logged in (now signed up) has always been checking if the current user has a valid email and password. The current user test can only be made on the current user that is signed up and logged in?

Some pages may be accessible by anyone and some only by logged-in users.
In this scenario which test should be used.
condition is signed up or
workflow -. general when the user is logged in.

  1. This workflow uses the same logic under the hood, so when using the “Current User is signed up” check, true means they are also logged in. If they don’t have an account, it simply means they aren’t logged in.
  2. Same thing here, correct.

As such, you could use either method here to achieve the same results.

FYI - One change we are considering based on the feedback so far is maintaining the old language of “Current User is logged in / is logged out” when the data source is Current User and then “is signed up” or “has an account” for when the data source is a generic user. The reasoning behind this proposed change is that when referencing a Current User, while the underlying logic is checking for an account, its really telling us if the user is logged in. This is because a user has to be logged in for the account to be recognized, otherwise it is false. On the flip side, when referencing the user datatype in general, we only have the ability to check for account existence, not session status, as mentioned above, so the new language is more accurate.

Any thoughts on this proposal?


I was thinking of this dynamic type solution as I was reading the thread, got my vote

I think this makes more sense @nick.carroll :+1:

Otherwise, it would just be confusing. Thanks for thinking of a good balanced solution.

I think this @nick.carroll makes more sense, as it is the least confusing explanation. Something must be wrong if you need 200 words to explain it.


Checking the database for a User data type, if there is a result would basically mean they have an account and therefore are ‘signed up’…however, I couldn’t imagine a situation in which a search of the User datatype would return a result that would be indicative of ‘user is not signed up’ because from the simple fact that a result was returned on the user data type search verifies that the user ‘is signed up’.

If this were to address the issue of a allowing a workflow to run workflows and create something in the database when the user who performs that action is not a registered user of the platform and therefore ‘is not signed up’ then this would make more sense as I could search for a datatype of ‘Restaurant’ and determine if the ‘Creator’ of that ‘Restaurant’ ‘is signed up’ and if the value of the ‘is signed up’ returns as false, I would know that the ‘Restaurant’ was created by a user who was not a registered user.

Searching the database for User data type though to me is not a potential use for the ‘is signed up’ evaluation as mentioned, no matter what it is already clear that a User data type entry that returns a result is returning a User in the database who ‘is signed up’.

That seems to be what I have said above about searching for Users and results indicating the user ‘is signed up’ and there is no need to use an evaluator to glean that information.

However, having an operator for ‘user is logged in’ can be helpful for various reasons, such as indicating in a Chat feature if the User who is part of the conversation is currently logged in, indicating they have an active session. I believe that is an evaluator that is actually going to be more helpful and valuable in more situations.

I think that it could be something that is a feature and an available function and the security/privacy concerns be left up to the developer themselves. We already have access to privacy rules, and in my mind Bubble should not be held responsible in any way for privacy issues related to an app that a developer put together with poor privacy controls.

Giving us in the privacy controls a field to check to decide if we the developer want to restrict the exposure of the ‘is logged in’ evaluation, just like we can do with the User data type social media login, slug and all other data fields on that User data type.

I can think of plenty of examples of when we might want that complete control, and thinking along the lines of an application with companies who have employees who communicate with each other, the privacy rule can be constructed to say when the ‘current user’s company is this users company’.

I was live in a Bootcamp session looking at a student’s app who is from Italy and I thought it was some kind of difference in the way the translation was working, but later saw it in my own app and was taken back by the change.

My first reaction to it was that it would function differently than the existing ‘is logged in’ and instead would help us to evaluate if a User who is on the app has actually ‘signed up’ or not…something that lead me to believe evaluating that would be related to the cookies tracking users and determining if they are a registered user or not as it relates to them creating data in the database when not ‘signed up’ or ‘logged in’ and the data field of creator would be the ‘ghost’ or ‘anonymous’ type of user.

Absolutely and this crops up in various areas, such as the ‘parent groups width’ versus the ‘container width’ when setting the collapse width or hiding rules in the responsive editor…no reason for using two different terms that mean the same thing because it leads to confusion.

Also crops up in things like API stuff as mentioned in this post


The wording of ‘user is signed up’ is very confusing and I do not think does a decent job of conveying the actual functionality of the operator. ‘Is logged in’ was much more self explanatory and I personally think does a much better job of conveying the functionality behind the operator.


Thanks for all of the feedback everyone! We are moving forward with the above proposal of
“Current User is / isn’t logged in” (like it was before)
“This user has / doesn’t have an account” instead of “is/isn’t signed up”.


Correct - your Restaurant use case is a great example of why the old naming was confusing.

Yes, I like it!

Having worked with this now for a bit, is/isn't signed up simply doesn’t make as much sense in certain contexts (as you’ve described). It forces too much mental gymnastics. If I understand correctly, I think what you’re proposing will be the best solution.

Thanks for listening and for trying to make Bubble easier to use and understand.


FWIW, my experience indicates the latter is not the case, as the UID is defined even for non-logged-in visitors who have cookies enabled. If the visitor signs up, that value actually becomes the new user’s unique id though.



Thanks for the update regarding this. I’ve been building out an application on Bubble for some time now and have been stuck on the privacy permissions part. The community has been great but asking here as you mentioned "We currently do not offer a feature to know if “User X is logged in”.

I’m trying to only allow user X to update items relating to their account, so for example, I’m using this to show elements and pulling the data from the “Parent group” of that page/repeating group. I’m displaying settings in an overlay to make it easier to have them edit it (profile pic, cover photo, etc.) but can’t seem to separate the users and any logged-in user can edit other user’s settings.

Any help here is greatly appreciated or if you can even point me in the right direction. I also want to make sure this is achievable with Bubble at the very least.

Attaching a screenshot to show in more detail. It may also help to note I’ve built this so there are edit buttons o the page for the user, but are hidden if logged out users access the page. Which isn’t solving my issue for other logged-in users.

I’m guessing this change was abandoned? I’ve only been building with Bubble for a few months, and my workflow conditions still use “is logged in/out”. I don’t have any “is signed up / isn’t signed up” options.


This is the most recent update @samnichols

1 Like