I’m implementing a company code system for B2B access during user signup.
Employees can enter an organization code when signing up to join their company if their employer has purchased seats.
Each company record contains:
company_code
seat_limit
Signup workflow logic
If organization code is invalid → show invalid code popup
If seat limit is reached → show seat limit popup
If seats are available → sign the user up
Assign the company to the user
Send the user to the main page
If there is a fake code they will get an invalid code popup
I’m also having problems with if they dont enter a code at all, now when they click the signup button it doesnt navigate at all, when it did before because it would just be a free user joining the app so that part is stuck now too.
Seat availability check:
Search for Users:count < Search for Company’s first item’s seat_limit
Example test
Company seat limit = 3
Example test
Company seat limit = 3
Expected behavior:
User 1 = signup works
User 2 = signup works
User 3 = signup works
User 4 = Seat limit popup
Actual behavior:
User 1 = signup works
User 2 = signup works
User 3 = Seat limit popup shows but still navigates to main page with access
User 4 =popup appears but workflow glitches (briefly goes to main page then back to signup)
It seems like the seat limit condition is triggering too early or conflicting with another workflow step.
Has anyone implemented something similar or see what might be causing this behavior?
So i don’t recommend doing it this way. You are probably exposing your app to security issues with privacy rules.
They way i would suggest building it would be to have the admin user, the one that signed up originally for the company, invite other users to the app. That way, it is secure and you don’t expose your data publicly. Does that make sense?
Right now the company code system simply allows employees to enter a code during signup. If the code matches a company record and the seat limit hasn’t been reached, they are allowed to sign up and receive access.
No company data or dashboards are exposed before signup — the workflow only checks whether the code exists and whether seats are available.
I generate the company codes myself and they have seat limits, so organizations would be responsible for distributing the code to their employees.
My main issue at the moment is just the seat limit workflow behavior during signup.
Do you see anything specifically wrong with the logic I’m using for the seat limit check? Would this system be fine if i generate the codes myself behind the scenes to give to the companies and there is no where users would be able to see the data or dashboard themselves.
So that just means that anyone with that code would have access to that company. Let’s say if someone shares it with someone else or something like that. I still don’t think this is a very secure way of doing things. Just my opinion though. They could also just use a Brute Force Attack to get the code.
Am I correct in assuming that your current issue is that if they don’t enter a code, it doesn’t work? Also, the actual behavior is not as expected from your info above?
Can you show us that workflow in full? Maybe a screen recording? Then we can try to debug the issue for you.
Again, I don’t think this is the best way to go about it but I can take a look for you anyways.
Thanks for the feedback - I understand the concern about someone sharing or guessing the code.
Just to clarify my setup: the signup page only checks whether the company code exists and whether the seat limit has been reached. It doesn’t expose any company data, dashboards, or company records before signup - the workflow simply allows or blocks access.
So the only risk I see is someone obtaining the code and signing up, which would still be limited by the seat limit.
Do you think the current setup could actually expose company data through Bubble searches/privacy rules, or are you mainly referring to the possibility of someone guessing the code?
Also yes - the main issue I’m trying to debug right now is the workflow behavior. The seat limit logic isn’t behaving as expected during signup.
Seat limit = 3 (Test number for if a company had 3 employees)
Users 1 & 2 work correctly
User 3 shows “seat limit reached” popup but still gets created + logged in (shows user in database)
User 4 gets seat limit popup but still ends up with access / wrong navigation (after popup when i click go to login page link it brings them to main page with access instead and shows user in database)
Fake codes work correctly
Seems like the popup and signup steps are both running — not stopping the workflow. Not sure what to do I keep getting stuck and feel like I am close but not there yet. Any thoughts?
It looks like your current setup could be optimized a bit. I’d recommend moving the condition to the top of the workflow so it only evaluates once, rather than at every step. You might also consider splitting this into multiple button workflows based on those conditions.
I can’t see your privacy rules, but based on what’s shown, allowing user and company searches directly from the frontend could introduce some serious security risks. I’d strongly advise revisiting that approach.
It seems like tightening up some foundational concepts could help improve both security and overall structure. If you’re open to it, a coaching session could be a good way to walk through this and get everything aligned.
Before going live, I suggest also testing for a race condition: where two or more users signing up at the same time (within a few seconds) all get access to the one remaining seat.
This can happen if the login happens before the client (browser) is updated, so especially vulnerable if the Bubble server websocket is lagging.
I second. You are exposing every user’s company which I don’t know if that’s a big deal but you probably don’t want to right? When you do Search for Users (constraint: company = company), that means the company field on every user signed up has to be exposed. If you really don’t want to do an admin invite system, then you should make this entire check in the backend. Check out how to use the App connector plugin or API connector to call your own backend, then create a workflow there for the check that returns if the signup can proceed or not.
Or, you could make a new data type as a join/satellite table. This would be called like “company_signup_limits” and have the company attached to it, the code attached here, and then a number as “remainingSeats”. But this again exposes an extra bit you may not want to, to the whole world: the remaining seats and codes of every company in your DB”
A trimmed-down copy of the page(s) with a starting timer workflow.
First it’s worth pointing out that for this app:
May not need fixing, if for example the seat limit is a soft limit (eg. 300-ish seats)
May not have a race condition, if for example as @parthapatel0723 says do the check on the backend
Too much info about testing …
A race condition is a logic flaw, potentially in this case about multi-user timing of events. As such I test for it first where the test is most cost effective.
If a “code” app, ideally a unit test case to run the code through scenarios.
For a Bubble app, the equivalent can be a trimmed-down copy of the page(s) with a starting timer workflow.
The choice of tool for test execution depends on volume: low-volume just manually spin up multiple browsers and tab containers, high volume (greater than say 20) any web automation tool will do it.
The seat limit being a business requirement may mean (depending on the SDLC) you want “user acceptance tests” where multiple people/browsers/tab containers test using the real page(s).
Note that this testing is not the same as Stress Testing, which should only be done with the permission and assistance of the infrastructure owner, i.e. Bubble team.
Does that make sense?