SaaS User & Company account creation... Bug?

Need help Database
1

I’m a first-time user trying to build a SaaS app, and I’m at the point where I need to build the user management functionality.

Currently, my “sign up” workflow, which collects both User and Company information (Name, Domain):

  1. Creates a new user
  2. Logs that user in
  3. Creates a new Company only when [Do a search for Companies where Domain = Input Domain]:count is 0
  4. Sets the new User’s related company to the result of step 3 only when there’s a single company with the input domain.

Here’s the problem (which I worry is a bug):
Step 3 is somehow running (and therefore creating a new Company thing) before evaluating its only when condition… A new company is created every time a new user logs in, even if the only when condition evaluates to false, which it always does, as the company created in step 3 appears in the search for companies with the same domain within its own only when condition.

If I change the only when condition to check if the count of companies with the same name is 1, everything works as expected (aside from no user ever being able to create a company). The problem is that while that workaround does indeed stop companies with duplicate domains from being created, it also stops the first company from being created, rendering the sign-up flow useless.

I could be missing something, but this seems like a bug… I just reported a report, but I’m now looking for workarounds so I can proceed with development.

How can I create a sign-up flow that only creates Company things with unique Domain fields? Do I need to separate User creation from Company creation?

2

I’d love to hop on a call to help (for free). It’d be easier than hashing it out over the forum, and be easier to look into specific tabs/workflows/etc. to determine whether or not it’s a bug.

3

Are you sure it’s not just a privacy rules issue (it certainly sounds like it might be)…

And what makes you think the condition is always evaluating to false? (I can probably guess why you think that’s what’s happening)…

(Also, don’t use :count is 0… use :count < 1 instead - not that that’s got anything to do with your issue…)

1 Like
4

Thanks nysykes, that’d be super helpful! What’s the best way to coordinate that for you?

5

Hey @adamhholmes, thanks for the response!

I’m 99% sure it’s not a privacy rules issue because I haven’t set up any of those for this app yet (still pretty early in development).

I can tell the condition is always evaluating to false by stepping through the sign-up process in the debugger. When I use :count is 1, it correctly evaluates to false and skips that step of the workflow when creating the first Company thing for a given domain. The super odd behavior happens only when I use :count is 0 — in this case, the condition always evaluates to false because the new Company thing is being created and returned by the Do a search for... :count is 0 that’s supposed to evaluate to true before creating the new thing. And the new Company is created despite the only when clause always evaluating to false, causing unintended duplicates in the database.

It’s a head-scratcher.

What’s the reasoning for using < 1rather than is 0? More performant?

6

Scratch that, feeling silly, turns out it was a privacy issue all along :man_facepalming:. Totally forgot I set those up while following a tutorial ages ago.

I got the intended functionality by changing the privacy settings to allow companies’ domains to appear in searches and creating 2 separate workflows (one for when a company with the input domain exists, and one for the other scenario).

The above behavior still seems buggy, but I’ll investigate how it works with the updated permissions tomorrow (it’s still odd that it was seemingly running the contents of the workflow step before evaluating the only when \ even when the only when evaluated to false.

1 Like
7

I suspected that’s why you thought it was false… but it’s not… that’s not how it works…

If you have (as it turns out you do) privacy rules on the thing you’re trying to create that prevent it being found in searches then, obviously, it won’t be found in the search…

So when you check if one already exists with the given domain, the results will return nothing (search count is 0 will be true) and a new thing will be created, even if there is already one (or several) in the database.

However, if you use the debugger in step-by-step mode, it will appear that search: count is 0 is false… here’s why:

When you click the button to start your workflow in step-by-step mode, your workflow will run, immediately, in normal speed (at least sever actions, like creating a thing will), even though the debugger shows that nothing has happened yet (check your database to prove it - the new thing will be created as soon as the button is clicked - even in step-by-step mode).

So immediately the condition search: count is 0 is evaluated as true, and a new thing is created.

Then, you click ‘next step’ a few times until you reach the step to create the new thing (but in reality that step has actually been completed as soon as you clicked the button).

Now the the debugger will show search count is 0 as false (because the thing was already created , as the condition was initially true) - giving the false impression that the condition was false (which it is by the time it’s shown in the step-by-step debugger - but it wasn’t when the action actually happened).

I don’t think it’s a bug - it’s just the way it works… but it does confuse a lot of people…

So the debugger, in step-by-step mode isn’t much use for checking the actual order of actions, or how conditions are being evaluated…

What’s the reasoning for using < 1 rather than is 0 ? More performant?

Yes… it’s faster and costs less in WU… (it shouldn’t be… but it is due to a bug in the way the number 0 works in Bubble - which they’re working on a fix for: Search: count is 0? Or Search:first item is empty? - Tips - Bubble Forum)

2 Likes
8

Awesome, thanks for the explanation!

Super helpful to know more about how the step-by-step debugger works, and I’ll take the tip and replace all of my conditions that rely on 0.

Much appreciated :slight_smile:

1 Like