Any use of Schedule API workflow adds an item to the scheduler, even if it’s immediate.
There is no documentation on how calling the workflow API directly via a synchronous API call does/doesn’t incur WU (does this ‘add to scheduler’?)
Yes, I would agree I’d expect this DB trigger charge to be included in the total WF WU usage, but evidently it is not so somethjng’s not clear here.
So just tried testing a couple variations but it seems that coming up with a arbitrary WU number takes some time as now its shows ZERO WU for these workflow action (even though there are individual actions triggered by the DB trigger that have WU numbers)
So every API WF costs .1 to schedule? Do Custom events as well?
Presumably not, as that does not open an additional API job in Bubble’s servers (i.e a custom event is equivalent to calling a function within a function, rather than calling a different API entirely).
Of course, these are not questions that we should be needing to ask as it’s not our job 
last update on this insane situation (I cant continue pretending there’s rhyme and reason to WU when Bubble wont respond with any hard number no matter how many hundreds of times we puch)
The new DT triggers 20+ minutes after they have run have no WU on the loga or in the metrics 
Don’t tell them they didn’t charge you, or they might fix it!
Can Bubble create - delete list of file Urls action as well.? Given we can only delete single file at this time, it requires us to use recursive workflows.
You should put a workunit meter inside the workflow action itself. For example you sign the user up with everything clicked and it shows a little 0.5 icon next to the action add a couple more actions at 1 and 0.5 and your total workunits are now shown as 2wu at the end of the workflow.
The problem with this workunit model is that the user has absolutely no idea how much their app needs or how much theyre using until the app is live and its too late to really change anything without breaking your app or getting hit with a gigantic bill because you’re not on the right plan.
These 3 things would be amazeballs. I don’t know how long I’ll be using Bubble for as I’m moving out of the industry, but WU is a complete mystery to me.
When I see something consume too much WU I don’t know if I can make it more efficient or whether to just dump that customer feature entirely.
I feel like Bubble says ‘look you can build this!’ , then you build it and after you build it Bubble says ’ well great, that will cost you $, please move up to a new plan.’ As a freelancer, that’s not viable.
I don’t know how other devs do it but I’m finding the lack of WU insights is really bad.
Where I would have recommended Bubble to 9/10 people before, I now recommend Bubble to 0/10 people (for $cost, reliability, and WU reasons), and I’m the freelancer!
I feel like it’s a tool you take a gamble on and it either works out for you or it doesn’t and you find out the hard way.
Good direction but there still needs to be more transparency. There is all this talk of WUs replacing capacity but then in the last few issues with downtime, there is the point that something on the main cluster has caused an issue and Bubble is now actively throttling apps on the main cluster so it may be good marketing to say that Bubble apps are now entirely not limited by capacity but the last few announcements reading between the lines would show that an arbitrary capacity limit is alive and kicking somewhere.
This is just another thing that makes the Bubble pricing leave a sour taste in the mouth, plus the lack of incentive for Bubble to optimize and makes things more efficient. I would have thought Bubble would be focusing on making things as simple as possible for people to understand, get more people in the door and make more money that way rather than focusing pretty much entirely on nickel and diming their already captive audience, as that is what it feels like.
Either go full transparency or don’t bother. The list of full WU or reasoning of calculations would go along way in that. Likewise, everyone seems to want the return certain fields from a search, Bubble is obviously finding that difficult to do, explain the reasons why or you just alienate people.
So soon the cow will REALLY be on the run. 
Will miss seeing you around these here parts. Where ya running to?
very nice @laura.oppenheimer I’m very happy. Can’t wait to use it.
This isn’t linked to notifications for WU but I’m +1000 with the folowing :
the idea has been suggested here if people you want to upvote : Return only data relevant to a page (page-based privacy rules) | Bubble
You know I love Bubble @laura.oppenheimer and this notification feature is really nice ! But I talk to @alex.bolanos about the editor design, and said that we don’t need those “nice-to-have improvments”, but “must-have” .
I always said, to you or to @emmanuel that developers are your best sales people. So let’s continue to hear from us to improve Bubble a way we can sell it !
Lol ha ha! I’m about to sign a lease (hopefully, fingers crossed), to run an Escape Room in an old train carriage in our tourist town. Get me away from the laptop, meeting people, and hopefully having some fun in the process!
Ps. The paragraph below from the Bubble manual sums up what is wrong with this pricing method. The fact Bubble even have to have a paragraph in the manual explaining that WU ‘may feel convoluted and overwhelming’ should be an indicator to you that it actually is!
Having looked at these two examples, the workload metric may feel convoluted to predict and understand, but let’s re-visit its purpose: to give a realistic and fair calculation of the work the server has to do to power your app. It may feel overwhelming to be expected to calculate the minutiae details in the examples we provided above, but that’s not their intention: most operations in Bubble (the two examples included) are very low-cost to execute and there’s no need to analyze, understand and predict every single operation down to the last decimal place.
I want to thank the active Bubbler’s in this thread raising concerns and voicing our needs as power users 
And especially taking the time to include very concrete examples.
I do not have time to chime in with my own specifics but I want to put up a +1,000 to all of these points. The WU structure, clarity, pricing and logs are big concerns for us power users with apps in production to trust the platform long term
Oh, another thing - this forum has continuously documented issues with WU calculation (Bubble bugs). The answer from Bubble is ALWAYS ’sorry, but we don’t have any plans to fix it any time soon!’. Come on, how’s that 1. responsible 2. ethical 3. building trust?!
Example: PSA: This Repeating Group's X uses WU - #12 by georgecollier
Yeah, maybe some of the issues are hard to fix - that’s on Bubble, not us. Your fault for designing a completely arbitrary and immeasurable billing system. Bubble designed the system - it’s on Bubble to fix it, no matter what it costs
you, because it’s costing us and clients are being turned away from using Bubble.
This is a hill I will die on 
The power of social media is with us George 
. Bubble is making the classic mistake, only a couple of users are vocal about something so nothing (or not al lot) is done about it.
But us little people have social media now. Once people post about these things on LinkedIn, Facebook, Reddit etc., and word gets out there, Bubble will have to act on it.
Also don’t forget the 100m investment they got 1 or 2 years ago, a bad name → less (new) customers → less money → less Crystal & Caviar → unhappy investors.
And what bothers me, is that the users who are vocal about it, have Bubble’s best interest in mind and are often very valuable forum members. Just listen to them and act on their ideas (reserve some of the development capacity to implement them). Happy current users → happy posts on social media → more new users → more money → more Crystal & Caviar → happy investors.
This is exactly the problem with the workload based approach. As we predicted when this was released, Bubble is now focused on how it reports the usage rather than reducing the usage. The responses in this thread are full of examples where people are being charged for complexity that has no fix because Bubble OVERCOMPLICATES simple tasks. The best example of this is having to add filters to any data search that needs to add a constraint to a related thing. It overcomplicates grouping, it overcomplicates recursive tasks. It overcomplicates page design. All of this over complication simply leads to more computational power so that the user pays more to achieve less. We need Bubble to be finding ways to simplify the tasks that make our applications work.
Who remember this https://www.youtube.com/watch?v=mnrwVdz_wKU ? … In other word: they show how not to use Bubble to do thing. Instead take everything outside to reduce WU or make thing more complicated (considering that Bubble is nocode tool).
I know I said it was my last post on Friday, but I just had to circle back one more time, especially since the crickets from Bubble and @laura.oppenheimer (not to shoot the messenger, it is certainly not your fault there are not answers) are deafening.
It’s now 4 days after the experimental DB triggers, and there are absolutely ZERO, NADA, ZILCH WUs being calculated or displayed for activities that are universally understood to consume WUs ( see image and 4 circled activities - DB trigger (.05), Server Side WF (.60), Scheduler (.10), Modif a thing (.50)). I may be missing something (please let me know), but this appears to be very strong evidence that WUs are not being calculated in accordance with the activities that Bubble has provided. How on earth does Bubble justify billing millions of dollars for metrics that are, at best, not calculated properly and legitimately, and, at worst, are completely inaccurate and possibly arbitrary?!? Anyone?
Finally, we know Bubble makes it impossible to try to extract actual WUs from the logs with its impossible filters, constant timeouts, and inability to search or extract logs, but this example is mind-blowing. I did a search for logs for a ONE minute duration on May 24th without any additional filters in "user email: or “contains” fields.
Even with such a limited query, Bubble gives me these random logs from days later (May 26th)! ( in addition to the logs for those minutes) (@chris.williamson1996 and we optimistically said a few hours can be retrieved without the logs crashing)
