Hi,
i have thousands of visitors daily in my multi-tenant app and i need to figure out how to set privacy rules based on user sessions.
Basically i dont want to create new user record for every visitor. Top solution would be something like “current user unique id is record visitor-id”. But bubble doesnt allow to set rule for non-db fields of user.
Could you give me advice how to do it plase?
Thank you.
Best,
Michal
Usually you set privacy rules for logged in users (Current user is logged in)
On the other hand, you’re allowing non-logged in users to see fields by enabling them in the “Everyone else“ permissions ? These fields are publicly accessible.
Why dont you create a table called visitor session/session and save each visitors unique id to it. If bubble doesnt assign one, you can do it with a simple javascript on page load.
Then you can assign resources based on their session id, set your privacy rules accordingly.
you’re right that Bubble won’t let you use unique id directly in a privacy rule condition, but there’s a clean workaround.
The approach I’d recommend: add a custom field to your User type called visitor_id (text field), then on page load run a backend workflow that checks if the current user has no visitor_id, generate one (you can use Bubble’s “Generate a random string” or a UUID from an API) and save it to that field. Now you have a persistent, database-stored identifier you can reference in privacy rules normally.
For truly anonymous visitors (not logged in at all), Bubble’s anonymous user session via Current User still gives you a temporary unique ID per session you can store that in a cookie or URL parameter on first visit and pass it into your workflows to link session activity without creating a full User record.
The key principle is you can move the identifier into a real database field as early as possible in the session, then your privacy rules can reference it like any other field.
One thing worth noting is with thousands of daily visitors, make sure your privacy rules are using database-level conditions (not :filtered after a search) otherwise you’ll burn through workload units fast.
