# Backend variables? **URL:** \ **Category:** Need help\ **Created:** [June 10, 2025, 1:39pm UTC](https://forum.bubble.io/t/backend-variables/372442 "2025-06-10T13:39:07Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ash8](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/ash8/32/239382_2.png) [@ash8](https://forum.bubble.io/u/ash8)\ **Post date:** [June 10, 2025, 1:39pm UTC](https://forum.bubble.io/t/backend-variables/372442/1 "2025-06-10T13:39:07Z")
**georgecollier,** you’re the expert can you give me a one line answer to the following? and I’ll buy you a beer/coffee if you have a link? (or anybody else):- Doing multiple searches of Subscribers on the backend is inefficient. I want **one** search and to use that search throughout my backend workflow like custom states/variables for backend. What is the best way to do this?- Use the app connector, pass the search from front end to backend using parameter (do the search on the parameter) Use custom events for parameters Use plugins Any other way? What’s the most performant, WU friendly option? Thanks, spending far too much time trying to figure this out. ---
**Author:** ![Jici](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/jici/32/30722_2.png) [@Jici](https://forum.bubble.io/u/Jici)\ **Post date:** [June 10, 2025, 1:40pm UTC](https://forum.bubble.io/t/backend-variables/372442/2 "2025-06-10T13:40:43Z")
What you describe sound more like a case for schedule API workflow on a list. What is your end goal, what do you want to do with the result of the search? ---
**Author:** ![ash8](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/ash8/32/239382_2.png) [@ash8](https://forum.bubble.io/u/ash8)\ **Post date:** [June 10, 2025, 1:47pm UTC](https://forum.bubble.io/t/backend-variables/372442/3 "2025-06-10T13:47:40Z")
I am trying to add a subscriber to my newsletter. Two inputs (first name and email). When a user presses the subscribe button I want to send them a verification code and create them as a subscriber but the field (verified) is no until they’ve confirmed via email. Before this happens I need to check they’ve not tried this more than 3 times in x hours, and that it doesn’t already exist. If it exists but not verified show x message, if it exists and is verified don’t let it happen and show ‘already subscribed’ message. When they click the email it redirects them, on page load or do when true, pull the parameter (code) and (uniqueID) from the URL and run the app connector (do a search on the app connector parameter to grab that specific subscriber) On the backend make a change to that parameter (subscriber) to verified = yes, then send the confirmation email, return data (to use custom state messages on front end) i.e You’ve subscribed! or if it fails “Try again”. Basically:- > **The goal is to create a newsletter subscription system where users submit their first name and email via a form, triggering a check to ensure the email isn’t already subscribed (displaying “Already subscribed” if verified, or a verification prompt if not) and hasn’t exceeded three attempts in a specified time frame. Upon valid submission, a subscriber record is created with `verified = no`, and a verification code is sent via email with a link containing `code` and `uniqueID` parameters. When clicked, the link redirects to a page that extracts these parameters, updates the subscriber’s record to `verified = yes` using an app connector, sends a confirmation email, and displays a frontend message: “You’ve subscribed!” for success or “Try again” for failure.** ---
**Author:** ![Jici](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/jici/32/30722_2.png) [@Jici](https://forum.bubble.io/u/Jici)\ **Post date:** [June 10, 2025, 2:00pm UTC](https://forum.bubble.io/t/backend-variables/372442/4 "2025-06-10T14:00:20Z")
> [@ash8](#): > > using an app connector Because this is stored in another app? I don’t see any reason for using backend WF for you case. This will be done with simple Do a search for in front end when user go back to your link using Get data from URL. One DB “newsletter” with a field for verified and attempt. You could always use two DB one for request and one for newsletter if you prefer. If you care about privacy rules, you could use app connector or API connector (my choise in this case go to API connector). Basically just to validate that the code is valid and update the subscriber (you don’t need to send both unique ID and code.). According to the result of the validation, you can return data from API saying a message like “sucess”, “expired”, “invalid code”, “Too many attempts” and display the message in front end. ---
**Author:** ![adamhholmes](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/adamhholmes/32/100510_2.png) [@adamhholmes](https://forum.bubble.io/u/adamhholmes)\ **Post date:** [June 10, 2025, 2:09pm UTC](https://forum.bubble.io/t/backend-variables/372442/5 "2025-06-10T14:09:06Z")
> [@ash8](#): > > I want **one** search and to use that search throughout my backend workflow like custom states/variables for backend. It’s _truly_ extraordinary that Bubble doesn’t have any proper way to work with variables inside backend WFs… > [@ash8](#): > > Use the app connector, pass the search from front end to backend using parameter (do the search on the parameter) > Use custom events for parameters > Use plugins > Any other way? What’s the most performant, WU friendly option? The best way (the fastest and most WU efficient) to do this is by using Custom events as variables (assuming you can’t use the WF parameters themselves - which you sometimes can, depending on the use-case). Any plugins you use for this can add significant WF cost, and slow things down a lot. That said, for you particular use case I’m not sure you need to store a list as a variable… there are probably simpler ways of doing it, as described already in this thread. ---
**Author:** ![ash8](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/ash8/32/239382_2.png) [@ash8](https://forum.bubble.io/u/ash8)\ **Post date:** [June 10, 2025, 3:45pm UTC](https://forum.bubble.io/t/backend-variables/372442/6 "2025-06-10T15:45:44Z")
Thank you @Jici and @adamhholmes. I’ve spent so long on here that I often overcomplicate the simple things. I’ve just managed to do it all in 30 minutes without the backend at all. 😅 I was under the impression that the front-end workflows cannot search dataType data in Only When conditions because of Privacy Rules. I now believe that they can as front-end workflows are still server side, you just can’t show that data outside of the front-end workflow unless Privacy Rules permit. > [@adamhholmes](#): > > It’s _truly_ extraordinary that Bubble doesn’t have any proper way to work with variables inside backend WFs… I know, it’s madness. Using ‘run APP/API connector’ and passing parameters from the front-end was the only way I knew of doing it but then you’re running the search on the front-end. Custom events is the only way I know to do it on the backend (I didn’t know this until I read your post on this forum from March 2024 thank you for that @adamhholmes! ---
**Author:** ![ash8](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/ash8/32/239382_2.png) [@ash8](https://forum.bubble.io/u/ash8)\ **Post date:** [June 10, 2025, 4:03pm UTC](https://forum.bubble.io/t/backend-variables/372442/7 "2025-06-10T16:03:57Z")
Nah, I was right. You literally cannot do a search on a front end workflow and use that data (like do a search for subscribers (constraint: email = this input’s email):count on the front-end without leaking your email in privacy rules. Would love to be corrected if I’m wrong but you have to do this backend? 😅 ---
**Author:** ![adamhholmes](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/adamhholmes/32/100510_2.png) [@adamhholmes](https://forum.bubble.io/u/adamhholmes)\ **Post date:** [June 10, 2025, 4:20pm UTC](https://forum.bubble.io/t/backend-variables/372442/8 "2025-06-10T16:20:28Z")
> [@ash8](#): > > (like do a search for subscribers (constraint: email = this input’s email):count on the front-end without leaking your email in privacy rules. If the subscriber datatype is ‘not findable in searches’ for a particular User then a search won’t find it, so the count will always be 0. If it _can_ be found in searches, then it _will_ be found (regardless of what fields are accessible via privacy rules). So you _could_ permit it to be found in searches, but restrict all fields from being accessible, and that will give the correct count, whilst keeping all field values protected. but it’s more secure to not allow it to be found in searches at all - in which case a backend WF can be used to establish the count. ---
**Author:** ![ash8](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/ash8/32/239382_2.png) [@ash8](https://forum.bubble.io/u/ash8)\ **Post date:** [June 10, 2025, 4:35pm UTC](https://forum.bubble.io/t/backend-variables/372442/9 "2025-06-10T16:35:07Z")
Ah that makes more sense. Is there much a hacker or competent person could do with enabling the verified (yes/no) field and unique ID of the subscriber in Privacy Rules? Also if you only ever do an Only when (Do the search here) in the front-end workflows, is it ever accessible via the DOM to hackers or ONLY if you save it in custom states or on page searches (RG, text elements etc) I don’t even think I can pass the search in a parameter as the search is done on the front end of the App connector (if I restrict all access to it) so literally custom events is the only solution if you want to search for subscribers that match that email and utilise that search multiple times across your workflow, correct @adamhholmes? ---
**Author:** ![DjackLowCode](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/djacklowcode/32/222536_2.png) [@DjackLowCode](https://forum.bubble.io/u/DjackLowCode)\ **Post date:** [June 10, 2025, 5:26pm UTC](https://forum.bubble.io/t/backend-variables/372442/10 "2025-06-10T17:26:55Z")
> [@ash8](#): > > Thanks, spending far too much time trying to figure this out. Hey @ash8 , what you need to do here is to create a backend workflow with a ‘return data from API’ action - this takes in the first name / email → then run your required searches, → and then return the information you need (could be yes/no, subscribed, etc.) You can do all this with the ‘ignore privacy rules’ checkbox selected. You would then call this API from your App’s API Connector (recommended) or APP connector. This will allow you to use this information in a normal workflow on the front end. This is a very common requirement to verifying data that should never be visible to users via privacy rules on the front-end (e.g. for logged out users, verification codes. etc.) Good luck! ---
**Author:** ![ash8](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/ash8/32/239382_2.png) [@ash8](https://forum.bubble.io/u/ash8)\ **Post date:** [June 10, 2025, 5:41pm UTC](https://forum.bubble.io/t/backend-variables/372442/11 "2025-06-10T17:41:32Z")
Thanks Djack, that’s exactly what I did originally but felt like it was overkill and may be able to move it to the front to make it simpler. I can’t without leaking data. To anybody else reading this: Privacy rules affect both backend and front end workflows. In the backend you have the option to bypass those rules but the front end workflows are affected if you’re doing searches or finding things that are blocked by privacy rules so any sensitive data should always be done in the backend. The app connector parameters are front end so searches done here to pass to the backend won’t show if privacy rules restrict. So your searches must be done on the backend. If you need to do several of the same searches throughout your workflow use @adamhholmes’s suggestion of custom events with parameters on the backend, it’s literally the only viable option at the moment to my knowledge. Thank you to @Jici , @adamhholmes and @DjackLowCode. ---
**Author:** ![Jici](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/jici/32/30722_2.png) [@Jici](https://forum.bubble.io/u/Jici)\ **Post date:** [June 10, 2025, 5:46pm UTC](https://forum.bubble.io/t/backend-variables/372442/12 "2025-06-10T17:46:58Z")
The search can be done on client side if you allow the search item. Data stay private and external user cannot modify it. There’s some option to workaround and keep it in front end, but I do not recommend them and you will probably not save on WU. ---
**Author:** ![DjackLowCode](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/djacklowcode/32/222536_2.png) [@DjackLowCode](https://forum.bubble.io/u/DjackLowCode)\ **Post date:** [June 10, 2025, 8:34pm UTC](https://forum.bubble.io/t/backend-variables/372442/13 "2025-06-10T20:34:41Z")
No problem @ash8 - once you get used to the process you can set these up in a minute or two. You will definitely come across the need to do this again for whatever privacy related workflow at some point though! ---
**Author:** ![ash8](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/ash8/32/239382_2.png) [@ash8](https://forum.bubble.io/u/ash8)\ **Post date:** [June 10, 2025, 10:24pm UTC](https://forum.bubble.io/t/backend-variables/372442/14 "2025-06-10T22:24:49Z")
@DjackLowCode , I’d love to be able to do these in a minute or two. Thanks 🙂 This is incorrect:- > Just for anybody learning too, backend custom events do not bypass privacy rules and cannot do so. There’s no option to bypass privacy on them and they do not inherit the “bypass privacy” of the backend workflow that they’re in. See > [@adamhholmes](#): > > A Custom Event in a Backend Workflow inherits whatever Privacy Rules settings the Backend Workflow uses. > > So if the Backend Workflow is ignoring privacy rules, so too will any custom events triggered within it. From my understanding, if go into Privacy Rules and check ‘Can be found in searches’ but only ever do the searches in the backend using backend custom events, it’s completely secure. Would love people that actually know about this to chime in and confirm or correct me though. ---
**Author:** ![ash8](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/ash8/32/239382_2.png) [@ash8](https://forum.bubble.io/u/ash8)\ **Post date:** [June 10, 2025, 11:09pm UTC](https://forum.bubble.io/t/backend-variables/372442/15 "2025-06-10T23:09:08Z")
I solved my use case and just for anybody else that’s getting a brain aneusrym over this stuff going bald years earlier than planned:- If you need to reference the same search multiple times on the backend, you can use > custom events to hold parameters but you’d need to check ‘This datatype is searchable’ in privacy rules. It’s secure as you’re still doing the entire search backend. But I found it a lot better to do this:- > Step 1: Make change to thing (do your search on this) but don’t add any fields or conditions. Leave it blank. > > Reference Step 1 anywhere in the workflow. I believe Make a change to an object but leaving it blank may be faster and more efficient than triggering a custom event to do the same search. Happy to be corrected. ---
**Author:** ![boston85719](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/boston85719/32/77286_2.png) [@boston85719](https://forum.bubble.io/u/boston85719)\ **Post date:** [June 11, 2025, 3:47am UTC](https://forum.bubble.io/t/backend-variables/372442/16 "2025-06-11T03:47:31Z")
The make changes to things trick for search results in a subsequent workflow action has been my go to for half a decade now. Works fine in my opinion. ---
**Author:** ![mitchbaylis](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/mitchbaylis/32/122860_2.png) [@mitchbaylis](https://forum.bubble.io/u/mitchbaylis)\ **Post date:** [June 11, 2025, 3:56am UTC](https://forum.bubble.io/t/backend-variables/372442/17 "2025-06-11T03:56:37Z")
I use custom events to store and return variables. 2 ways custom events in the backend which are shared across all backend apis custom events in helper reuseables which I can add to any front end page to do the same logic a common pattern is create a thing but only if not already created, if exists then return existing this is easy in a custom event as it silos off the logic trigger create conditionally using search for aggregate is 0 return data in the return you return search for plus result of create : first item this way the return will either be the existing or the created you have to use both search plus created because sometimes the search (although it shouldn’t) runs before the created has finished quite often I’ll use custom events purely to store and process data as well. ie to merge 3 searches for contacts I’d always use a custom event so that each search is held separately and can then be changed independently without having to rewrite the entire 3 search formula… which bubble loves making us do. in essence anything that feels a little heavy I just break down into custom events there is also the added benefit of custom events forcing order of operations - but that also has a downside of slowing down workflows (unless you use schedule custom event then they process alongside each other) ---
**Author:** ![adamhholmes](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/adamhholmes/32/100510_2.png) [@adamhholmes](https://forum.bubble.io/u/adamhholmes)\ **Post date:** [June 11, 2025, 7:08am UTC](https://forum.bubble.io/t/backend-variables/372442/19 "2025-06-11T07:08:28Z")
Just to add/clarify a few things here… > [@ash8](#): > > Just for anybody learning too, backend custom events do not bypass privacy rules and cannot do so. There’s no option to bypass privacy on them and they do not inherit the “bypass privacy” of the backend workflow that they’re in. That’s incorrect. A Custom Event in a Backend Workflow inherits whatever Privacy Rules settings the Backend Workflow uses. So if the Backend Workflow is ignoring privacy rules, so too will any custom events triggered within it. > [@ash8](#): > > From my understanding, if go into Privacy Rules and check ‘Can be found in searches’ but only ever do the searches in the backend using backend custom events, it’s completely secure If an item can be ‘found in searches’ then any user that meets that privacy rule can access it. Whether that’s secure or not depends on the privacy rules themselves. > [@boston85719](#): > > The make changes to things trick for search results in a subsequent workflow action has been my go to for half a decade now. Works fine in my opinion. This is a reasonable approach, with 2 caveats… Firstly, obviously this can only be used for ‘Things’ from the DB. It can’t be used for option sets, or API data, or primitive datatypes, calculated values or data manipulation etc. or anything more complex than defining single (or multiple) database items - so it has _very_ limited use compared to using Custom Events. And secondly it’s a _lot_ more costly in WU compared with using Custom Events. Using a Make Changes to a Thing action, although it does NOT incur WU charges for making changes to that thing (I’m almost _certain_ it used to, but it doesn’t seem to now) it DOES incur 0.6 WU as a server action. Custom events don’t seem to count as running a sever action, nor does a ‘return data’ action within a CE - so using a Custom Event as a variable costs 0 WU. So, if you’re using 5 ‘Make changes to a thing’ actions in a backend WF to establish some data to work with elsewhere in the WF, you’ll incur WU costs for 5 server actions (that’s 3 WU) plus 5 searches (1.5 WU) and whatever data is returned (e.g. 0.5 WU) so a total WU cost of 5 WU. Whereas you can use a single Custom Event to define all 5 items and it won’t cost anything to run it, so you only pay for the searches/data (actually, it makes no difference if you run 1 single CE or 5 separate CEs - since they don’t incur any server action charges). So a total WU cost of 2 WU (5 searches plus the returned data) - less than half the cost of using Make Changes to Thing actions. > [@ash8](#): > > I believe Make a change to an object but leaving it blank may be faster and more efficient than triggering a custom event to do the same search. Happy to be corrected. There’s no reason to think it’s faster but, as outlined above, it’s _definitely_ more costly in WU - so _not_ more efficient. ---
**Author:** ![manipaje](https://avatars.discourse-cdn.com/v4/letter/m/67e7ee/32.png) [@manipaje](https://forum.bubble.io/u/manipaje)\ **Post date:** [June 11, 2025, 7:39am UTC](https://forum.bubble.io/t/backend-variables/372442/20 "2025-06-11T07:39:40Z")
Did you try this plugin: [Store Temp Data (Result of Step X) Plugin | Bubble](https://bubble.io/plugin/store-temp-data-result-of-step-x-1660111853497x246324148854587400) ---
**Author:** ![adamhholmes](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/adamhholmes/32/100510_2.png) [@adamhholmes](https://forum.bubble.io/u/adamhholmes)\ **Post date:** [June 11, 2025, 8:02am UTC](https://forum.bubble.io/t/backend-variables/372442/21 "2025-06-11T08:02:24Z")
> [@manipaje](#): > > Did you try this plugin: [Store Temp Data (Result of Step X) Plugin | Bubble](https://bubble.io/plugin/store-temp-data-result-of-step-x-1660111853497x246324148854587400) Yep… as I said previously, plugins (by their very nature) are more costly in WU and, in many cases a lot slower, than using Custom Events. [Next page](https://forum.bubble.io/t/backend-variables/372442.md?page=2)